Poziom 3: przeglądasz diffy

Poziom 3 drabiny autonomii to etap, na którym agenci piszą większość kodu w równoległych sesjach, a programista czyta każdy diff przed scaleniem. Poziom 3 jest etapem, a nie celem: ogranicza go przepustowość review. Zespoły wychodzą z niego, przenosząc po jednej klasie zmian naraz z czytania linia po linii na dowody i automatyczne bramki.

Ta strona jest dla programistów, którzy już prowadzą dwóch lub więcej agentów naraz, i dla tech leadów, których kolejka review rośnie szybciej niż zespół. Pięciu agentów pracuje i czterech ma rację. Które cztery, dowiadujesz się przez czytanie, a czytanie jest tą częścią potoku, która nie przyspieszyła. CTO i zarząd mogą przejść od razu do sekcji o metrykach: definiuje cztery liczby, które pokazują, czy zespoły doszły do sufitu.

Co daje ci ten przewodnik po poziomie 3

• Test czterech punktów, który mówi, czy jesteś na poziomie 3, czy wciąż na poziomie 2.
• Konfigurację równoległych agentów w Claude Code, Codeksie i Cursorze wraz z komendami startowymi.
• Mapę tego, co robi automatyczne review w każdym narzędziu, i jeden szczegół, który decyduje, czy cokolwiek blokuje.
• Sześć kroków, które podnoszą sufit review, w tym krok w CI zamieniający review Claude Code w blokującą bramkę.
• Trzy prompty do skopiowania: zmierz kolejkę review, każ agentom przynosić dowody i zaprojektuj bramkę review.
• Kryteria wyjścia, po których klasa zmian przechodzi na czytanie dowodów zamiast kodu.

Czy jesteś na poziomie 3? Test czterech punktów

Drabina Dana Shapiro (The Five Levels: from Spicy Autocomplete to the Dark Factory, 23 stycznia 2026) opisuje poziom 3 trzema słowami: „Your life is diffs”, czyli „twoje życie to diffy”. Dodaje, że „almost everyone tops out here”: prawie wszyscy tu się zatrzymują. Jesteś na poziomie 3, gdy prawdziwe są wszystkie cztery zdania:

1. Agent pisze większość każdej zmiany. Poprawiasz jego wynik, ale pierwszą wersję piszesz rzadko.
2. Pracuje więcej niż jeden agent naraz, każdy we własnym checkoucie, a ty w tym czasie robisz coś innego.
3. Czytasz każdy diff przed scaleniem. O wyniku decyduje czytanie, nie agent.
4. Kolejka nieprzeczytanej pracy rośnie w ciągu dnia. Agenci kończą szybciej, niż ty przeglądasz.

Jeśli zdanie 2 jest fałszywe, jesteś na poziomie 2 i najpierw przyda ci się przewodnik po poziomach 1–2. Jeśli zdanie 3 jest fałszywe dla części zmian, a nic nie zastąpiło twojego czytania, nie jesteś na poziomie 4. Jesteś na poziomie 3 z wyłączonym sprawdzaniem i to najczęstszy sposób, w jaki ten szczebel się nie udaje.

Jak prowadzić równoległych agentów na poziomie 3?

Podstawą jest izolacja systemu plików: jeden worktree gita na agenta, więc równoległe zmiany nigdy nie dotykają tych samych plików. Drugim warunkiem jest jeden ekran, który pokazuje, które sesje cię potrzebują.

Claude Code

Każde zadanie uruchamiasz we własnym worktree, na pierwszym planie albo w tle (sprawdzone na Claude Code 2.1.285):

# Terminal: jedna odizolowana sesja na zadanie
claude --worktree feature-auth
claude --worktree fix-pagination --bg   # działa w tle, wypisuje id

# Terminal: widok agentów pokazuje każdą sesję w tle i to, czego potrzebuje
claude agents

Widok agentów (agent view) jest w research preview. Wewnątrz sesji wbudowany skill /batch dzieli jedną dużą zmianę na 5 do 30 jednostek, a każdą wykonuje subagent w tle we własnym worktree. Szczegóły: widok agenta w Claude Code.

Codex

