Sto godzin, 400 dolarów i 5 lekcji. Anatomia jednego narzędzia AI

Spędziłem nad jednym narzędziem ponad sto godzin. Wydałem około 400 dolarów na zewnętrznych usługach AI. Cztery razy zmieniałem całe podejście zanim trafiłem na to, które działa. Większość tych godzin nie poszła na pisanie programu — poszła na cofanie się z błędnych ścieżek.

Wyciągam z tego pięć lekcji. Nie po to, żebyś nie popełnił moich błędów — tych już nie zdążysz, są moje. Po to, żebyś popełnił własne, ciekawsze. I żeby kosztowały Cię mniej.

Tekst piszę z myślą o osobach, które same eksperymentują z AI — niekoniecznie programistach. Każdy techniczny termin tłumaczę przy pierwszym użyciu.

Kontekst — prosty problem, długi projekt

O co chodziło: chciałem zbudować narzędzie, które za człowieka wyszukuje w internecie zamienniki produktów. Klient — polska firma hurtowa biorąca udział w przetargach publicznych — co tydzień dostaje od urzędu listę produktów do dostarczenia. Dla każdej pozycji musi udokumentować, że szukał alternatyw na rynku. Pokazać minimum trzy ekwiwalenty z polskich sklepów: producent, model, cena, link do strony konkretnego produktu, krótkie uzasadnienie zgodności z opisem. To wymóg formalny przy zamówieniach publicznych.

Ręcznie: pracownik wpisuje produkt do Google’a, otwiera kilkanaście stron sklepów, porównuje parametry, kopiuje linki i ceny do Excela. Pięć do ośmiu minut na pozycję. Przetargi mają po pięćdziesiąt do stu pozycji. Cały dzień, czasem dwa, idzie na ręczne klikanie.

Pozornie prosta sprawa do automatyzacji. „Niech AI to zrobi za człowieka.” W praktyce, w skrócie:

Prawnik klienta pyta dlaczego cena na liście nie zgadza się ze stroną producenta. Bo Perplexity (jedna z usług AI którą używałem) wymyśliła cenę. To się nazywa „halucynacja modelu” — model AI generuje pewnie brzmiącą informację, która nie ma pokrycia w rzeczywistości.
Sklep zwraca błąd przy próbie automatycznego sprawdzenia oferty. Allegro blokuje na poziomie zabezpieczeń antybotowych. Ceneo wymaga uruchomienia JavaScriptu, którego standardowe narzędzia nie odpalają. Standardowe sposoby pobierania danych ze stron padają.
Klasyfikator (kawałek systemu, który rozpoznaje typ opisu produktu) nie odróżnia „router do światłowodu” od „routery światłowodowe”. Dla narzędzia analizy treści to są różne frazy. Model w odpowiedzi komponuje absurdy w stylu „światłowodowe Wi-Fi” — co technicznie jest bzdurą, bo Wi-Fi i światłowód to dwa różne sposoby przesyłania sygnału.
Klient czeka na wynik dla 220 produktów do końca tygodnia. Codzienny mail „jak idzie?”.

Wstępna wycena: trzy dni roboty. Realny czas: ponad miesiąc. Pomiędzy tymi dwoma liczbami mieści się te pięć lekcji. Każda kosztowała mnie konkretne pieniądze, godziny i jedną nieprzespaną noc.

Lekcja 1: nie ulepszaj tego, co działa, zanim nie odtworzysz tego co działa

Co się stało

Pierwsza wersja narzędzia istniała w N8N — to platforma, która pozwala budować „przepływy” zadań przez układanie klocków na ekranie, bez pisania kodu. Każdy klocek to jedno zadanie: „wyszlij zapytanie do AI”, „pobierz stronę”, „zapisz do bazy”. Łączysz je strzałkami w określonej kolejności.

Mój przepływ wyglądał tak:

Klocek 1A: wyślij krótkie zapytanie do AI „co to za produkt” (z krótkim opisem ~400 znaków)
Klocek 1B: wyślij krótkie zapytanie „znajdź ceny w sklepach”
Klocek 2: wyślij zapytanie analizujące zgodność z opisem
Klocek 3: sprawdź czy linki ze sklepów żyją (otwórz każdy w tle)

