Poziom 4: piszesz specyfikacje

Poziom 4 drabiny autonomii to etap, na którym programista pisze specyfikację, warunek stopu sprawdzalny przez maszynę i testy, które go rozstrzygają, a agent pracuje potem bez nadzoru przez wiele godzin. Człowiek ocenia wynik po dowodach, a nie przez czytanie każdego diffu. Poziom 4 działa tylko wtedy, gdy agent nie może edytować sprawdzeń definiujących „gotowe”.

Ta strona jest dla programistów, którzy już prowadzą agentów równolegle na poziomie 3 i chcą przebiegów, od których można odejść, oraz dla tech leadów, którzy decydują, jaka praca może tak działać. O osiemnastej uruchamiasz dużą migrację. O ósmej rano agent raportuje „wszystkie testy przechodzą”, a jeden z zielonych testów to ten, który przepisał o trzeciej w nocy. Poziom 4 to zestaw nawyków, po których taki poranek się nie zdarza. CTO i zarząd mogą przejść od razu do sekcji o metrykach.

Co daje ci ten przewodnik po poziomie 4

• Test z czterech punktów, który mówi, czy jesteś na poziomie 4, czy na poziomie 3 z usuniętym sprawdzeniem.
• Cztery artefakty, które istnieją przed startem długiego przebiegu, i kolejność, w jakiej je piszesz.
• Uruchomienie przebiegu sterowanego celem w Claude Code, Codeksie i Cursorze, z komendami.
• Hook Stop, który nie pozwala skończyć, dopóki testy są czerwone albo pliki testów się zmieniły.
• Dwa prompty do skopiowania: napisz i zaatakuj warunek stopu oraz przygotuj poranny raport dowodów.
• Poranny przegląd: jak przyjąć albo odrzucić dwunastogodzinny przebieg bez czytania całego diffu.

Czy jesteś na poziomie 4? Test z czterech punktów

Drabina Dana Shapiro (The Five Levels: from Spicy Autocomplete to the Dark Factory, 23 stycznia 2026) opisuje ten szczebel bez ozdobników: „write a spec”, a potem „leave for 12 hours, and check to see if the tests pass”. Jesteś na poziomie 4, gdy prawdziwe są wszystkie cztery zdania:

1. Piszesz specyfikację i linię mety, nie kod. Twoim produktem pracy jest specyfikacja i warunek.
2. Przebiegi trwają dłużej, niż je obserwujesz. Mija godzina lub więcej bez twojego promptu.
3. O „gotowe” decyduje sprawdzenie, któremu ufasz. Rozstrzygają testy, typy i skrypty, a nie podsumowanie agenta.
4. Przebieg nie może przepisać tego sprawdzenia. Pliki testów, konfiguracja CI i skrypty hooków są poza jego zasięgiem.

Jeśli czwarte zdanie jest fałszywe, przebieg sam sobie wystawia ocenę. To poziom 3 bez recenzenta i najczęstszy sposób, w jaki ten szczebel zawodzi. Jedna mapa pokazuje, jak drabina ma się do etapów cyklu życia i stanowisk fabryki.

Jakie cztery artefakty istnieją przed startem przebiegu na poziomie 4?

Żaden z nich nie jest kodem. Pisz je w tej kolejności, bo każdy sprawdzasz względem poprzedniego.

1. Specyfikacja. Wynik, ograniczenia i to, co jest poza zakresem, w pliku, który przebieg czyta (spec.md, issue, PRD). Spec-driven development opisuje, jak utrzymać ją jako źródło prawdy, a kryteria akceptacji — jak zamienić każde wymaganie w sprawdzenie.
2. Plan. Agent pisze go w trybie planowania, a ty go czytasz. Plan to strona tekstu, a nie diff na 3000 linii: najtańsze review całego przebiegu. Zobacz tryb planowania w różnych narzędziach i workflow PRD w Cursorze. AI-DLC formalizuje ten krok: AI tworzy plan i wdraża rozwiązanie dopiero po walidacji przez zespół.
3. Wyrocznia. Testy, typy i skrypty, które rozstrzygają, czy specyfikacja jest spełniona, napisane lub przejrzane przez ciebie przed przebiegiem. Testy napisane najpierw to jedyna część wyroczni, której nie napisał agent, i na tym stoi argument za programowaniem sterowanym testami na poziomie 4: nie chodzi o czystość, tylko o pochodzenie. Siła wyroczni mówi, czy te sprawdzenia w ogóle złapią błędną odpowiedź.
4. Warunek stopu. Jedna meta zapisana jako komendy, które muszą zakończyć się kodem 0, plus budżet rund lub tur. Prompt poniżej go szkicuje, a potem atakuje.