Obsługa worktree jest domyślnie włączona od Codeksa 0.156.0, ale sesja działa w worktree tylko wtedy, gdy o to poprosisz (sprawdzone na codex-cli 0.157.1):

# Terminal: jedna sesja na zadanie, każda w nowym zarządzanym worktree gita
codex --worktree

# Terminal: przegląd wszystkich sesji agentów na lokalnym demonie app-server
codex agents

W TUI /worktree robi to samo dla trwającej sesji, a /agents otwiera centrum dowodzenia. Szczegóły: worktree w Codeksie.

Cursor

Cursor opisuje worktree jako jednostkę izolacji: „Worktrees let Agent work in isolated Git checkouts” (sprawdzone 2026-08-28; 2026-09-26 cursor.com był nieosiągalny ze środowiska, w którym powstała ta strona). Równoległych agentów uruchamiasz i obserwujesz w Agents Window. Zanim cokolwiek wokół tego oskryptujesz, sprawdź aktualne kroki w dokumentacji Cursora.

Worktree izolują pliki, a nie porty, bazy, cache ani wspólny serwer deweloperski. Przydziel każdemu agentowi własny blok portów i własny stan lokalny, inaczej dwa zielone przebiegi będą się kłócić o tę samą maszynę. Porty i stan opisuje przewodnik po worktree gita, resztę środowiska efemeryczne. Floty uruchamiane skryptem opisują tmux do flot agentów i herdr, multiplekser agentów.

Dlaczego przepustowość review jest sufitem poziomu 3

Generowanie skaluje się z liczbą agentów, czytanie z liczbą recenzentów. Dwa niezależne zbiory danych zmierzyły, co dzieje się pomiędzy.

Raport Faros AI AI Engineering Report 2026: The Acceleration Whiplash (kwiecień 2026) obejmuje dwa lata telemetrii z 22 000 programistów i ponad 4000 zespołów. Przepustowość wzrosła: ukończone epiki na programistę +66,2%, przepustowość zadań na programistę +33,7%, tempo scalania pull requestów na programistę +16,2%. W tym samym okresie jakość i review zostały z tyłu:

Miara Farosa (kwiecień 2026)	Zmiana	Co mówi
Mediana czasu w review	+441,5%	Kolejka: jak długo pull request siedzi w review
Mediana czasu do pierwszego review	+156,6%	Czas reakcji: ile trwa, zanim ktokolwiek zajrzy
Pull requesty scalone bez żadnego review	+31,3%	Review zamienia się w akceptację
Incydenty na pull request	+242,7%	Ile kosztowało pominięte czytanie
Błędy na programistę	+54%	To samo, liczone na osobę

Dane Farosa to telemetria dostawcy z jego własnej bazy klientów, więc traktuj je jako kierunek, a nie prognozę dla twojego zespołu. DX zmierzył to obciążenie w innej jednostce: mediana wielkości pull requesta wzrosła „from 44 lines to 72 lines per pull request between July 2025 and June 2026” (DX, Justin Reock, 17 czerwca 2026), czyli z 44 do 72 linii. Więcej diffów, większe diffy, ten sam czytelnik. Pełne liczby ze źródłami są na stronie o stanie inżynierii agentowej.

Co obejmuje automatyczne review w Claude Code, Codeksie i Cursorze?

Wszystkie trzy narzędzia mają automatycznego recenzenta. Żaden nie jest bramką scalania, dopóki go nią nie zrobisz.

	Claude Code	Codex	Cursor
Review lokalne	/code-review w sesji (/review to alias; --fix, --comment)	/review w TUI; codex review --base main albo codex exec review ze skryptu	Niesprawdzone tutaj (cursor.com nieosiągalny 2026-09-26)
Review pogłębione lub bezpieczeństwa	claude ultrareview [target] albo /code-review ultra: flota w chmurze, w której „every reported finding is independently reproduced and verified”, zwykle 5 do 10 minut	@codex security review na pull requeście (sprawdzone 2026-08-28)	Security Agents do przebiegu po podatnościach (sprawdzone 2026-08-28)
Review na pull requeście	Zarządzane Code Review: research preview, plany Team i Enterprise, strojone plikiem REVIEW.md w katalogu głównym	@codex review na GitHubie i GitLabie, review automatyczne, reguły w AGENTS.md (sprawdzone 2026-08-28)	Bugbot „reviews pull requests and identifies bugs, security issues, and code quality problems” (sprawdzone 2026-08-28)
Czy może zablokować scalenie?	Sam z siebie nie: check run „always completes with a neutral conclusion”	Nieudokumentowane (sprawdzone 2026-08-28)	PR Routing & Approval „can approve low-risk PRs when your criteria are met” (sprawdzone 2026-08-28)