Działało. 92% produktów dostawało prawidłowe wyniki: trzy linki do konkretnych ofert z cenami. Wolno (40-50 sekund na jeden produkt), ale poprawnie. Wzorzec dojrzewał miesiącami w pierwotnej wersji — ktoś już wcześniej znalazł i wygładził dziwne przypadki.

Pomyślałem oczywistą rzecz: „Skoro N8N jest powolne, przepiszę to na własny, mały serwer. Cztery zapytania zamienię w jedno duże, oszczędność czasu i pieniędzy, te same dane wejściowe, te same wyjściowe.” Wyglądało jak banalna przeróbka.

Wynik: model się gubił. Długie zapytanie powyżej trzech tysięcy znaków, z całą procedurą krok po kroku, wprowadzało AI w „tryb analizy” zamiast „trybu wyszukiwania”. Zamiast szukać w sklepach, model cytował generyczne źródła prawnicze (ustawy, gov.pl), bo „to przecież temat o przetargach”. Skuteczność spadła z 92% na 77%. Cofałem się przez cztery dni — zmieniałem zapytanie, próbowałem różnych formatów, wymuszałem konkretną strukturę odpowiedzi — zanim wróciłem do trzech osobnych zapytań. I wtedy 92% wróciło natychmiast.

Dlaczego tak wyszło

Działający przepływ ma ukryte detale. Ktoś już raz złapał, że krótkie zapytanie daje bardziej przewidywalne wyniki niż długie. Ktoś już raz odkrył, że jak połączysz wyszukiwanie produktu z wyszukiwaniem ceny w jeden krok, AI miesza te dwa zadania i daje słabszy wynik na obu. Te decyzje nie były losowe — miały za sobą historię, której nie znałem, bo wszedłem do projektu z gotowym narzędziem.

„Optymalizacja” bez zrozumienia, skąd te decyzje się wzięły, to nie optymalizacja — to pogorszenie jakości pod nazwą porządkowania.

Reguła

Jeśli przerabiasz coś, co już działa, najpierw odtwórz dokładnie to, co działało — nawet jeśli wygląda na nieoptymalne. Zmierz, że nowa wersja daje takie same wyniki jak stara. Dopiero potem optymalizuj — każdą zmianę traktuj jako osobny eksperyment z porównaniem do punktu wyjścia.

Co konkretnie zrobić

Zanim cokolwiek zmienisz w działającym rozwiązaniu, zadaj sobie trzy pytania:

Co w mojej propozycji NIE jest w oryginale? Każda zmiana musi mieć uzasadnienie — wynikać z konkretnego wymagania, nie z estetyki („ładniej będzie tak”).
Czy mam punkt odniesienia? Skuteczność oryginału wyrażona w liczbach. Jeśli nie wiesz, że oryginał miał 92% trafień, nie wiesz, czy nowa wersja jest lepsza, gorsza, czy taka sama.
Czy wiem, dlaczego oryginał był zrobiony właśnie tak? Jeśli na pytanie „czemu to zapytanie ma akurat 400 znaków” odpowiadasz „no, krótko jest dobrze” — nie znasz wzorca wystarczająco, żeby go zmieniać.

Czas na sprawdzenie tych trzech rzeczy: dwie godziny. Zaoszczędzony czas, jeśli pomijasz: cztery dni. Bilans jest jednoznaczny.

Lekcja 2: testuj na pięciu produktach, nie na dwustu

Anatomia drogiego błędu

Dwie fazy iteracji nad zapytaniem dla AI. Pierwsza była drogą szkołą.

Faza pierwsza, błędna: po każdej zmianie zapytania uruchamiałem przetwarzanie wszystkich 220 produktów. „Skoro już AI pracuje, niech od razu sprawdzi na realnych danych — będę miał pełny obraz.” Każde takie uruchomienie kosztowało około 5 dolarów (trzy zapytania na produkt × 220 produktów). Dwadzieścia minut po kolei albo pięć minut, jeśli puszczałem równolegle po pięć naraz.

