Jak poprawiać rezultaty AI w czasie

Problem, o którym nikt nie mówi po udanym demie

Większość zespołów wdraża agenta AI tak samo: udane demo, fala entuzjazmu, a potem ciche utknięcie w miejscu. Agent powiela te same rodzaje błędów miesiąc po miesiącu. Pisze od nowa funkcję pomocniczą, która już istnieje. Sięga po bibliotekę porzuconą dwa lata temu. Dowozi kod tylko dla happy path, bez obsługi błędów. Wszyscy to widzą. Nikt tego systematycznie nie naprawia.

Oto niewygodna prawda: agent AI sam z siebie nie staje się lepszy w twoim konkretnym kodzie albo procesie. Model pod spodem poprawia się w harmonogramie producenta, nie twoim. To, co odróżnia agenta, który frustruje zespół w nieskończoność, od takiego, który dochodzi do jakości silnego inżyniera, to świadoma, powtarzalna pętla doskonalenia - i dyscyplina, żeby faktycznie ją domykać.

Dwa wydarzenia, jedno po drugim

Mechanizm to dwa krótkie, oddzielne wydarzenia, zwykle tego samego dnia. Pierwsze znajduje wzorce; drugie na nie reaguje. Trzymanie ich osobno ma znaczenie - mieszanie odkrywania z podejmowaniem decyzji prowadzi do pośpiesznych poprawek problemów, których nigdy nie potwierdzono jako realne.

Na początek rób oba co dwa tygodnie. Gdy system doskonalenia się ustabilizuje - zwykle po czterech do sześciu miesiącach - oba można przestawić na raz w miesiącu. Częstotliwość to decyzja sytuacyjna: za często, a zmieniasz rzeczy, zanim zobaczysz, czy poprzednia zmiana zadziałała; za rzadko, a słabe zachowanie trzyma się dłużej, niż musi.

Warunek wstępny: nawyk notatek roboczych

Żadne z wydarzeń nie zadziała bez tego. To najtańsza część systemu i ta, którą zespoły najczęściej odpuszczają - a jej odpuszczenie po cichu wyłącza wszystko, co dalej.

Między sesjami każdy członek zespołu zapisuje krótkie notatki robocze na bieżąco. Nie formalny dokument - kilka punktów przed zamknięciem ticketu wystarczy. Liczy się treść, nie forma. Warto zapisać cztery rzeczy:

• Co AI zrobiło dobrze w tej iteracji - konkretne momenty, nie ogólne pochwały. „Wygenerowało zestaw testów, który wyłapał realny przypadek brzegowy" jest przydatne; „było pomocne" nie.
• Co zrobiło źle albo czego nie zrobiło - gdzie wymagało więcej poprawek, niż się spodziewałeś, albo poszło w złą stronę.
• Konkretne halucynacje - wynik prawdopodobny, ale błędny: kod, który wyglądał dobrze, a nie działał; test, który przechodził, ale sprawdzał nie to, co trzeba; dokumentacja sprzeczna z implementacją. Bądź precyzyjny: co zostało wygenerowane, co było w tym złego, jak wyglądała poprawna wersja.
• Każda technika, która zadziałała lepiej, niż się spodziewałeś - wzorzec promptu albo specyfikacji wart powtórzenia.

Wydarzenie pierwsze - polowanie na wzorce (20–25 minut)

Jedno wystąpienie błędu AI to szum. Ten sam błąd w pracy kilku osób - albo wielokrotnie u jednej - to sygnał. Polowanie na wzorce ma jedno zadanie: odróżnić jedno od drugiego. Nic się tu nie naprawia; naprawianie jest dalej.