Wiersze Claude Code sprawdzono w dokumentacji Anthropic i w claude --help 2026-09-26, wiersze CLI Codeksa w codex --help 0.157.1. Ultrareview i Code Review rozliczane są w kredytach użycia; aktualne kwoty i limity planów znajdziesz w automatycznych przeglądach kodu w Claude Code. Konfigurację opisują przewodniki po review w Codeksie i Bugbocie w Cursorze.

Automatyczny recenzent, który nie umie zablokować, jest drugą opinią. Podnosi sufit dopiero wtedy, gdy zdecydujesz, które jego znaleziska blokują build.

Jak podnieść sufit review na poziomie 3?

Sześć kroków, w tej kolejności. Każdy zdejmuje z ludzkiej kolejki jedną kategorię pracy, zanim zacznie się następny.

1. Zmierz kolejkę. Dla każdego repozytorium zapisz medianę czasu do pierwszego review, medianę czasu w review i medianę wielkości pull requesta z ostatnich 50 do 100 scalonych pull requestów. Użyj pierwszego promptu poniżej. Bez punktu odniesienia nie ocenisz, czy którykolwiek późniejszy krok pomógł.

2. Spraw, żeby bramka deterministyczna blokowała. Typy, testy, lint, sprawdzenie schematu i grep po wzorcu, z którego migrujesz, kończą się kodem różnym od zera przy błędzie. Nic nie kosztują i nie da się ich przegadać. Oznacz je jako wymagane checki, żeby żaden pull request nie trafił do człowieka, póki któryś jest czerwony.