Po ośmiu próbach: 40 dolarów wydane, jakość gorsza niż na początku. Wszystko się skumulowało — nie wiedziałem, która konkretna zmiana dała pogorszenie. Czy to halucynacja AI (te same dane wejściowe potrafią dać różne wyniki w różnych dniach), czy zmiana po stronie zewnętrznej usługi, czy moje zapytanie. Wieczorem stwierdziłem, że muszę zacząć od zera, z innym podejściem.

Faza druga, poprawna: zacząłem od pięciu wybranych produktów. Wybranych, nie losowych. Zaprojektowałem dobór tak, żeby każdy reprezentował inny typ przypadku:

Jeden z konkretną marką i numerem modelu w opisie (np. „Bayersystem WB-50”) — szukamy dokładnie tego
Jeden z ogólnym opisem bez marki (np. „rękawice antystatyczne XL”) — szukamy alternatyw od różnych firm
Jeden niszowy, mała szansa znalezienia w polskich sklepach (np. „pędzel detalingowy 16mm”)
Jeden trudny przypadek (zestaw zbiorczy z 129 elementów)
Jeden z podpowiedzią od klienta („sugerowany produkt: 3M DUCK TAPE 1900”)

Każde uruchomienie na tej piątce kosztowało około 10 centów. Mogłem zmienić zapytanie, sprawdzić wyniki w 30 sekund, wycofać się jeśli było gorzej, próbować ponownie. Jakość zaczęła iść w górę. Gdy próbka dawała sensowne wyniki we wszystkich pięciu typach, rozszerzałem na 20 produktów dla weryfikacji wzorca. Dopiero potem przetwarzanie wszystkich 220.

Łączny koszt fazy drugiej: około 3 dolarów na próbki + jedno duże uruchomienie potwierdzające. Razem 8 dolarów zamiast 40 z fazy pierwszej. I jakość znacznie lepsza.

Reguła

Nigdy nie uruchamiaj przetwarzania większego niż pięć rekordów bez wcześniejszej akceptacji próbki. Nawet jeśli zmiana wygląda na drobną poprawkę. AI, narzędzia pobierające dane ze stron, ograniczenia zewnętrznych usług — wszystko jest niedeterministyczne. Coś, co wydaje się „drobne”, potrafi popsuć cały batch.

Test pięciu sekund

Przed uruchomieniem czegokolwiek na więcej niż pięciu pozycjach zadaj sobie jedno pytanie:

„Co się stanie, jeśli błąd dotknie połowy wyników?”

Jeśli odpowiedź to „stracę godzinę pracy plus 5 dolarów plus zaufanie klienta, którego nie chcę denerwować” — próbka idzie pierwsza. Jeśli odpowiedź to „machnę ręką, sprawdzę inny pomysł, nikt nie patrzy” — możesz lecieć od razu. W praktyce, jeśli płacisz za AI lub jakąkolwiek usługę zewnętrzną, pierwsza odpowiedź jest poprawna w dziewięciu na dziesięć przypadków.

Jak konkretnie wybrać te pięć

Najważniejsza zasada: dobieraj po typach, nie losowo. Losowa próbka jest złudnie reprezentatywna — w pięciu pozycjach trafisz tylko najbardziej typowe przypadki. Nietypowe (które najprawdopodobniej Cię zaskoczą) są w mniejszości w bazie, więc losowo je pominiesz.

Zamiast tego: zidentyfikuj cztery do sześciu typów przypadków (krótki opis vs długi, polski vs angielski, z marką vs bez marki, z hintem vs bez), i bierz po jednym z każdego typu. Ta sama metoda działa w batchu 50 (po 5-7 z każdego typu) i w batchu 500 (po 50-70).

Lekcja 3: zapisuj surowe odpowiedzi, naprawiaj na bazie tego co masz

Decyzja, której nie żałuję

Jedna decyzja zrobiona na początku okazała się kluczowa, choć nie wiedziałem o tym wtedy: każde wywołanie zewnętrznej usługi AI zapisuję do specjalnej kolumny w bazie danych. Nie tylko końcowy wynik, ale całą surową odpowiedź — co wysłałem, co dostałem, status, czas wykonania.

