Pętla feedbacku w sesji — autoweryfikacja agenta

Pętla feedbacku w sesji to wewnętrzny mechanizm weryfikacyjny, który pozwala agentowi programistycznemu AI testować, obserwować i samodzielnie poprawiać własny kod przed przedstawieniem wyników inżynierowi. Wyposażenie sesji w szybki runner testów uruchamiany pojedynczą komendą oraz mierzalny cel sukcesu przekształca agenta z jednorazowego generatora kodu w samonaprawiającą się pętlę deweloperską.

Pytanie w scorecardzie: W jaki sposób agent weryfikuje własną pracę przed przekazaniem jej do przeglądu przez człowieka? Maksymalna odpowiedź (3 pkt): Wymuszona weryfikacja: mierzalne cele, automatyczne iteracje w pętli i subagent weryfikujący w świeżym kontekście.

Dlaczego to ważne w 2026

Gdy agenci nie potrafią weryfikować własnego kodu, człowiek staje się wąskim gardłem manualnego testowania. Programista musi pobierać gałąź, uruchamiać testy, analizować logi i wklejać ślady błędów z powrotem do promptu. Taka wymiana wiadomości wyczerpuje okno kontekstowe i drastycznie marnuje czas inżyniera.

W natywnym dla AI SDLC weryfikacja odbywa się wewnątrz sesji agenta. Agent otrzymuje obiektywną metrykę (np. „wszystkie 14 testów w auth.test.ts przechodzi na zielono” lub „kompilator TypeScript zgłasza zero błędów”) i wykonuje iteracje autonomicznie aż do spełnienia tego warunku. Dla pełnej rzetelności subagent weryfikujący uruchamia się w czystym oknie kontekstowym, badając finalny diff bez obciążeń z fazy tworzenia kodu.

Jak wygląda maksymalny wynik

Konfiguracja z maksymalnym wynikiem w Q14 składa się z czterech elementów:

1. Skodyfikowane komendy: Szybkie polecenia lokalnej weryfikacji (make test, pnpm check, pytest) są udokumentowane w CLAUDE.md, .cursor/rules lub AGENTS.md.
2. Mierzalny cel: Każdy prompt zawiera precyzyjną definicję ukończenia (definition of done) ze sprawdzalnymi kryteriami zaliczenia.
3. Autonomiczna iteracja: Agent wykonuje polecenie testowe, parsuje błędy, nanosi poprawki i uruchamia test ponownie aż do pełnego sukcesu.
4. Subagent weryfikujący: Przed zakończeniem zadania niezależny subagent z czystym kontekstem sprawdza zmiany pod kątem zgodności z plan.md.

Wdrożenie krok po kroku

1. Udokumentuj komendy weryfikacji jedną komendą.

   Dodaj czytelne polecenia weryfikacji wraz z oczekiwanymi rezultatami do instrukcji repozytorium (CLAUDE.md, .cursor/rules/core.mdc lub AGENTS.md):

   ## Komendy weryfikacji
   - Build: make build (musi kończyć się komunikatem "Build succeeded")
   - Testy jednostkowe: make test (wszystkie testy zielone)
   - Linter: make lint (zero ostrzeżeń i błędów)
   
   Zawsze uruchamiaj wszystkie trzy sprawdzenia przed zgłoszeniem ukończenia zadania.
   Wklej wyjście z terminala pokazujące kod wyjścia 0.

2. Podaj mierzalne cele w prompcie.

   Zawsze definiuj obiektywny standard, który agent musi udowodnić przed zatrzymaniem pracy:

   Zaimplementuj obsługę webhooka Stripe opisaną w plan.md.
   Definicja ukończenia:
   1. Wszystkie istniejące testy w tests/billing/ przechodzą pomyślnie.
   2. Trzy nowe testy jednostkowe pokrywające weryfikację sygnatury, duplikaty zdarzeń
      i niepoprawny payload są zielone.
   3. npm run typecheck zwraca 0 błędów.
   Nie proś o review człowieka, dopóki wszystkie trzy warunki nie zostaną spełnione.

3. Skonfiguruj subagenta weryfikującego.

   Utwórz dedykowanego subagenta w pliku .claude/agents/verifier.md (lub w konfiguracji agentów Cursora/Codexa):

   ---
   name: verifier
   description: Sprawdza zmiany i weryfikuje zachowanie w świeżym kontekście
   tools: Bash, Read, Grep
   ---
   Jesteś weryfikatorem o nastawieniu sceptycznym. Przejrzyj ostatni git diff względem plan.md.
   Uruchom zestaw testów za pomocą `npm test`. Przetestuj sąsiadujące moduły pod kątem regresji.
   Zgłoś wszystkie rozbieżności. Nie wprowadzaj poprawek — raportuj wyłącznie znaleziska.

4. Zautomatyzuj wywołanie weryfikacji.

   Poinstruuj agenta, aby uruchomił weryfikatora w ostatnim kroku sesji:

   Claude Code

   Wszystkie testy przechodzą lokalnie. Uruchom subagenta verifier, aby zweryfikować
   diff względem plan.md przed zakończeniem zadania.

   Cursor

   Użyj Composera lub okna Agents z włączonym wykonywaniem poleceń w terminalu:

   Wykonaj `npm test` oraz `npm run lint`. Jeśli jakiekolwiek sprawdzenie nie przejdzie,
   popraw odpowiednie pliki źródłowe i uruchom ponownie. Nie przerywaj pracy,
   dopóki terminal nie pokaże w pełni czystego przebiegu.

   Codex

   W Codex CLI:

   Wdróż zmiany, a następnie uruchom `pnpm test` i `pnpm lint`. Iteruj po ewentualnych
   błędach aż do uzyskania kodu wyjścia 0. Podsumuj wyniki testów w ostatniej odpowiedzi.

Częste pułapki

• Subiektywne prompty: Proszenie agenta, aby „upewnił się, że kod wygląda dobrze” zamiast „upewnij się, że npm test kończy się kodem 0”.
• Nieskończone pętle błędów: Brak limitu powtórzeń, gdy zewnętrzny serwis lub baza danych są niedostępne. Zdefiniuj wyraźne granice mockowania.
• Omijanie testów: Modyfikowanie testu przez agenta, aby zaliczyć sprawdzenie, zamiast naprawienia błędu w kodzie. Zastosuj ścisłą ochronę plików testowych (patrz Q15).

Jak sprawdzić, czy już tam jesteś

• Odpowiedzi agenta regularnie zawierają wykonania poleceń w terminalu (npm test, pytest) bez konieczności ręcznego ponaglania.
• Agent wkleja dowód z terminala o zaliczonych testach przed zadeklarowaniem ukończenia zadania.
• Pull requesty otwierane przez agentów przechodzą proces CI na zielono już przy pierwszym pushu.
• Programiści recenzują kod pod kątem architektury i intencji biznesowej, a nie pod kątem błędów kompilacji.

Dodatkowe materiały

Etap Test w natywnym dla AI SDLC Konfiguracja pętli feedbacku w sesji i ciągłego testowania.

Q15 · Naprawa sterowana testami (TDD) Odtwarzaj błędy za pomocą czerwonych testów przed dotknięciem kodu aplikacji.

Q11 · Własne subagenty Twórz wyspecjalizowanych weryfikatorów i recenzentów w czystym oknie kontekstowym.