Prompt do skopiowania: napisz warunek stopu, a potem go zaatakuj

Read spec.md and the plan we agreed. Draft the goal text for this run as
five blocks and nothing else.

Objective: one sentence, one finish line.
Read first: the exact files that define correct, including one
already-correct example in this repository.
Done when: the commands that must exit 0 (tests, typecheck, lint), plus one
grep proving the old pattern is gone. Say that each command's output must
appear in the transcript.
Never touch: the test files that make up the oracle, listed by path, plus
CI config, .claude/run-base, and .claude/ or .codex/ settings.
Budget: one line appended to RUN_LOG.md per round, and "or stop after 30
turns and report what is left" as the last clause.

Then attack your own draft. List every way the condition could be satisfied
by weakening a test, deleting a case, skipping a suite, or claiming a result
without running the command. Rewrite the wording so none of them works, and
print only the final version.

Agenci Stripe pokazują, jak wygląda ograniczony warunek w dużej skali: „at most two rounds of CI”, po których gałąź wraca do człowieka (blog inżynierski Stripe, 9 lutego 2026). Budżet jest częścią warunku, a nie dodatkiem.

Jak uruchomić przebieg sterowany celem w Claude Code, Codeksie i Cursorze?

Wszystkie trzy narzędzia mają polecenie /goal. Różnią się tym, kto sprawdza warunek i co jeszcze można do niego podpiąć.

Claude Code

Sprawdzone z Claude Code 2.1.283 (kanał latest) i dokumentacją /goal 26 września 2026.

# W sesji: najpierw plan, zatwierdź go i wyjdź z trybu planowania (Shift+Tab do trybu auto)
/plan
# potem ustaw cel; ustawienie celu od razu startuje turę
/goal all tests in test/billing pass, `npm run typecheck` exits 0, no file under test/ is modified, or stop after 30 turns
/goal          # status: warunek, tury, zużyte tokeny, ostatni werdykt
/goal clear    # zatrzymanie przed czasem

Po każdej turze mały, szybki model (domyślnie Haiku w Claude API) ocenia, czy warunek jest spełniony. Zwraca „not yet met”, „met” albo „impossible”. Warunek może mieć do 4000 znaków, a w sesji aktywny jest jeden cel. Cel nie zmienia trybu uprawnień, więc cel ustawiony przy włączonym trybie planowania niczego nie zedytuje. Najpierw przełącz się na tryb auto, żeby tury szły bez nadzoru.

Ewaluator „doesn’t run commands or read files independently”. Czyta transkrypt. Dlatego warunek powyżej wymienia komendy, a hook Stop z następnej sekcji uruchamia je sam.

Do przebiegu ze skryptu albo z CI tryb headless wykonuje całą pętlę w jednym wywołaniu. Sesja claude -p startuje w trybie Manual, a nie auto (v2.1.283), więc podaj tryb uprawnień wprost, bo inaczej przebieg utknie na pierwszym niezatwierdzonym wywołaniu narzędzia:

# Terminal: tryb auto dla tur bez nadzoru; strumieniuj każdą turę, żeby długi cel nie wyglądał na zawieszony
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week" \
  --permission-mode auto --output-format stream-json --verbose

Przy ciaśniejszym przebiegu zamień --permission-mode auto na --allowedTools i wymień tylko komendy, których cel potrzebuje.

Codex

Sprawdzone z codex-cli 0.157.1 26 września 2026: goals to stabilna funkcja włączona domyślnie, a /goal ustawia lub pokazuje „the goal for a long-running task”. Od wersji 0.151.0 tokeny zużyte przez zagnieżdżonych subagentów liczą się do budżetu celu.

# W TUI Codeksa: najpierw plan, zatwierdź go, potem ustaw cel
/plan
/goal all tests in test/billing pass, `npm run typecheck` exits 0, no file under test/ is modified, or stop after 30 turns and report what is left

Wskazówki samego Codeksa o formułowaniu celu (strona Long-running work, sprawdzona 28 sierpnia 2026) wymagają trzech części: „Outcome, Constraints, Verification”. Codex ma też zdarzenie Stop wśród 12 zdarzeń hooków; hooki działają dopiero po zapisaniu zaufania. W Codeksie nie ma polecenia /loop (sprawdzone 28 sierpnia 2026 na liście komend deweloperskich i brak go w binarce 0.157.1 26 września 2026).

Cursor