Po ludzku: baza danych to coś jak wielki Excel, z którym rozmawia program. Każdy produkt ma swój wiersz. W wybranej kolumnie zapisuję, dla każdego produktu, dokładnie to, co AI mi odpowiedziała przy ostatnim wyszukiwaniu. Pełną odpowiedź, nie tylko wybrany fragment.

Pierwotnie pomyślane jako „audyt na potem” (gdyby klient pytał, skąd dany wynik). Nieoczekiwanie zmieniło sposób, w jaki naprawiam błędy.

Konkretny przypadek, który pokazał wartość

W którymś momencie odkryłem 32 produkty z błędnymi wynikami:

Część miała link do strony kategorii (np. „narzędzia ręczne” — cała sekcja sklepu) zamiast strony konkretnego produktu
Część miała ceny niezgodne ze stroną — AI podawała cenę o 100-400 złotych wyższą niż faktyczna na stronie
Kilka miało linki ułożone w złej kolejności — droższe oferty wyżej niż tańsze

Pierwszy odruch: „Niech AI poszuka jeszcze raz dla tych 32 produktów.” Szybkie liczenie kosztu i czasu:

32 produkty × kilka zapytań = około 1,60 dolara czystego API
Plus ryzyko: AI bywa nieprzewidywalna. To samo zapytanie w innym dniu daje inny wynik. Możliwe, że naprawię 32, a popsuję 5 innych. Z buforem na drugą próbę: ~5 dolarów efektywnie
Czas: 30 minut przetwarzania + drugie tyle na sprawdzenie wyników

Drugi pomysł — lepszy

Zamiast prosić AI ponownie, napisałem mały skrypt (kawałek programu w języku Python — nie wymaga zewnętrznych usług, działa lokalnie na komputerze). Skrypt czyta zapisane wcześniej surowe odpowiedzi z bazy danych — bez wywoływania AI po raz drugi — i przefiltrowuje je po nowych, lepszych regułach wyboru. Następnie aktualizuje wyniki w bazie.

Cała logika wyboru wyników jest w skrypcie, nie w AI. Skrypt mogę uruchomić sto razy — za każdym razem da ten sam wynik. AI uruchomiona sto razy daje sto różnych wyników.

Czas pisania skryptu: trzy godziny (z testami na pięciu produktach). Czas wykonania na 32 produktach: pięć minut. Koszt zewnętrznych usług: zero. Wynik: 32 produkty naprawione, klient dostał około 880 złotych oszczędności na różnicy cen wybranych ofert (skrypt wybrał tańsze, prawidłowe oferty, których AI wcześniej nie wyłapała).

Reguła

Zanim poprosisz AI o ponowne wykonanie pracy, sprawdź czy nie masz już wszystkiego, czego potrzebujesz w bazie. Jeśli zapisujesz surowe odpowiedzi (a powinieneś), 80% błędów rozwiążesz analizą tego, co już masz, bez ponownego wywoływania AI.

Trzy zalety naprawy lokalnej nad ponownym uruchomieniem AI

Powtarzalność. Skrypt da zawsze ten sam wynik dla tych samych danych. AI w innym dniu może dać inny wynik dla tego samego zapytania — szczególnie dla niszowych produktów, gdzie indeks AI zmienia się dynamicznie.

Koszt. Zero zapytań do AI = zero dolarów. Dla projektów, gdzie iterujesz logikę wyboru 10-20 razy zanim trafisz na właściwą, oszczędności są realne.

Pełna historia. Jeśli klient pyta „skąd ta cena?”, możesz pokazać dokładny moment, w którym AI to zwróciła, plus reguły, które zastosowałeś. Ponowne uruchomienie AI gubi tę historię — nadpisujesz dane.

Pierwsza rzecz do wprowadzenia w nowym projekcie

Dodaj do każdej tabeli w bazie kolumnę, która zapisuje surowe odpowiedzi z każdego wywołania AI. Jedna linia w schemacie bazy. Logowanie do tej kolumny to dwie do trzech linii kodu w funkcji, która rozmawia z AI. Bez tego tracisz większość możliwości naprawiania błędów bez ponoszenia kosztów.

Lekcja 4: drugi model AI jako recenzent i jako adwokat diabła