1. Każdy krótko przedstawia obserwacje ze swoich notatek - najważniejsze punkty, nie czytanie wszystkiego. „Ciągle generowało nowe funkcje pomocnicze zamiast użyć istniejących." „Każda specyfikacja bez jawnych stanów błędów dawała złą obsługę błędów."
2. Prowadzący zapisuje powtarzające się motywy na wspólnej tablicy w miarę, jak spływają obserwacje.
3. Zespół potwierdza, które obserwacje są realnymi wzorcami - pojawiają się u więcej niż jednej osoby albo więcej niż raz u tej samej.
4. Pojedyncze wystąpienia są notowane, ale jeszcze nie naprawiane. Obserwujemy je, nie naprawiamy.

Wydarzenie drugie - retrospektywa AI (40–60 minut)

Tu potwierdzone wzorce stają się trwałymi poprawkami. Przebiega w czterech krokach, a pominięcie któregokolwiek psuje pętlę. Najczęstszy błąd to przeskok od razu do poprawek bez wcześniejszego zdiagnozowania przyczyny źródłowej - co wysyła poprawkę w złe miejsce.

Krok 1 - Sklasyfikuj każdy wzorzec (5–10 min)

Zanim zdecydujesz o jakiejkolwiek poprawce, sklasyfikuj każdy potwierdzony wzorzec. Właściwa poprawka zależy w całości od przyczyny źródłowej, a trzy przyczyny wymagają zupełnie różnych reakcji:

Kategoria	Co znaczy	Poprawka
Luka w wiedzy	Agent nie zna reguły, którą powinien stosować	Dodaj albo zaktualizuj jawną regułę w stałym kontekście agenta
Luka w specyfikacji	Agent zachował się źle, bo specyfikacja była niedospecyfikowana	Popraw szablon specyfikacji albo listę kontrolną kompletności
Granica możliwości	Zadanie leży na granicy tego, co model robi niezawodnie	Skieruj ten typ zadania do mocniejszego modelu albo dodaj dodatkowe elementy walidacji rezultatu

Krok 2 - Zaktualizuj definicję agenta albo instrukcję (20-30 min)

Dla każdej potwierdzonej luki w wiedzy zespół wspólnie decyduje, jaką regułę dodać. To decyzja na poziomie produktu, nie indywidualna preferencja - każda zmiana jest omówiona, uzgodniona i wrzucona, zanim sesja się skończy. Dobre reguły są konkretne i sprawdzalne. Prawdziwe przykłady reguł, jakie rodzi ta pętla:

• „Zawsze sprawdź, czy funkcja pomocnicza już istnieje, zanim utworzysz nową."
• „Ten kod zarządza stanem istniejącym mechanizmem kontekstu - nie wprowadzaj drugiej biblioteki do stanu."
• „Gdy specyfikacja zawiera limit zapytań, zawsze zaimplementuj jego stan błędu obok happy path."
• „Nie buduj nowej warstwy komunikatów, gdy stan aplikacji już pokrywa potrzebę."

Krok 3 - Przejrzyj szablon specyfikacji (5–10 min)

Dla każdej potwierdzonej luki w specyfikacji zdecyduj, czy lista kontrolna kompletności potrzebuje nowej pozycji. Lista jest bramką przed kodowaniem - jeśli klasa błędów wynika z luki w liście, domknij ją, zanim przejdzie przez nią następna historyjka. Częste dodatki:

• „Zawsze sprawdź, czy funkcja pomocnicza już istnieje, zanim utworzysz nową."
• „Ten kod zarządza stanem istniejącym mechanizmem kontekstu - nie wprowadzaj drugiej biblioteki do stanu."
• „Gdy specyfikacja zawiera limit zapytań, zawsze zaimplementuj jego stan błędu obok happy path."
• „Nie buduj nowej warstwy komunikatów, gdy stan aplikacji już pokrywa potrzebę."
• „Stany błędów są jawnie zdefiniowane dla każdego wywołania zewnętrznego."
• „Punkty integracji są nazwane wprost, a nie opisane ogólnikowo."
• „Możliwości poza zakresem są nazwane, a nie domyślne."

Krok 4 - Zweryfikuj zmiany z poprzedniej sesji (5 min)