Cursor ogłosił /goal w changelogu z 19 sierpnia 2026: „Use /goal to give the agent a long-lived objective to work towards until it’s fully complete.” Dokumentacja poleceń slash w CLI Cursora wciąż oznaczała je jako „Rolling out” przy sprawdzeniu 28 sierpnia 2026. Plan Mode „creates detailed implementation plans before writing any code”, a hooki Cursora działają „before or after defined stages of the agent loop and can observe, block, or modify behavior” (wszystko sprawdzone 28 sierpnia 2026; 26 września 2026 cursor.com był nieosiągalny ze środowiska, w którym powstał tekst). Zanim oskryptujesz bramkę stopu, sprawdź aktualne nazwy zdarzeń w dokumentacji hooków Cursora.

/loop (dołączony skill od wersji 3.5, 20 maja 2026) uruchamia prompt ponownie według lokalnego harmonogramu, aż osiągnie wynik albo go zatrzymasz; /goal zmierza do jednej mety bez harmonogramu.

Polecenie /goal omawia każde narzędzie dokładnie, a polecenie /loop opisuje przebiegi w rytmie.

Jak nie pozwolić przebiegowi skończyć, gdy testy są czerwone?

Użyj hooka: skryptu, który narzędzie uruchamia w stałym punkcie pętli, niezależnie od decyzji modelu. W Claude Code hook Stop uruchamia się, gdy agent próbuje zakończyć turę. Kod wyjścia 2 blokuje zakończenie i odsyła tekst ze stderr agentowi jako powód, żeby pracował dalej. W odróżnieniu od ewaluatora /goal hook sam uruchamia komendy.

Zanim przebieg wystartuje, zapisz commit, od którego zaczyna, żeby hook porównywał zmiany z nim niezależnie od tego, ile razy agent zrobi commit:

git rev-parse HEAD > .claude/run-base

#!/usr/bin/env bash
# .claude/hooks/require-green.sh — Stop hook: no finishing while the oracle is red
cd "${CLAUDE_PROJECT_DIR:-$(git rev-parse --show-toplevel)}" || exit 0
[ -f .claude/run-base ] || exit 0   # armed only during a recorded run

# 1. The oracle must be untouched: the run may not edit the tests it is graded by.
#    Diff against the commit recorded before the run, not HEAD, so a committed
#    test edit still counts, and list new untracked test files too.
base=$(cat .claude/run-base)
changed=$( { git diff --name-only "$base" -- test/; git ls-files --others --exclude-standard -- test/; } )
if [ -n "$changed" ]; then
  printf 'Revert your edits to the test files and fix the code instead:\n%s\n' "$changed" >&2
  exit 2
fi

# 2. The oracle must be green.
if ! out=$(npm test --silent 2>&1); then
  printf 'Tests are failing. Fix the code, not the tests:\n%s\n' "$(printf '%s' "$out" | tail -n 40)" >&2
  exit 2
fi
exit 0

Zarejestruj go w .claude/settings.json (skrypt musi być wykonywalny: chmod +x):

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/require-green.sh", "timeout": 600 }
        ]
      }
    ]
  }
}

Hook uzbraja się tylko na czas zarejestrowanego przebiegu: bez pliku .claude/run-base kończy się po cichu kodem 0, więc zwykłe sesje w tym samym repozytorium nie widzą błędów hooka. Usuń plik, gdy przebieg zostanie oceniony. Zanim zaczniesz na nim polegać, poznaj trzy ograniczenia. Claude Code stosuje limit ośmiu kolejnych kontynuacji: gdy hooki stopu osiem razy z rzędu przedłużą turę, następna blokada zostaje zignorowana i tura się kończy (CLAUDE_CODE_STOP_HOOK_BLOCK_CAP podnosi limit). Plik ustawień leży w repozytorium, więc przebieg też może go edytować; wpisz go do „Never touch” i sprawdzaj w CI. A /goal sam jest hookiem Stop, więc nie działa, gdy disableAllHooks ma wartość true. Polecenie mówi o tym wprost, zamiast zawieść po cichu.

Ta sama bramka w pozostałych narzędziach:

• Codex uruchamia ten sam skrypt z hooka Stop, ale nie kopiuj rejestracji z Claude Code. Codex 0.157.1 nie ustawia zmiennej CLAUDE_PROJECT_DIR, więc ${CLAUDE_PROJECT_DIR}/.claude/hooks/require-green.sh rozwija się do /.claude/hooks/require-green.sh, powłoka kończy pracę kodem 127 z komunikatem „not found”, a bramka w ogóle się nie uruchamia. Codex wykonuje polecenie przez powłokę w katalogu roboczym sesji, więc w .codex/hooks.json ustal katalog główny repozytorium przez git:

  {
    "hooks": {
      "Stop": [
        {
          "hooks": [
            { "type": "command", "command": "\"$(git rev-parse --show-toplevel)/.claude/hooks/require-green.sh\"", "timeout": 600 }
          ]
        }
      ]
    }
  }

  Potem otwórz /hooks i nadaj mu zaufanie: hooki projektu nie działają, dopóki zaufanie nie zostanie zapisane, i trzeba je nadać ponownie po każdej zmianie pliku (Codex 0.157.1). Hooki agentów w różnych narzędziach opisują resztę rejestracji w Codeksie.

• Cursor ma hooki, które mogą blokować pętlę agenta, ale 26 września 2026 nie dało się sprawdzić nazw ich zdarzeń ze środowiska, w którym powstał tekst. Sprawdź je w dokumentacji hooków Cursora, zanim przeniesiesz skrypt.

Hooki w Claude Code i hooki agentów w różnych narzędziach opisują pozostałe zdarzenia. Ochrona wyroczni idzie dalej: zablokowane ścieżki testów, CODEOWNERS i sprawdzenia typu holdout, trzymane poza repozytorium.

Jak sprawdzić dwunastogodzinny przebieg bez czytania każdej linii?

Czytasz dowody w ustalonej kolejności, a kod tylko tam, gdzie dowody nie wystarczają. Dowody zbiera agent; decyzja należy do ciebie.

1. Uruchom wyrocznię sam albo przeczytaj wynik CI na wypchniętej gałęzi. Nigdy nie przyjmuj raportu przebiegu o zielonym wyniku na słowo.
2. Sprawdź, czy wyrocznia jest nietknięta. git diff --stat $(cat .claude/run-base) -- test/ .github/ .claude/ musi być puste, chyba że specyfikacja prosiła o zmiany w testach.
3. Sprawdź, co zmieniło się względem specyfikacji. Które kryteria akceptacji są spełnione, a których agent według własnych słów nie spełnił.
4. Przeczytaj RUN_LOG.md. Szukaj rundy, w której postęp stanął albo zmieniło się podejście. Długie przebiegi się degradują: SlopCodeBench (arXiv, 25 marca 2026) kazał 15 agentom kodującym rozwijać własny kod przez 196 checkpointów, stwierdził, że „no agent fully solves any problem end-to-end, and the best agent passes 14.8% of checkpoints”, i zmierzył ten rozpad jako erozję struktury i rozwlekłość.
5. Czytaj kod tylko w klasach eskalacji. Schemat i migracje, autoryzacja, pieniądze i wszystko, co widzi klient. Czytanie dowodów zamiast kodu definiuje te klasy.
6. Zatwierdź albo odeślij. Programista, który napisał specyfikację, zatwierdza na podstawie dowodów. Zmiana w klasie eskalacji potrzebuje też właściciela kodu.

Prompt do skopiowania: poranny raport dowodów

The run toward the goal in RUN_LOG.md has ended. Do not change any code.
Produce EVIDENCE.md with these sections and nothing else:

1. Oracle: run the full test suite, the typecheck and the lint step now,
   and paste each command with its exit code and last 10 lines of output.
2. Oracle integrity: the output of
   git diff --stat $(cat .claude/run-base) -- test/ .github/ .claude/
   and one sentence on every file it lists.
3. Spec coverage: a table of every acceptance criterion in spec.md with
   met / not met / partly met and the test that proves it.
4. Escalation classes: every changed file that touches migrations, auth,
   payments or user-visible copy, with one line on what changed.
5. Turning points: the rounds in RUN_LOG.md where the approach changed or
   progress stalled, and why.
6. Doubts: what you are least sure of, and the check that would settle it.

Ten sam plik EVIDENCE.md dołączony do pull requesta to pakiet dowodów, który recenzenci czytają zamiast diffu.

Co powinni mierzyć tech leadzi, CTO i zarząd na poziomie 4?

Cztery miary, liczone dla repozytorium albo dla klasy zmian, pokazują, czy poziom 4 działa, czy przebiegi tylko wyglądają na skończone. Przyjmij definicje w tej postaci, a progi ustaw według własnego punktu odniesienia.