Ta lekcja ma dwie warstwy. Pierwszą znają wszyscy, drugą rzadziej — i to ta druga ratowała mnie najczęściej.

Warstwa pierwsza: recenzja przez drugi model

Pracujesz z jednym AI nad pomysłem (u mnie Claude, asystent Anthropic). Wklejasz wynik — kod albo plan — do drugiego AI z poleceniem „przejrzyj to, wskaż trzy największe ryzyka”. Najtańsze rozwiązanie: lokalny model na własnym komputerze, np. Qwen przez narzędzie Ollama (instalacja jednorazowa, potem darmowo).

Po ludzku: Ollama to taka aplikacja na komputer, która pozwala uruchomić AI lokalnie — bez internetu, bez płacenia za zapytania. Pobierasz raz model (kilkanaście gigabajtów), instalujesz, i potem masz „drugiego asystenta AI” pod ręką. Działa szybko na nowszych Macach (M1, M2, M3).

Sposób użycia jest prosty:

# Jednorazowy setup (instalacja Ollama z internetu)
curl -fsSL https://ollama.com/install.sh | sh

# Pobranie modelu (jednorazowo, około 22 GB)
ollama pull qwen3.6:35b-a3b

# Recenzja przez API lokalne (port 11434)
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3.6:35b-a3b",
  "prompt": "Przejrzyj poniższy plan. Wskaż 3 największe ryzyka. PLAN: [tutaj wklej plan]",
  "stream": false
}'

Odpowiedź dostajesz w 2-3 minuty. Koszt: zero. Drugi model wyłapuje typowe błędy — niezabezpieczone rzadkie przypadki, sprzeczność z istniejącym kodem, brak obsługi błędów. Jak recenzja w zespole, tylko że masz drugiego „kolegę z pracy” w kieszeni dostępnego non-stop.

Ale jest jedno fundamentalne ograniczenie: drugi model nie wie, czego nie wie. Daje recenzję na to, co widzi w kodzie. Jeśli kod jest ładny strukturalnie, ale logika biznesowa jest źle przemyślana — drugi model często to przegapi, bo nie zna domeny.

Warstwa druga: adwokat diabła (silniejsze, mniej znane)

Zamiast wklejać kod i pytać „co jest nie tak”, wklejasz plan albo opis problemu i prosisz drugi model, żeby zadał Ci pięć najtrudniejszych pytań, które ujawnią luki w Twoim podejściu.

Potem odpowiadasz na każde pytanie. Połowa odpowiedzi okaże się słaba — nie wiesz, nie pomyślałeś o tym, masz wątpliwości, „to się jakoś rozwiąże w trakcie”. To są właśnie miejsca, w których projekt się wywali, jeśli zaczniesz pisać kod bez ich domknięcia.

Konkretny przypadek z tego projektu

Zaprojektowałem dwie różne ścieżki w narzędziu, w zależności od typu opisu produktu. Ścieżka A — gdy w opisie jest konkretna marka i model (np. „Bayersystem WB-50”); szukamy dokładnie tego. Ścieżka B — gdy opis to tylko parametry („rękawice antystatyczne XL”); szukamy alternatyw od różnych firm. Pomysł wydawał się gotowy, miałem już strukturę kodu w głowie.

Otworzyłem terminal z lokalnym Qwen i napisałem:

„Zaprojektowałem narzędzie z dwiema ścieżkami. Ścieżka A — gdy w opisie jest marka i model. Ścieżka B — gdy opis to tylko parametry. Wciel się w rolę doświadczonego inżyniera, który NIE chce, żeby to weszło na produkcję bez krytycznej analizy. Zadaj mi pięć najtrudniejszych pytań, które ujawnią luki, niedopowiedzenia lub nieprzemyślane scenariusze. Bądź konkretny, nie ogólnikowy. Pytania mają być takie, że jeśli nie umiem na nie odpowiedzieć, projekt się wywali w jakimś momencie.”

Qwen zwrócił między innymi:

„Jak rozpoznasz, że opis jest 'konkretny’ vs 'ogólny’? Jaki próg pewności? Co, jeśli opis ma cechy obu?”
„Co, jeśli rozpoznawanie zaklasyfikuje błędnie? Czy ścieżka A może 'spaść’ do B i odwrotnie?”
„Co z opisami, które mają 'sugerowany produkt: X’ — są konkretne czy ogólne?”
„Jak unikasz duplikatów, gdy obie ścieżki znajdą ten sam produkt?”
„Czy próg pewności jest ten sam dla każdej kategorii produktów? Bo elektronika ma inne opisy niż chemia.”

Te pytania ujawniły trzy kluczowe błędy projektu, zanim napisałem linijkę kodu:

Brak planu B dla niepewnych przypadków — dodałem regułę „jeśli pewność niska, idziemy ścieżką B (więcej alternatyw, bezpieczniej)”
Brak usuwania duplikatów — dodałem łączenie wyników z obu ścieżek z usuwaniem powtarzających się pozycji
Brak obsługi „sugerowanego produktu” — dodałem specjalną logikę dla tego przypadku

Gdybym zaczął pisać kod bez tej rozmowy, te problemy złapałbym dopiero przy uruchomieniu na 220 produktach. Pewnie kosztem kilku iteracji i kolejnych dolarów na AI. Pewnie 4-5 godzin pracy plus realne koszty.

Rozmowa z Qwen zajęła 12 minut.

Reguła

Zanim zaczniesz pisać kod do czegoś nietrywialnego, otwórz drugi model i poproś go o przesłuchanie. To 5-15 minut, które oszczędzają 5-15 godzin. Im wcześniej, tym taniej — pytania zadane przed pisaniem kodu kosztują rozmowę. Pytania zadane po wypuszczeniu na produkcję kosztują wycofywanie i zaufanie klienta.

Wzór polecenia do skopiowania

Przedstawiam Ci [plan / projekt / decyzję].

Twoja rola: doświadczony inżynier, który NIE chce, żeby to weszło
na produkcję bez krytycznej analizy. Zadaj mi pięć najtrudniejszych
pytań, które ujawnią luki, niedopowiedzenia lub nieprzemyślane
scenariusze.

Bądź konkretny, nie ogólnikowy. Pytania mają być takie, że jeśli
nie umiem na nie sensownie odpowiedzieć, projekt się wywali w
jakimś momencie.

Po moich odpowiedziach zadaj pytania pogłębiające, jeśli któraś
odpowiedź wydaje się słaba.

[PLAN/PROJEKT]:
[wklej tutaj]

To jest sposób pracy, nie konkretne narzędzie — możesz go zastosować z każdym AI, które masz pod ręką. Działa najlepiej z modelem od innego dostawcy niż ten, z którym pisałeś plan: Claude pisze, Qwen lub Gemini przesłuchuje. Inny model = inny zestaw uprzedzeń = inny zestaw pytań.

Lekcja 5: notatki z projektu jako mapa, nie biurokracja

Najpierw byłem sceptyczny

Przez sto godzin projektu napisałem kilkadziesiąt krótkich notatek końca sesji (zapisy stanu po każdym dniu pracy), kilkanaście wpisów „czego się nauczyłem” w pliku konfiguracyjnym projektu, dziesiątki notatek do globalnej pamięci asystenta AI. Na początku traktowałem to jak biurokrację — „po co pisać podsumowanie, skoro za chwilę i tak wracam do tego samego zadania”.

Po dwóch tygodniach okazało się, że to nie biurokracja. To mapa nawigacyjna projektu, której nie ma nikt inny — bo asystent AI w nowej sesji zaczyna od zera (nie pamięta wczorajszej rozmowy), a Ty nie zapamiętasz wszystkich szczegółów.

Konkretny przykład

Wieczorem kończę sesję pracy po sześciu godzinach. Zapisuję krótką notatkę w pliku — co zrobiłem, co zostało, jakie są przeszkody, jaka pierwsza akcja jutro. Pięć do siedmiu minut pisania.

Następnego dnia rano otwieram nową sesję pracy z asystentem AI. Nowy „egzemplarz” asystenta, kontekst z wczoraj zniknął. Wpisuję jedno słowo: „wznów”.