3. Pozwól automatycznemu recenzentowi blokować build na krótkiej liście. Wybierz klasy znalezisk, którym ufasz, na przykład znaleziska Important w Claude Code Review, i blokuj tylko na nich. Claude Code zapisuje w check runie liczbę znalezisk według wagi w formie czytelnej dla maszyny, a krok CI może ją odczytać tokenem z dostępem do odczytu checków:

   # Krok CI, po zakończeniu check runu "Claude Code Review"
   CHECK_RUN_ID=$(gh api "repos/$OWNER/$REPO/commits/$SHA/check-runs" \
     --jq '.check_runs[] | select(.name=="Claude Code Review") | .id')
   counts=$(gh api "repos/$OWNER/$REPO/check-runs/$CHECK_RUN_ID" \
     --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson')
   important=$(echo "$counts" | jq -e '.normal') || { echo 'No severity counts in check run'; exit 1; }
   if [ "$important" != "0" ]; then
     echo "Claude Code Review reported $important Important findings"
     exit 1
   fi

   Pierwsze wywołanie znajduje ID check runu Claude Code Review dla commita $SHA, tak jak opisuje to strona Code Review w dokumentacji Anthropic. Klucz normal zawiera liczbę znalezisk Important. Dzięki jq -e krok zawodzi bezpiecznie: jeśli check run nie zawiera liczby znalezisk według wagi, build się zatrzymuje, zamiast przejść.

4. Każ agentom przynosić dowody, a nie streszczenie diffa. Każdy pull request agenta podaje zmienione zachowanie, przypisuje każde kryterium akceptacji do sprawdzenia, które faktycznie się wykonało, i wymienia każdy dotknięty plik testów, fixture’ów albo CI. Wstaw drugi prompt poniżej do pliku kontekstu albo szablonu zadania.

5. Podziel kolejkę według klas ryzyka. Uwierzytelnianie i autoryzacja, pieniądze, schemat, migracje danych i każda zmiana, która edytuje własne testy, zawsze dostają ludzkiego czytelnika. Resztę można oceniać na podstawie dowodów. Code review PR-a agenta zamienia to w protokół sześciu kroków z werdyktami.

6. Przenieś jedną klasę zmian na review dowodów. Wybierz klasę z najmocniejszymi sprawdzeniami, na przykład podbicia zależności albo zmiany tekstów, i zatwierdzaj ją na podstawie dowodów z kroku 4, a całą resztę dalej czytaj. Kryteria wyjścia poniżej mówią, kiedy klasa jest gotowa.

Osoba, która zatwierdza, się nie zmienia: każde scalenie zatwierdza wskazany recenzent. Zmienia się to, co ta osoba czyta. Na poziomie 3 czyta diff; po przeniesieniu każdej klasy czyta dowody, a diff już tylko w klasach eskalacji.

Prompty do skopiowania, które podnoszą sufit review na poziomie 3

Prompt do skopiowania: zmierz swój sufit review

Measure this repository's review queue. Use the GitHub CLI:
gh pr list --state merged --limit 100 --json number,author,createdAt,mergedAt,additions,deletions,reviews,body
For each pull request compute: time to first review (createdAt to the earliest
review's submittedAt), time in review (createdAt to mergedAt), size (additions +
deletions), and whether it merged with zero reviews. Mark a PR as agent-authored
when its author is a bot account or its body names an agent.
Output one table with the median of each measure, split into agent-authored and
human-authored, and into size buckets under 100, 100-400 and over 400 lines.
Then list the five PRs that waited longest for a first review. Do not estimate:
if a field is missing, say so and leave the cell empty.

Prompt do skopiowania: podsumowanie dowodów w każdym pull requeście agenta

Before you open the pull request, write its description in this order and
nothing else:
1. Behaviour change: two sentences on what a user or caller now sees that they
   did not see before. No file-by-file summary of the diff.
2. Acceptance evidence: one line per acceptance criterion, as
   criterion -> command or test name -> result. Run every command yourself;
   paste the exit code, not your expectation.
3. Oracle changes: every test, fixture, snapshot, lint or CI file you added,
   edited or deleted, with one line on why. Write "none" if there are none.
4. Risk flags: say yes or no to each of authentication, authorization, money,
   schema, data migration, public API. For each yes, name the file.
5. Unsure: anything you guessed, skipped or could not verify.
If any command in section 2 failed, do not open the pull request; fix it or
stop and report.

Prompt do skopiowania: zaprojektuj bramkę review dla repo, w którym piszą agenci

Design the review gate for this repository, given that agents open most of the
pull requests. Read .github/workflows, CODEOWNERS, the test scripts and the last
50 merged PRs first, and then output exactly four things.
1. The classes of change that may merge on a green pipeline alone, each with the
   command that proves it and the file globs that identify it.
2. The classes that always need a human reader, with the same globs, and one
   sentence each on the blast radius that earns them a human.
3. The automated review layer in between: which tool runs, on what diff size,
   what it may block on, and what it may only comment on.
4. The single metric that tells us the gate is failing: name it, say where it
   is measured today, and give the threshold that triggers a change.
Propose nothing you cannot enforce with a file in this repository.

Co mierzą tech leadzi, CTO i zarząd na poziomie 3?

Cztery miary liczone dla każdego repozytorium pokazują, czy zespół doszedł do sufitu. Przyjmij definicje w tej postaci, a progi ustal na podstawie własnego punktu odniesienia z ostatniego kwartału, nie liczb innej firmy.

Miara	Definicja	Sygnał sufitu
Czas do pierwszego review	Mediana godzin od otwarcia pull requesta do pierwszego przesłanego review	Rośnie razem z liczbą agentów
Czas w review	Mediana godzin od otwarcia do scalenia	Rośnie szybciej niż tempo scalania
Udział scaleń bez review	Scalone pull requesty bez żadnego review podzielone przez wszystkie scalone	Każdy wzrost, na który nie pozwala spisana polityka
Mediana wielkości pull requesta	Mediana sumy dodanych i usuniętych linii	Rośnie ponad to, co jeden recenzent przeczyta za jednym posiedzeniem

Najważniejszy jest rosnący udział scaleń bez review. Oznacza, że recenzenci przestali czytać, a żadna bramka nie zajęła ich miejsca. Obsadę i kierowanie kolejką opisuje przewodnik po kolejce review w zespole.

Co się psuje, gdy pięciu agentów dzieli jednego recenzenta?

Kolejka rośnie, zanim ktokolwiek zauważy

Objaw: każdy pull request wygląda rozsądnie, a czas do pierwszego review podwaja się w ciągu miesiąca. Wyjście: uruchamiaj prompt pomiarowy co dwa tygodnie, ogranicz liczbę równoległych agentów na recenzenta do poziomu, przy którym kolejka stoi w miejscu, a odzyskany czas przeznacz na krok 2 z listy powyżej.

Review zamienia się w przybijanie pieczątek

Objaw: akceptacje przychodzą kilka minut po otwarciu pull requesta na 400 linii. Wyjście: nazwij klasy, które mogą wejść na podstawie dowodów (krok 6), a dla reszty wymagaj prawdziwego czytania. Uczciwa bramka mówi, które klasy wchodzą nieprzeczytane; recenzent, który przestał czytać i nikomu nie powiedział, to właśnie awaria zmierzona przez Farosa.

Wszyscy przewijają automatycznego recenzenta

Objaw: bot komentuje każdy pull request, a nikt nie reaguje na jego znaleziska. Wyjście: blokuj na jednej klasie znalezisk (krok 3), resztę zamień w komentarze i strój instrukcje recenzenta (REVIEW.md w katalogu głównym dla Claude Code Review, reguły review w AGENTS.md dla Codeksa), aż jego blokujące znaleziska będą trafne w większości przypadków.

Równolegli agenci zderzają się poza repozytorium

Objaw: dwa worktree przechodzą osobno, a razem padają, albo migracja jednego agenta psuje testy drugiego. Wyjście: przydziel każdemu worktree własny blok portów i własną bazę, a serwery deweloperskie uruchamiaj na tych portach zamiast domyślnych.

Diff jest za duży, żeby przeczytać go uczciwie

Objaw: pull request przekracza to, co człowiek utrzyma w głowie, albo Ultrareview odrzuca go jako za duży. Wyjście: zwróć go i podziel zadanie: jedno zadanie agenta, jedna sprawa, jeden pull request. Szybszy czytelnik tego nie naprawi.

Kiedy klasa zmian jest gotowa do wyjścia z poziomu 3?

Wychodź po jednej klasie naraz, nigdy całym repozytorium. Klasa zmian jest gotowa do review dowodów, gdy spełnione są wszystkie cztery warunki:

• Bramka deterministyczna dla tej klasy jest wymaganym checkiem i zablokowała już co najmniej jedną złą zmianę.
• Agenci nie mogą niepostrzeżenie osłabić wyroczni: każda zmiana testów, fixture’ów albo CI w tym samym pull requeście kieruje go do człowieka.
• Każdy pull request w tej klasie zawiera podsumowanie dowodów z drugiego promptu.
• Twoje czytanie serii ostatnich pull requestów w tej klasie (na przykład ostatnich 10) nie znalazło niczego, co umknęło sprawdzeniom.

Prowadź krótki dziennik zaufania: klasa, kiedy przeszła i co ją cofnęło. Czytanie dowodów zamiast kodu wyjaśnia, co czytasz zamiast diffa i po czym poznać, że przestałeś czytać za wcześnie. Code review PR-a agenta to codzienny protokół oceny. Gdy większość scalanych zmian zatwierdzasz na podstawie dowodów, przebiegi mogą trwać godzinami i zaczyna się poziom 4.

Dokąd dalej z poziomu 3

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

Code review PR-a agenta Sześć kroków: akceptacja, zwrot albo eskalacja bez czytania każdej linii.

Poziom 4: piszesz specyfikacje Warunki stopu, hooki i przebiegi, od których można odejść.

Warstwowe review pull requestów Trzywarstwowa bramka i dlaczego PR-y od agentów jej potrzebują.

Automatyzacja review PR w zespole Warstwowi recenzenci AI w skali zespołu.

Jedna mapa Drabina, cykl życia i stacje fabryki na jednej siatce.

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