Test: daj sesji pętlę feedbacku

Etap test daje każdej sesji implementacyjnej szybką, zamykającą się przy błędzie pętlę informacji zwrotnej przed ludzkim review. Agent uruchamia prawdziwe testy, build i kontrolę wizualną; naprawa błędu zaczyna się od testu reprodukującego problem, którego sesja implementacyjna nie może osłabić ani podmienić.

Tradycyjnie: Sygnał, że kod działa, przychodzi późno: CI minuty później, tester dni później, produkcja tygodnie później. Gdy kod produkuje agent, późny sygnał oznacza, że człowiek musi sprawdzić cały jego output.

AI-native: Sesja dostaje sposób na sprawdzenie własnej pracy, zanim zobaczy ją osoba. Uruchom testy, uruchom build, zrób screenshot. Agent iteruje, aż check przejdzie.

Nie myl pętli feedbacku z verifier subagentem. Pętla działa przez całe zadanie. Verifier to jeden sposób, by spakować finalny check w świeżym oknie kontekstu, gdy sesja uważa, że praca jest skończona.

Zanim zaczniesz

• Suite testów i build, które działają lokalnie każda jedną komendą
• Przy pracy UI narzędzie przeglądarki lub screenshot utility (MCP), żeby agent widział wynik

Prerequisites: brak, by zacząć pętlę. CLAUDE.md / rules / AGENTS.md z Build czyni pętlę trwałą.

Ustaw pętlę

1. Zawiń dzisiejszy check w jeden target, który kończy się non-zero przy failure (make test, npm test).

2. W sekcji Commands w CLAUDE.md, .cursor/rules lub AGENTS.md wymień każdą komendę z przykładem zdrowego outputu.

3. Podaj mierzalny target, żeby agent mógł sprawdzić pracę bez pytania Ciebie.

   Przykłady: “All tests in test_status.py pass”, “the screenshot matches the attached mock”, “the endpoint returns 200 with the new field”.

4. Przy bugfixach najpierw napisz failing test.

   Poproś agenta o reprodukcję buga jako test, uruchomienie go i potwierdzenie, że failuje z oczekiwanego powodu. Commitnij ten test. Dopiero potem poproś agenta, by go przeszedł bez edycji testu.

5. Przy pracy UI zamknij pętlę wizualnym checkiem.

   Daj agentowi przeglądarkę lub narzędzie screenshotów, daj mu mock i pozwól iterować: implementuj, screenshot, porównaj, dostosuj. Dwie lub trzy rundy to norma.

6. Uczyń weryfikację częścią „done”.

   Poinstruuj agenta, by uruchamiał testy przed zgłoszeniem zadania jako complete, i wklejał output.

7. Chroń pętlę.

   Agent naprawiający kod nie może osłabić checka na tym kodzie. Hook blokujący edycje plików testowych podczas fixa to robi. Alternatywą jest odrzucanie każdego review diffa, który dotyka testu podczas zadania fix.

Blok weryfikacji do dodania do pliku instrukcji projektu:

## Verifying your work
- Build: make build (must finish with "Build succeeded")
- Test: make test (all green; never skip or delete a failing test)
- Lint: make lint (zero warnings)

Run all three before reporting any task complete, and paste the output.
If a test fails, fix the code, not the test.

Ciągłe evale w CI

Evale to AI-native odpowiednik stage-gate QA: suite, który uruchamia się, gdy zmienia się konfiguracja agenta. Gdy wymieniasz model lub przepisujesz prompt, suite mówi, czy agent nadal wykonuje pracę według tego samego standardu.

1. Zbierz 20 do 50 realnych zadań z niedawnej pracy, każde z zaakceptowanym outcome.

2. Zapisz każde zadanie jako eval: prompt plus checki definiujące akceptowalne (testy przechodzą, lint czysty, zachowanie niezmienione, polityka przestrzegana).

3. Uruchamiaj suite nieinteraktywnie w CI według harmonogramu oraz przy każdej zmianie CLAUDE.md, .cursor/rules, AGENTS.md, skills lub hooków.

4. Bramkuj zmiany konfiguracji wynikami. Zmiana skilla, która obniża pass rate, dostaje review przed mergem.

5. Każdy produkcyjny incydent staje się evalem, pisanym przez zespół, który go posiadał, i zostaje w suite jako regression test.

Niektóre zespoły uruchamiają te evale offline w rytmie, a nie przy każdej zmianie. Tak czy inaczej suite jest żywy: gdy modele się poprawiają, przypadki, które kiedyś dyskryminowały, przestają to robić, i dodajesz nowe z monitoringu.

Claude Code może uruchamiać evale przez claude -p w GitHub Actions. Codex używa openai/codex-action@v1 (który uruchamia codex exec). Cursor Cloud Agents mogą uruchamiać te same checki z workflow, które checkoutuje repo.

Governance

Weryfikacja przed zgłoszeniem zadania jako done oraz blokada edycji plików testowych podczas fixa są obie implementowane jako hooki tam, gdzie organizacja chce ich gwarancji. Dowodem jest literalny output make test, log builda lub screenshot diff. Code owner recenzujący PR może skupić się na intencji i ryzyku, bo mechaniczny dowód jest już dołączony.

Evale dają QA bramkę, która nadąża za outputem agenta. Próg pass-rate to merge check na zmianach harnessu.

Verify

• Agent wkleił output testów lub builda, zanim ogłosił zadanie jako done.
• PR bug-fix nie przepisuje failing testu, który udowodnił buga.
• Zmiana CLAUDE.md / rules / skills odpala suite evali (albo masz udokumentowany rytm).

Wskaźnik wiodący: first-pass CI success rate dla zmian pisanych przez agenta; pass rate evali w czasie.

Wskaźnik opóźniony: czas review per PR, change failure rate oraz regresje złapane w CI versus produkcja.

Zastosuj praktykę w swoim narzędziu

Adapter Claude Code Uruchamiaj checki w sesji i ograniczone review headless przez claude -p.

Adapter Cursora Użyj terminala, przeglądarki, screenshotów, checkpointów i pętli Agenta.

Adapter Codex Użyj aktywnej pętli albo codex exec z jawnym sandboxem i formatem.

Wyślij zweryfikowaną pracę do review

Wyślij już sprawdzony diff przez Deploy.