Asystent (skonfigurowany odpowiednim „skillem”, czyli zestawem instrukcji co ma robić) automatycznie czyta najnowszą notatkę, sprawdza historię zmian w projekcie, zagląda do globalnej pamięci. W pierwszych 30 sekundach wie:

„Wersja 19 zakończona. 222 produkty zwalidowane, zero krytycznych błędów. Pliki w katalogu Downloads — NIE MODYFIKOWAĆ. Czeka wizualna ocena Dariusza, NIE wysyłaj nic do klienta bez zgody. Pierwsza akcja: otwórz raport z próbką do akceptacji i poprowadź użytkownika przez weryfikację.”

Zacząłem pracę bez fazy „ah, gdzie to było”. Ten układ zadziałał kilkanaście razy w tym projekcie. Każdym razem oszczędność 20-30 minut na „ponowne wczytanie się w kontekst” plus zero ryzyka pomyłki („a, miałem zrobić X” — nie, miałeś NIE robić X bez zgody klienta).

Trzy rodzaje notatek, które się sprawdziły

1. Notatka końca sesji

Krótki dokument — co zrobiłem, co zostało, jaki jest stan, jaka pierwsza akcja w nowej sesji. Plik ląduje w specjalnym katalogu projektu, np. .ai/handoffs/ z datą i krótkim tytułem. Zawsze do pliku, nigdy „tylko na ekranie chatu” — bo ekran znika z kontekstu, a plik zostaje.

Wzór, który mi się sprawdził:

# Notatka YYYY-MM-DD HH:MM — [krótki tytuł]

**Stan:** aktywny / stabilny / zawieszony

## Co zostało zrobione
- [punkt 1, najlepiej z odniesieniem do pliku]
- [punkt 2]

## Co zostało do zrobienia
- [konkretne zadanie, najlepiej z plikem i numerem linii]

## Przeszkody / decyzje czekające
- [jeśli są]

## Pierwsza akcja w nowej sesji
[1-2 zdania: co dokładnie zrobić jako pierwsze]

## Czego nie ruszać
- [pliki/dane, których NIE wolno modyfikować]

2. Wnioski z błędów („Lessons Learned”) per projekt

Sekcja w pliku konfiguracyjnym projektu. Format:

## Lessons Learned

- [DATA] KONTEKST: Co poszło nie tak → Co robić zamiast tego.

Tylko konkretne, praktyczne lekcje — nie ogólniki. Po sesji z błędem, którego naprawa zajęła więcej niż jedną próbę, dopisuję jedną linijkę. Przy starcie nowej sesji to pierwsze miejsce, do którego asystent zagląda.

Przykłady z mojego pliku w tym projekcie:

„[2026-04-28] AI ZWRACA WIĘCEJ NIŻ WIDAĆ W BAZIE: niszowe produkty dostają od AI po 9-15 ofert łącznie. Walidacja odrzuca większość (zła cena, link 404, kategoria zamiast produktu). Gdy klient pyta 'czemu nie ma trzeciej oferty’ — odpowiedź zazwyczaj NIE 'AI nie znalazł’, tylko 'walidacja odrzuciła z powodu X’. Najpierw sprawdź zapisane surowe odpowiedzi, potem debuguj.”

„[2026-04-29] Kiedy uruchamiasz wiele zadań równolegle, ryzyko zawieszenia rośnie z liczbą produktów na zadanie: 11 produktów na zadanie → 40% zawieszeń. 4-7 produktów → 0% zawieszeń. Reguła: dziel paczki na maksymalnie 7 pozycji.”

Każda jednolinijka — wartość liczy się w skali tygodni.

3. Globalne preferencje (działają w każdym projekcie)

Globalne preferencje komunikacyjne, antywzorce, decyzje, które chcesz, żeby asystent stosował zawsze, niezależnie od projektu. Pliki w globalnym katalogu pamięci asystenta. Przykłady:

„Nie używaj formatowania Markdown w mailach do klientów” — asystent automatycznie przełącza się na zwykły tekst, gdy generuje treści dla klienta zewnętrznego
„Zawsze 'Panie Pawle’ + Pan/Pana/Panu w mailach do klienta” — formy grzecznościowe, nie skrót na 'cześć’
„Przy estymacji czasu pracy, podawaj realny czas plus bufor osobno” — żeby nie mieszać zegara wewnętrznego z kalendarzem klienta