Miara	Definicja	Sygnał ostrzegawczy
Odsetek przyjętych przebiegów	Przebiegi bez nadzoru, których wynik scalono bez poprawek, podzielone przez wszystkie uruchomione	Spada, gdy przebiegi się wydłużają
Odsetek edycji wyroczni	Przebiegi, których diff dotknął plików testów, CI lub hooków, choć specyfikacja o to nie prosiła	Jakikolwiek wzrost
Defekty przepuszczone na produkcję (na klasę)	Incydenty produkcyjne wywołane zmianami zatwierdzonymi na podstawie dowodów, w podziale na klasy zmian	Klasa, która ciągle przecieka, wraca na poziom 3
Przekroczenie budżetu	Przebiegi zatrzymane przez budżet tur lub tokenów, a nie przez warunek	Warunki nieosiągalne albo niejasne

Najważniejszy jest odsetek edycji wyroczni. Przebieg, który zmienia własne sprawdzenia, nie osiągnął poziomu 4, niezależnie od odsetka przyjętych przebiegów.

Co się psuje, gdy dwunastogodzinny przebieg wraca zielony?

Agent zmienił wyrocznię

Objaw: zestaw testów jest zielony, a w diffie jest plik testów. Naprawa: cofnij zmiany w testach, uruchom wyrocznię na wyniku jeszcze raz i dopisz ścieżki do hooka oraz do „Never touch”. Rozstrzygające sprawdzenie trzymaj w CI, gdzie przebieg go nie przepisze.

Ewaluator uwierzył na słowo

Objaw: cel jest „met”, ale w ostatniej turze nikt nie uruchomił testów. Naprawa: wpisz do warunku, że wynik npm test musi pojawić się w transkrypcie, i dodaj hook Stop, żeby sprawdzenie szło niezależnie od tego, co mówi agent.

Przebieg błądził albo się miotał

Objaw: log pokazuje tę samą poprawkę próbowaną na trzy sposoby albo pracę poza specyfikacją. Naprawa: rozdziel cel na dwa, wskaż jeden już poprawny przykład do naśladowania i zacznij od ostatniego dobrego commita z logu, a nie od stanu końcowego.

Budżet skończył się przed celem

Objaw: limit wyczerpany, a warunek wciąż niespełniony. Naprawa: warunek był nieosiągalny albo za szeroki. Dodaj klauzulę tur („or stop after 30 turns and report”) i udowodnij, że warunek da się spełnić, uruchamiając go najpierw na ręcznie przygotowanej poprawce.

Przebieg w ogóle nie ruszył

Objaw: Claude Code odmawia uruchomienia /goal. Naprawa: przeczytaj komunikat. Zwykle przyczyną są wyłączone hooki (disableAllHooks), polityka dopuszczająca tylko zarządzane hooki albo niezaufany folder, bo /goal działa przez system hooków.

Zielone, ale złe

Objaw: wszystkie sprawdzenia przechodzą, a funkcja nadal działa źle. Naprawa: wyrocznia jest za słaba dla tej klasy. Wzmocnij ją testem, który odtwarza błąd, i przywróć czytanie kodu w tej klasie, dopóki nowe sprawdzenia same czegoś nie złapią.

Kiedy klasa zmian jest gotowa na poziom 5?

Poziom 5 wyjmuje człowieka z pętli dla całych stanowisk, a nie pojedynczych przebiegów. Klasa zmian jest gotowa, gdy przebiegi bez nadzoru mają w niej wysoki odsetek przyjęć, odsetek edycji wyroczni wynosi zero, liczba przepuszczonych defektów nie rośnie, a zespół przegląda specyfikacje, a nie prompty. Wszystko, czego warunek stopu nie rozstrzygnie (intencja, wyczucie, klasy eskalacji), zostaje przy ludziach; wylicza to strona co zostaje człowiekowi.

Compound engineering sprawia, że żaden przebieg nie zaczyna od zera: każdy skończony zostawia po sobie regułę, sprawdzenie albo skill. Zobacz compound engineering, spakowaną dyscyplinę w Superpowers i grill me jako przebieg dostrajający przed długim zadaniem.

Dokąd dalej z poziomu 4

Poziom 5: prowadzisz fabrykę oprogramowania Sześć stanowisk i to, co każde narzędzie do nich dokumentuje.

Czytanie dowodów zamiast kodu Co czyta człowiek, gdy diff przestaje być jednostką review.

Ochrona wyroczni Sprawdzenia, których agent nie zmieni: zablokowane ścieżki, bramki w CI, ukryte sprawdzenia kontrolne.

Polecenie /goal Autonomiczne przebiegi sterowane celem, narzędzie po narzędziu.

Spec-driven development Przeglądasz specyfikację, a nie kod.

Znajdź swój poziom Dwadzieścia pięć pytań, które umieszczą twoją pracę na drabinie.