Rozwój kierowany błędami: uczenie się z niepowodzeń

CI jest czerwone. Stack trace wskazuje na payment.ts:212, spaliłeś już dwadzieścia minut na zgadywanie, który z ostatnich sześciu commitów to zepsuł, a „poprawka”, którą właśnie wypchnąłeś, zamieniła jeden niezdany test w trzy. Wpatrywanie się w błąd mocniej nie działa.

Komunikat błędu to najbardziej precyzyjna specyfikacja tego, co jest nie tak, jaką masz — i jest dokładnie tym wejściem, które asystent AI konsumuje najlepiej. Rozwój kierowany błędami (Error-Driven Development, EDD) opiera się właśnie na tym: zamiast celować w idealny pierwszy szkic, prowadzisz ciasną pętlę błąd → naprawa → ponowne uruchomienie i pozwalasz każdemu niepowodzeniu sterować następną zmianą. Robione świadomie, zbiega szybko nawet przy paskudnych kaskadach.

Co z tego wyniesiesz

• Powtarzalną pętlę błąd → naprawa → ponowne uruchomienie, którą możesz prowadzić w dowolnym z trzech narzędzi
• Gotowe prompty dla produkcyjnego stack trace’a, kaskady kompilatora i pętli niezdanego testu
• Mechanikę specyficzną dla narzędzia: kto uruchamia testy, kto cofa złą poprawkę, kto iteruje bez nadzoru
• Skrót MCP, który pobiera dla ciebie zgłoszenie z Sentry zamiast kopiowania-wklejania stack trace’ów
• Tryby awarii samej pętli — gonienie za niewłaściwym błędem, naprawianie objawów, pętla na niestabilnych testach

Pętla, według narzędzia

Cykl jest wszędzie taki sam — wydobądź błąd, przekaż go AI z wystarczającym kontekstem, zastosuj poprawkę, uruchom ponownie dokładnie to, co zawiodło. Różni się to, kto uruchamia polecenie i jak wycofujesz złą poprawkę.

Cursor

W trybie agenta Cursor sam uruchamia testy lub build, czyta wyjście terminala i iteruje bez kopiowania-wklejania z twojej strony. Siatką bezpieczeństwa są checkpointy: każda edycja agenta to punkt przywracania, więc gdy „poprawka” pogarsza sprawę, cofasz się do ostatniego zielonego stanu jednym kliknięciem, zamiast to rozplątywać.

Najlepsze, gdy chcesz patrzeć, jak pętla się dzieje, i wkroczyć w chwili, gdy zboczy z kursu.

Claude Code

Claude Code uruchamia kompilator i testy przez narzędzie Bash i podaje wyjście z powrotem sobie, więc pętla zamyka się wewnątrz jednej sesji. W trybie headless (claude -p) możesz pozwolić mu iterować względem niezdanego polecenia z limitem tur, by nie kręciło się w nieskończoność.

Najlepsze, gdy pętla ma działać z terminala lub w CI — skryptowo i z ograniczeniem.

Codex

Codex uruchamia polecenia w sandboksie. Ustaw --sandbox workspace-write, by mógł edytować i uruchamiać, oraz --ask-for-approval on-failure, by szedł dalej przy zielonym, ale zatrzymywał się na tobie, gdy polecenie zawiedzie — naturalny checkpoint EDD. (--full-auto pakuje workspace-write + on-request, jeśli chcesz mniej tarcia.)

Najlepsze, gdy chcesz, by przemieliło długą listę błędów w większości bez nadzoru, ale zatrzymało się przy prawdziwych niepowodzeniach.

Scenariusz 1: błąd produkcyjny ze stack trace’a

Użytkownik trafił na crash, a twój tracker błędów przechwycił wyjątek. Najszybsza droga to dać AI trace plus pliki, które wskazuje.

1. Pobierz trace. Skopiuj pełny wyjątek z Sentry — błąd runtime i stos, nie tylko górną linię.

2. Przekaż go z podejrzanymi plikami. Nazwij pliki, by AI nie musiało grepować na ślepo.

   Wskazówka

   Gotowy prompt dla produkcyjnego stack trace’a:

   Production bug. Here is the exception and stack from Sentry:

   TypeError: Cannot read properties of undefined (reading 'total') at applyDiscount (src/services/payment.ts:212:18) at checkout (src/controllers/checkout.ts:64:22)

   The relevant files are @src/services/payment.ts and @src/controllers/checkout.ts. Find the root cause, the undefined value, not just where it’s read. Tell me whether the fix is a guard at line 212 or an upstream initialization bug, then make the change and add a regression test.

3. Zastosuj i uruchom ponownie. Poprawka powinna zaadresować to, gdzie total stało się undefined (powiedzmy: nadrzędny koszyk bez pozycji), a nie tylko doczepić ?. w linii 212. Uruchom ponownie ścieżkę, która zawiodła; jeśli wyłoni się nowy błąd, przekaż go z powrotem i powtórz.