Skill auto-pamięci czyta to przy każdej sesji niezależnie od projektu. Setup raz, działa wszędzie.

Reguła

Jeśli projekt jest dłuższy niż dwa tygodnie, zaczynasz tracić kontekst po trzech dniach przerwy. Notatki to nie biurokracja — to pamięć, której asystent AI nie ma. Trzy minuty pisania notatki = trzydzieści minut oszczędzonych przy powrocie. Powtórz to 30 razy w trakcie projektu — masz 15 godzin oszczędzonych.

Setup w nowym projekcie (5 minut)

Utwórz katalog .ai/handoffs/ w repozytorium projektu
Dodaj sekcję „Lessons Learned” w pliku konfiguracyjnym projektu (np. CLAUDE.md)
Ustal zasadę: „kończę sesję — piszę notatkę. Robię błąd kosztujący więcej niż jedną próbę — dopisuję wniosek”
Zapisz pierwszą notatkę (nawet krótką) — żeby asystent w nowej sesji widział, że konwencja istnieje

Reszta przyjdzie sama. Po pierwszym razie, gdy asystent w nowej sesji bez wahania kontynuuje od miejsca, w którym skończyłeś — zrozumiesz, dlaczego to działa.

Co z tego brać

Te pięć lekcji nie jest spójną metodologią ani frameworkiem. To pięć rzeczy, które zrobiłbym inaczej, gdybym zaczynał ten projekt dzisiaj. Patrząc wstecz, mógłbym oszczędzić 30-40 godzin pracy i 200-250 dolarów kosztów, gdybym wiedział o nich od pierwszego dnia.

Jeśli zaczynasz pierwszy duży projekt z AI, trzy rzeczy od pierwszego dnia:

Pierwsza: zapisuj surowe odpowiedzi z AI

Do każdej tabeli w bazie, która rozmawia z AI, dodaj kolumnę zapisującą pełną odpowiedź. Logowanie to 2-3 linie kodu w funkcji wywołującej AI. Bez tego tracisz większość możliwości naprawiania błędów bez ponoszenia kosztów. Najtańsza decyzja architektoniczna, jaką możesz podjąć.

Druga: nigdy bez próbki

Nigdy nie uruchamiaj przetwarzania większego niż pięć rekordów bez wcześniejszej akceptacji próbki. Nawet jeśli zmiana wygląda na drobną poprawkę. Test pięciu sekund: „co się stanie, jeśli błąd dotknie 50%?”. Odpowiedź zazwyczaj wymaga próbki przed pełnym uruchomieniem.

Trzecia: notatki końca sesji od pierwszego dnia

Po każdej sesji — trzy minuty na krótką notatkę. Po każdym błędzie kosztującym więcej niż jedną próbę — jedna linijka w „Lessons Learned”. To pamięć, której AI nie ma, a której potrzebujesz w projekcie dłuższym niż dwa tygodnie.

I czwarta, na końcu, najważniejsza

Nie traktuj AI jak „tańszego pracownika”. Traktuj jak partnera, który ma talent, ale nie ma kontekstu. Twoim zadaniem jest dać mu kontekst (notatki), narzędzia (lokalna AI do recenzji, baza danych z surowymi odpowiedziami), system pamięci (notatki końca sesji, lessons learned), drugiego asystenta do kwestionowania pomysłów (recenzent, adwokat diabła). Wtedy działa wielokrotnie szybciej niż człowiek — natomiast tylko wtedy.

Sto godzin nad jednym narzędziem brzmi jak dużo. Ale po tych godzinach mam rzecz, która oszczędza klientowi tygodnie pracy w każdym przetargu — a sam wiem, jak zrobić następne narzędzie w połowie tego czasu. To jest, jak sądzę, sensowna inwestycja. Pod warunkiem, że po drodze popełnisz lepsze błędy niż ja.

Powodzenia.

Do tego artykułu jest też osobny Toolkit — gotowe wzory notatek, polecenia do skopiowania, drzewo decyzyjne („kiedy co robić”) i 30-minutowy plan startowy dla nowego projektu.