Programowanie sterowane bledami

Twoj pipeline CI swieci na czerwono. Jest 14 bledow TypeScript, 3 nieudane testy i ostrzezenie o deprecjacji. Twoj instynkt podpowiada, zeby naprawic je samodzielnie albo wkleic caly log bledow do AI i powiedziec “napraw wszystko”. Oba podejscia marnuja czas. Naprawianie samodzielnie ignoruje zdolnosc AI do rozwiazywania mechanicznych problemow. Zrzucanie calego logu daje AI zbyt wiele do przetworzenia na raz i prowadzi do kaskadowych “napraw”, ktore wprowadzaja nowe problemy.

Programowanie sterowane bledami traktuje kazdy blad jako precyzyjna, wygenerowana maszynowo specyfikacje. Komunikat bledu mowi AI dokladnie co jest zle, gdzie jest zle i czego system oczekuje zamiast tego. To lepsza informacja niz jakikolwiek prompt, ktory moglbys napisac od zera.

Czego sie nauczysz

• Systematyczny przeplyw pracy do przekazywania bledow asystentowi AI po jednym na raz
• Prompty, ktore wyciagaja maksymalny sygnal z komunikatow bledow
• Strategie przerywania kaskad bledow (gdy naprawienie jednego bledu tworzy trzy nowe)
• Techniki wykorzystywania bledow jako okazji do nauki, ktore ulepszaja twoj CLAUDE.md, .cursor/rules i AGENTS.md

Petla sterowana bledami

Zamiast probowac zapobiec wszystkim bledom, wykorzystujesz je jako najszybszy dostepny mechanizm sprzezenia zwrotnego. Petla jest prosta:

1. Wprowadz zmiane (lub pozwol AI ja wprowadzic)
2. Uruchom krok weryfikacji (build, test, lint, type-check)
3. Przeczytaj pierwszy blad
4. Przekaz go AI z docelowym kontekstem
5. Pozwol AI naprawic przyczyne zrodlowa
6. Powtorz od kroku 2

Kluczowa dyscyplina to jeden blad na raz. Komunikaty bledow czesto kaskaduja — jedna przyczyna zrodlowa produkuje dziesiątki dalszych bledow. Napraw pierwszy, a polowa pozostalych zniknie.

Przekazywanie bledow do AI

Jakosc naprawy zalezy calkowicie od tego, jak prezentujesz blad. Nie mow po prostu “build jest zepsuty”. Daj AI dokladny komunikat bledu, plik, w ktorym wystapil, i to, czego sie spodziewales.

Cursor

Zintegrowany terminal Cursor sprawia, ze programowanie sterowane bledami jest bezproblemowe. Uruchom build lub testy bezposrednio w terminalu, a nastepnie odwolaj sie do bledu w trybie Agent:

I ran npm run type-check and got this error:

src/services/notification.ts:42:5 - error TS2345:
Argument of type 'string' is not assignable to parameter
of type 'NotificationPayload'.

Fix the root cause. The function signature in @src/services/notification.ts
expects a NotificationPayload object, not a raw string. Check the caller
at line 42 and the type definition in @src/types/notification.ts.

Agent Cursor moze rowniez czytac wyjscie terminala bezposrednio. Po nieudanej komendzie po prostu wpisz w czacie: “Fix the error in the terminal.”

Claude Code

Przekieruj bledy bezposrednio do Claude Code lub uruchom komende i pozwol Claude przeczytac wyjscie:

Run npm run type-check. For each error:
1. Read the file and line number referenced in the error
2. Understand the root cause (don't just suppress the error)
3. Fix the root cause
4. Re-run type-check to verify the fix
5. Move to the next error

Fix errors one at a time. Do not batch fixes.

Mozesz rowniez przekierowac wyjscie bledow bezposrednio:

npm run type-check 2>&1 | claude -p "Fix the first TypeScript error. Show me the root cause and your fix."

Agentyczna petla Claude Code uruchomi komende, przetworzy wyjscie, naprawi problem i automatycznie ponownie uruchomi, az do uzyskania czystego wyniku.

Codex

Srodowisko sandbox Codex uruchamia weryfikacje automatycznie:

Run npm run type-check. Fix each error one at a time,
starting with the first one. After fixing each error,
re-run the check to see if downstream errors resolved.
Do not batch fixes -- address one root cause per iteration.

W aplikacji Codex mozesz wkleic wyjscie terminala bezposrednio jako kontekst. Codex przeanalizuje bledy i bedzie je systematycznie rozwiazywac. W przypadku awarii CI integracja Codex z GitHub moze odczytac wyjscie nieudanej kontroli bezposrednio z PR.

Gotowy prompt: Systematyczne rozwiazywanie bledow

Run [BUILD/TEST COMMAND]. Then fix errors using this process:

1. Read the FIRST error message carefully
2. Identify the root cause (not the symptom)
3. Read the referenced files to understand context
4. Fix the root cause
5. Re-run the command
6. If new errors appear, repeat from step 1
7. If the same error persists, try a different approach

Do not suppress errors with type casts, @ts-ignore, or empty catch blocks.
Fix the underlying issue.

Przerywanie kaskad bledow

Czesta pulapka: AI naprawia blad 1, co wprowadza blad 2, ktory po naprawieniu wprowadza blad 3. Konczysz w cyklu “wack-a-mole”, ktory wypala twoje okno kontekstowe bez robienia postepu.

Rozwiazaniem jest rozpoznanie wzorcow kaskadowych i zaadresowanie ich strukturalnie.

Cursor

Gdy widzisz ten sam plik pojawiajacy sie w wielu bledach, cofnij sie:

We've been fixing errors in notification.ts for three iterations
and new ones keep appearing. Stop fixing individual errors.

Instead:
1. Read the full file @src/services/notification.ts
2. Read the types it depends on @src/types/notification.ts
3. Read the test file @src/services/__tests__/notification.test.ts
4. Identify the structural problem causing the cascade
5. Propose a fix for the root architectural issue

Do not modify any files until I approve the approach.

Claude Code

Uzyj /clear do zresetowania kontekstu, gdy utkniesz w petli, a nastepnie zacznij ponownie z szerszym spojrzeniem:

I've been fixing TypeScript errors in src/services/notification.ts
but they keep cascading. Take a step back:

1. Read the file and all its imports
2. Run npm run type-check and capture ALL errors related to this file
3. Identify the common root cause
4. Fix the structural issue rather than individual symptoms
5. Re-run type-check to verify

Jesli Claude dziala juz wiecej niz dwa cykle korekcji na tym samym bledzie, kontekst jest zanieczyszczony nieudanymi podejsciami. /clear i swiezy prompt prawie zawsze zbiegna szybciej.

Codex

Rozpocznij nowy watek, gdy bledy sie kaskaduja. Czysty kontekst pomaga Codex zobaczyc problem strukturalny:

The file src/services/notification.ts has cascading TypeScript errors.
Individual fixes keep introducing new errors.

Read the file and all its dependencies. Identify the structural
root cause and fix it holistically. Run type-check after your
changes to verify all errors are resolved.

Gotowy prompt: Wyjscie z petli bledow

We're stuck in a cycle where fixing one error introduces another.
Stop making changes and analyze the situation:

1. List all current errors (run [COMMAND])
2. Group them by root cause
3. Identify which single change would resolve the most errors
4. Explain your reasoning before making any changes

I need to understand the structural issue before we proceed.

Zamiana bledow w trwala wiedze

Najcenniejsze bledy to te, ktorych nigdy wiecej nie zobaczysz. Gdy napotkasz nieoczywisty blad, zapisz lekcje w konfiguracji projektu, aby AI unikal tego samego bledu w przyszlych sesjach.

Cursor

Dodaj regule projektu w .cursor/rules/errors.md:

---
description: "Common errors and their fixes for this project"
alwaysApply: true
---

## Known Error Patterns

- When modifying notification types, always update both
  `src/types/notification.ts` AND the Zod schema in
  `src/validators/notification.ts`. They must stay in sync.
- Redis connection errors in tests: run `docker compose up -d redis`
  before running the test suite.

Claude Code

Dodaj lekcje do swojego CLAUDE.md lub popros Claude, zeby ja zapamietał:

Remember: when modifying notification types, always update both
src/types/notification.ts AND the Zod schema in
src/validators/notification.ts. They must stay in sync.

Automatyczna pamiec Claude zapisze to w ~/.claude/projects/<project>/memory/ i zaladuje w przyszlych sesjach. Mozesz rowniez dodac to bezposrednio do CLAUDE.md projektu, aby caly zespol mial z tego korzysci.

Codex

Dodaj lekcje do swojego AGENTS.md:

## Known Error Patterns

- Notification types: always update both src/types/notification.ts
  AND the Zod schema in src/validators/notification.ts together.
- Redis must be running for integration tests: docker compose up -d redis

Codex czyta AGENTS.md na poczatku kazdej sesji, wiec te wskazowki sa stosowane automatycznie do calej przyszlej pracy.

Gotowy prompt: Analiza po trudnym bledzie

We just spent significant time fixing [describe the error]. Before moving on:

1. Summarize what the root cause was
2. Explain why it was hard to diagnose
3. Suggest a rule or check we can add to prevent this in the future
4. Add the prevention rule to [CLAUDE.md / .cursor/rules / AGENTS.md]

Kiedy to nie dziala

Komunikat bledu jest bezuzyteczny. Niektore komunikaty bledow sa naprawde nieprzejrzyste (segfaulty, generyczne “internal server error”). W takich przypadkach przelacz sie z podejscia sterowanego bledami na podejscie sterowane hipotezami: popros AI o dodanie logowania, odtworzenie problemu i zawezenie przyczyny przez eliminacje.

AI ciągle tlumi bledy zamiast je naprawiac. Jesli widzisz @ts-ignore, as any, puste bloki catch lub eslint-disable w wyjsciu AI, to tłumi objawy zamiast naprawiac przyczyny. Badz bezposredni: “Do not suppress errors. Fix the underlying issue.”

Zbyt wiele bledow do przetworzenia. Jesli type-check produkuje 200+ bledow, nie podawaj ich wszystkich AI. Skup sie na pierwszych 3-5 bledach — to zwykle przyczyny zrodlowe, ktore produkuja reszte. Po ich naprawieniu uruchom ponownie i sprawdz, ile pozostalo.

Blad jest w wygenerowanym kodzie. Gdy blad jest w pliku, ktory AI wygenerowalo od zera, czesto szybciej jest usunac plik i wygenerowac go ponownie z bardziej ograniczonym promptem, niz latac istniejaca zepsuta wersje.

Co dalej

Programowanie sterowane testami Polacz TDD z programowaniem sterowanym bledami dla najszybszej drogi do poprawnego kodu.

Ciagla dostawa Dostarczaj bezbłedne zmiany przyrostowo zamiast gromadzic ryzyko.

Wzorce pamieci Przechowuj wzorce bledow na stale, aby AI uczyl sie z przeszlych pomylek.