Czy zmiany z poprzedniej retrospektywy faktycznie zadziałały? Każdy krótko mówi, czy reguła albo zmiana, którą zastosował, dała oczekiwaną poprawę. Ten krok odróżnia realny system doskonalenia od spotkania, które produkuje dobre chęci i o nich zapomina.

Reguły, dzięki którym to działa

Każda reguła, za każdym razem

• Każda zmiana jest konkretna. „Popraw jakość kodu" to nie reguła, którą agent może zastosować. „Sprawdź, czy funkcja pomocnicza już istnieje, zanim utworzysz nową" - owszem.
• Każda poprawka trafia do właściwej warstwy. Luki w wiedzy do kontekstu, luki w specyfikacji do listy kontrolnej, granice możliwości do kierowania zadań. Zła warstwa, zmarnowany wysiłek.
• Konsekwencja to cała gra. Zespół, który konsekwentnie robi to, co zapowiedział, buduje kulturę, w której retrospektywa napędza realną zmianę. Zespół, który tego nie robi, buduje kulturę, w której retrospektywa jest teatrem.

Rób retrospektywę nawet wtedy, gdy polowanie nic nie znalazło

Czyste polowanie na wzorce to nie powód, żeby odwołać retrospektywę. To znak, że poprzednie poprawki się trzymają - co warto jawnie potwierdzić. Wykorzystaj ten czas na przegląd kondycji nazbieranych instrukcji agenta: czy któreś reguły są już sprzeczne, nieaktualne albo zbędne? Zbiór instrukcji, który tylko rośnie, w końcu zamienia się w szum.

Czego się spodziewać, miesiąc po miesiącu

Najważniejsza rzecz do ustawienia oczekiwań: pierwszy miesiąc sprawia wrażenie powolnego postępu. I tak ma być. Budujesz system korekcji, zanim ma cokolwiek do pokazania. Zespoły, które porzucają pętlę, prawie zawsze robią to w tym pierwszym miesiącu - tuż przed momentem, w którym nakłady zaczynają przynosić efekty.

Okres	Co powinieneś zobaczyć
Miesiąc 1	Idzie wolno. Tworzy się nawyk notatek, wychodzą pierwsze wzorce, powstają pierwsze reguły. Jeszcze mała widoczna zmiana jakości - to faza inwestycji.
Miesiące 2–3	Powtarzające się błędy zaczynają znikać w miarę, jak przybywa reguł. Ta sama halucynacja przestaje wracać. Specyfikacje się poprawiają, bo lista kontrolna chłonie realne dane o awariach. Jakość wyników zaczyna wyraźnie iść w górę.
Miesiące 4–6	Wyniki dochodzą do poziomu silnego inżyniera na waszym kodzie. Częstotliwość można rozluźnić do raz w miesiącu. Nazbierany kontekst i lista kontrolna stały się realnymi aktywami - i najlepszym materiałem wdrożeniowym.

Prosty sposób, żeby wiedzieć, że działa

Nie potrzebujesz wymyślnych metryk. Dwa sygnały mówią ci niemal wszystko. Po pierwsze, tempo nowych potwierdzonych wzorców powinno z czasem spadać - kończą ci się powtarzające się błędy do znalezienia, o co właśnie chodzi. Po drugie, powracające wzorce - problem, który już zaadresowałeś, wracający z powrotem - powinny być rzadkością; gdy któryś wróci, potraktuj to jako flagę, że wcześniejsza poprawka chybiła prawdziwej przyczyny. Pętla, w której nowe wzorce wciąż napływają po kilku miesiącach, zwykle wskazuje na problem z jakością specyfikacji, która karmi agenta złym wsadem szybciej, niż reguły zdążą to nadrobić.

To jest praca ciągła i nigdy nie zakładamy, że jest skończona. Redukujemy częstotliwość, ale nie rezygnujemy - cały czas przykładamy do tego procesu szczególną uwagę. To jest budowanie know-how produktu, które samo w sobie jest wartością i przewagą konkurencyjną na rynku. A dobrze skrojone, dopasowane i skonfigurowane do kontekstu AI to ogromna przewaga.