Notatka

Skrót MCP: z podłączonym serwerem MCP Sentry (zdalny, https://mcp.sentry.dev/mcp) pomijasz kopiowanie-wklejanie w całości — agent pobiera zgłoszenie, stack trace i breadcrumbs bezpośrednio. Zamiast „oto trace” prompt staje się „pull Sentry issue PROJ-1234 and fix the root cause”. Wszystkie trzy narzędzia wspierają MCP; to zamienia ręczne wklejanie w jeden przywołany identyfikator zgłoszenia.

Scenariusz 2: kaskada kompilatora po refaktoryzacji

Zmieniłeś sygnaturę kluczowej funkcji i kompilator rozbłysnął trzydziestoma błędami w całej bazie kodu. To słodki punkt EDD — błędy są dokładną, wygenerowaną maszynowo listą zadań.

1. Wprowadź zmianę i uruchom sprawdzacz typów. Nie naprawiaj jeszcze niczego ręcznie; pozwól, by pełna lista błędów się zmaterializowała.

2. Deleguj całą listę. Daj AI prawdziwe wyjście kompilatora i pozwól mu się przez nie przebijać.

   Wskazówka

   Gotowy prompt dla kaskady kompilatora:

   I changed calculate(order: Order) to calculate(order: Order, currency: Currency). Here is the resulting tsc output:

   src/billing/invoice.ts:48:21 - error TS2554: Expected 2 arguments, but got 1. src/api/checkout.ts:90:14 - error TS2345: Argument of type 'Order' is not assignable to parameter of type 'Currency'. …(28 more)

   Fix every call site. Default currency to the order’s own order.currency where one exists; do not invent a hard-coded currency. After each batch, re-run tsc and continue until it’s clean. Show me the diff before applying.

3. Iteruj aż do czystości. Agent naprawia miejsca wywołań, ponownie uruchamia sprawdzacz typów i powtarza. Zadanie, które ręcznie to godzina mozołu, kończy się w kilka cykli — AI nigdy się nie nudzi przy dwudziestym siódmym miejscu wywołania.

Scenariusz 3: pętla niezdanego testu

Najmocniejsza forma EDD to napisanie najpierw niezdanego testu, a potem pozwolenie AI, by samo doprowadziło się względem niego do zieleni. Test jest jednoznacznym wyrocznią, więc pętla kończy się sama.

Wskazówka

Gotowy prompt dla pętli niezdanego testu:

Here is a failing Vitest spec for parseDuration (it should turn "1h30m" into 5400 seconds):

expect(parseDuration('1h30m')).toBe(5400) // received NaN

Implement parseDuration so this passes, plus the cases "45s" → 45, "2h" → 7200, and "" → throws RangeError. Run the spec after each change and keep iterating until all four pass. Don’t edit the test to make it pass.

To ostatnie zdanie ma znaczenie: bez niego nadgorliwy agent czasem „naprawi” niepowodzenie, rozluźniając asercję. Przypnij test jako specyfikację.

Gdy to się zepsuje

Uwaga

• Gonienie za niewłaściwym błędem w kaskadzie. Pierwszy błąd często powoduje resztę; naprawianie błędu nr 14 to zmarnowana praca, jeśli nr 1 jest wyzwalaczem. Powiedz AI, by najpierw naprawiło najwcześniejszy/źródłowy błąd i uruchomiło ponownie, zanim ruszy pozostałe.
• Naprawianie objawu, nie przyczyny. Owinięcie dostępu do undefined w ?. sprawia, że crash znika, ale nie wyjaśnia, czemu wartości brakowało. Zawsze pytaj „gdzie to stało się undefined?”, a nie tylko „zatrzymaj wyrzucenie”.
• Wieczna pętla na niestabilnym teście. Jeśli test zawodzi niedeterministycznie, AI „naprawi”, uruchomi ponownie, zobaczy zieleń i ogłosi zwycięstwo — a potem znów się posypie w CI. Najpierw zakwarantannij niestabilny test; nie uruchamiaj na nim pętli EDD.
• Furtka edycji testu. Agenci czasem przepuszczają niezdaną asercję, osłabiając ją. Dodaj „do not modify the test” do każdego promptu sterowanego testami.
• Ślepota kontekstowa. Wklejenie samej górnej ramki stosu ukrywa prawdziwego winowajcę głębiej w trace’ie. Daj pełny trace i nazwij podejrzane pliki.

Co dalej

• Programowanie sterowane testami — napisz niezdany test celowo, a potem doprowadź go do zieleni
• Testowanie przez wstrzykiwanie błędów — wyprodukuj awarie, zanim zrobi to produkcja
• Monitoring i obserwowalność — wepnij sygnał z Sentry, który zasila tę pętlę