Agent się pomylił. Tylko w czym dokładnie?

Poprosiłem agenta o naprawę filtra w katalogu urządzeń w Angularze: po zmianie marki lista modeli wciąż pokazywała model starej marki. Agent zaczął resetować wszystkie filtry przy zmianie marki, więc wyczyściły się też zakres cen i pamięć. Napisałem: „popraw, pozostałe filtry mają działać”. Druga próba dodała wyjątek dla ceny, trzecia dla pamięci. Trzy łatki, każda poprawnie wykonywała zły kierunek. Poprawiałem kod, a powinienem był się zatrzymać i poprawić plan.

Dlaczego „popraw to” tylko pogarsza sprawę?

Bo „popraw to” traktuje każdą porażkę jak błąd wykonania. Jeśli agent rozwiązuje niewłaściwy problem albo trzyma się złego wzorca, kolejna runda szlifuje błąd, zamiast go usunąć. Każda łatka dokłada kod na decyzji, której nigdy nie zatwierdziłeś, a agent w każdej turze czyta od nowa swoje nieudane próby.

Jakie jest pięć klas błędów coding agenta?

Cel, kierunek, wykonanie, weryfikacja oraz narzędzie lub środowisko. Sama etykieta jest mniej ważna niż poziom, na który Cię odsyła.

1. Błąd celu: dobre rozwiązanie złego problemu

Prosisz o naprawę nieaktualnego wyboru modelu, a agent przebudowuje panel filtrów, bo odczytał zadanie jako skargę na UX. Sygnał: diff jest sensowny, ale odpowiada na inne pytanie. Wróć do zadania. Jeszcze raz opisz obecne zachowanie, oczekiwane zachowanie i to, co znaczy „gotowe”.

2. Błąd kierunku: dobry cel, zła droga

Cel jest jasny, ale podejście, wzorzec albo obszar jest zły: reset wszystkich filtrów albo edycja ProductFilters, choć katalog korzysta z CatalogFilters. Sygnał: każda poprawka dokłada nowy wyjątek. Zatrzymaj implementację i popraw plan. Więcej kodu nie naprawi złego kierunku.

3. Błąd wykonania: dobra droga, techniczne potknięcie

Podejście się broni, ale kod ma usterkę: brakującą zależność w useEffect, subskrypcję valueChanges, której nikt nie odpina, przesunięcie o jeden w paginacji. Popraw lokalnie, dodaj test, zweryfikuj ponownie. To jedyna klasa, w której „popraw to” jest dobrą wiadomością, najlepiej z dołączonym przypadkiem, który nie działa.

4. Błąd weryfikacji: może dobrze, ale bez dowodu

Kod może być w porządku, ale nikt nie sprawdził pustego stanu, pozostałych filtrów ani odświeżenia strony. Uzupełnij brakujący dowód: test regresyjny, ręczne przejście flow, przegląd miejsc użycia. Jakie dowody się liczą, opisuję w tekście o review kodu z AI.

5. Błąd narzędzia lub środowiska: problem nie siedzi w kodzie

Agent ciągle coś zmienia, bo dev server leży, komenda się wywala, wersja Node jest zła albo serwer MCP jest źle skonfigurowany. Sygnał: ten sam błąd przeżywa zmiany, które powinny go ruszyć. Przerwij próby i napraw środowisko. Obchodzenie zepsutego narzędzia w kodzie tworzy drugi problem.

Kierunek i wykonanie to klasy, które najłatwiej pomylić. Test: opisz podejście agenta jednym zdaniem, tak jak opisałbyś je komuś z zespołu. „Resetuj wszystkie filtry przy zmianie marki” odpada, bo odrzucasz samo podejście. „Czyść model, gdy nie należy do nowej marki, ale efekt odpala się o jeden render za późno” przechodzi: podejście jest dobre, myli się szczegół. Odrzucasz podejście, to błąd kierunku. Odrzucasz szczegół, to błąd wykonania.

Dlaczego liczy się to, jak szybko zauważysz błąd?

Bo koszt złej decyzji rośnie razem ze wszystkim, co na niej powstało: kolejnymi plikami, zależnościami i testami, które utrwalają złe zachowanie.

Swoją pracę mierz liczbą akcji agenta od pierwszego odchylenia do Twojej reakcji. Nie musisz zapobiec każdemu błędowi. Musisz go zobaczyć, kiedy jest jeszcze jednym plikiem, a nie całą gałęzią pracy. Błąd kierunku złapany w audycie planu w ogóle nie trafia do diffu.

Kiedy zatrzymać agenta zamiast go poprawiać?

Gdy dalszy wysiłek na obecnej ścieżce przestaje dawać nowe informacje. Agent potrafi długo ratować zły kierunek, więc warunki zatrzymania ustal z góry:

• agent musi przyjąć niepotwierdzone założenie produktowe;
• zmienione pliki wychodzą poza uzgodniony zakres;
• rozwiązanie wymaga zmiany współdzielonego kontraktu;
• pojawia się regresja w niezwiązanym obszarze;
• plan przestał opisywać to, co jest implementowane;
• dalsze łatanie kosztuje więcej niż cofnięcie i nowy plan.

Dokumentacja Claude Code mówi to samo: po dwóch nieudanych korektach uruchom /clear i napisz jedną lepszą wiadomość z tym, czego się dowiedziałeś, bo trzecia korekta głównie dokłada się do rozmowy pełnej nieudanych prób.

Jak wrócić na właściwy tor po zatrzymaniu agenta?

Wróć na poziom, na którym błąd się zaczął, a nie do ostatniej linii kodu.

1. Nazwij klasę: cel, kierunek, wykonanie, weryfikacja albo środowisko.
2. Wróć na jej poziom: zadanie, plan, kod, dowody albo narzędzia.
3. Cofnij zmiany, zamiast łatać na złym kierunku. W Claude Code /rewind przywraca kod i rozmowę do wcześniejszej wiadomości, ale nie obejmuje plików zmienionych tylko komendami w shellu, więc git zostaje Twoją siatką bezpieczeństwa.
4. Wyślij jedną wiadomość z tym, czego się dowiedziałeś, albo zacznij z nią czystą sesję.
5. Weryfikuj względem kryteriów ustalonych przed pracą, a nie względem podsumowania agenta.