Strukturyzacja zmian — Explore → Plan → kod → PR → review-fix

Q25 · Operacje i higiena Jak strukturyzujesz nietrywialną zmianę?

Maksymalna odpowiedź: “Pełna pętla: parallel Explore subagents → Plan mode → kod → auto-PR → review-fix loop.”

Dlaczego to ważne: Pomijanie researchu i planowania to największy single failure mode w 2026. Pewność agenta to nie poprawność.

Dlaczego to ważne w 2026 (pewność ≠ poprawność, top failure mode)

Największy leak w agent-first workflow 2026 to nie model, nie IDE i nie stack MCP — to fakt, że pewny siebie agent z entuzjazmem napisze 400 linii wiarygodnie wyglądającego kodu w złym kierunku, w złym pliku, przeciwko złej abstrakcji i zakończy tym samym spokojnym “Done!”, którym podsumowałby poprawną zmianę. Pewność nie równa się poprawności. Największym pojedynczym kontrybutorem do zmarnowanego budżetu tokenów i wall-clock time na nietrywialnych zadaniach jest “wrong-direction rework” — sesje, w których model wprowadził edycje w kierunku, który użytkownik odrzuciłby w pierwszych sześćdziesięciu sekundach, gdyby zobaczył plan. Model produkuje rozkład prawdopodobieństwa nad tekstem, nie nad codebase’em; bez wymuszonego researchu i planowania sięgnie po najbardziej płynnie brzmiącą odpowiedź zamiast najbardziej poprawnej. Rozwiązanie jest strukturalne, nie motywacyjne. Nie naprawisz confidence-not-correctness przypominając sobie, żeby być ostrożnym. Naprawisz to robiąc z “research pierwszy, plan drugi, kod trzeci, ship czwarty, fix piąty” jedyną ścieżkę, którą agent ma prawo przejść — podpinając każdy etap do innego mechanizmu, żeby żaden krok nie mógł zostać pominięty bez Twojej wiedzy. To jest pięciofazowa pętla, a Q25 to operational hygiene check, który pyta, czy faktycznie ją zbudowałeś.

Jak naprawdę wygląda maksymalny wynik (pięciofazowa pętla, prawdziwy przykład)

Maksymalny wynik na Q25 to setup, w którym każda nietrywialna zmiana przechodzi przez pięć mechanicznie odrębnych faz. Faza 1: parallel Explore subagents mapują odpowiednie pliki, call sites, testy i API w izolowanych read-only kontekstach i zwracają zwięzłe podsumowania do głównej sesji. Faza 2: Plan mode zamienia research w explicit, plik-po-pliku plan, który czytasz i iterujesz, zanim cokolwiek dotknie dysku. Faza 3: kod wykonuje zatwierdzony plan z planem przypiętym jako kotwica. Faza 4: auto-PR odpala się w momencie, gdy praca się kończy — Stop hook commituje, pushuje, otwiera PR. Faza 5: review-fix loop wybudza agenta, gdy CodeRabbit, Copilot Code Review, ludzki reviewer albo failujący GitHub Actions check zostawią nowe komentarze, adresuje te actionable i re-pushuje z bounded backoffem aż komentarze przestaną przychodzić.

Konkretny przykład. Zadanie: “wymień Stripe Checkout na Polar.” Agent w direct-edit otworzyłby checkout.ts, podmienił SDK, pushnął i popsuł trzy webhook handlery, dwa test fixtures i Cloudflare Workers binding, których nigdy nie przeczytał. Maksymalna pętla zamiast tego spawnuje trzy Explore subagents równolegle — mapując call sites stripe, czytając webhook handlery i testy, ściągając docs Polar SDK przez Context7 — zwracając trzy krótkie briefy w pod dwie minuty. Główna sesja wchodzi w Plan mode i pisze 14-stopniowy plan. Pushujesz back na krok 7 (“webhook secret powinien być Cloudflare secret, nie env var”), iterujesz dwa razy, zatwierdzasz. Agent koduje z planem przypiętym. Stop hook commituje, pushuje, otwiera PR. CodeRabbit zostawia trzy komentarze — dwa LGTM, jeden actionable nit o brakującym await. Agent poprawia, pushuje, czeka cztery minuty, nie dostaje nowych komentarzy, kolejkuje gh pr merge --auto. Łączny wall-clock: ~35 minut na zmianę, która w direct-prompt loop kosztowałaby ~3 godziny edit-then-debug. To jest gap, który Q25 mierzy.

Niższe tiery mapują się czysto na brakujące fazy. 0 pkt: promptujesz i mergeujesz ręcznie. 1 pkt: Faza 2 na dużych taskach, ale brak parallel research. 2 pkt: Fazy 2 i 4 wpięte, ale Faza 1 zaśmieca główny kontekst, a Faza 5 to “sprawdzę później.” 3 pkt (max): wszystkie pięć faz wpiętych razem, chodzą domyślnie.

Aktualny krajobraz (zweryfikowany przez web search)

Elementy pętli to dziś standardowe mechanizmy 2026 — tylko rzadko zostają złożone end-to-end. Każda faza ma swój tooling, swoje quirki i swoje failure mode’y, a dźwignia płynie z podpięcia ich tak, by output jednej był inputem następnej bez ręcznego hand-offu.

Faza 1: Parallel Explore subagents (research w izolowanym kontekście)

Explore subagent to jeden z trzech wbudowanych typów subagentów Claude Code w 2026 (obok Plan i General-purpose) i najbardziej niedoużywany prymityw w stacku. Z założenia read-only, chodzi na Haiku, operuje w swoim oknie kontekstu, więc research nie zaśmieca tokenów głównej sesji. Gdy zadanie dotyka więcej niż trzech plików, spawnujesz dwa do czterech Explore subagentów w jednym turnie, każdy z ciasno zdefiniowanym pytaniem badawczym (“zmapuj każdy plik importujący stripe”, “przeczytaj testy webhooków i podsumuj kontrakt”, “pobierz docs Polar SDK przez Context7”), a zwięzłe podsumowania mergeujesz z powrotem. Research task, który sekwencyjnie zająłby 15 minut, w paraleli zajmuje 3–4. Nieoczywista wygrana to ekonomia kontekstu: główna sesja trzyma czyste okno z tylko zsyntetyzowanymi briefami, nie z surowym outputem rg z pięćdziesięciu plików. To czyste okno sprawia, że Faza 2 działa. Pułapka: subagenty paralelizują się czysto tylko gdy paths nie zależą od siebie. Agent tabs Cursora (3.0+, kwiecień 2026) oferują podobny prymityw; Codex CLI nie ma natywnego w maju 2026 — najbliższy workaround to wiele shelli codex ze scoped promptami.

Faza 2: Plan mode (zamień research w podejście)

Plan mode to brama, która zamienia briefy z researchu w reviewable, plik-po-pliku plan, zanim cokolwiek dotknie dysku. W Claude Code Shift+Tab dwa razy (albo /plan od stycznia 2026); Cursor używa tego samego skrótu w oknie Agents; Codex CLI nie ma natywnego Plan mode — standardowy workaround to dwustopniowy prompt (“wyprodukuj tylko szczegółowy plan” → iteruj → “teraz wykonaj”) sparowany z --ask-for-approval on-request. Kluczowa dyscyplina to iteracja, nie akceptacja — dwa do pięciu rund przed zatwierdzeniem, pushowanie back na założenia, wymaganie konkretów, odrzucanie kroków już zrobionych, pytanie o rollback. Każda iteracja kosztuje ~20 sekund i oszczędza minuty wrong-direction edits. W Claude Code Ctrl+G otwiera plik planu w ~/.claude/plans/ w $EDITOR dla chirurgicznych edycji. Wklej zatwierdzony plan do prompta Fazy 3 explicit — nie polegaj na tym, że agent “zapamięta” go przez przejście trybów.

Faza 3: Kod (główna sesja, z planem jako kotwicą)

Gdy research jest zrobiony, a plan zatwierdzony, egzekucja powinna być tanią, mechaniczną fazą — agent przechodzi przez ponumerowane kroki planu z planem przypiętym jako load-bearing context. Dyscyplina: nie edytuj planu w trakcie kodu. Jeśli okaże się zły, zatrzymaj się, wyjdź z trybu edycji, wróć do Fazy 2, iteruj, dopiero potem wejdź ponownie. Nie pozwalaj agentowi po cichu zaimprowizować innego designu — to dokładnie ten wrong-direction rework, przed którym pętla chroni. Sparuj z Auto-Accept (Claude Code) albo YOLO mode (Cursor), żeby throughput nie zwalniał na ręcznym zatwierdzaniu diffów. Publiczny workflow Borisa Cherny’ego — “zaplanuj w Plan mode, zatwierdź, wskocz w Auto-Accept, odejdź” — to właściwy kształt. Clarifying questions tutaj oznaczają, że plan był underspecified; to bug Fazy 2, wróć, nie odpowiadaj inline.

Faza 4: Auto-PR (Stop hook)

Faza 4 to auto-PR Stop hook (omówiony szczegółowo w przewodniku Q16). W momencie, gdy główny turn agenta kończy się z niezatwierdzoną pracą albo niewypchanymi commitami, skrypt Stop hooka — zwykle ~/.claude/hooks/auto-pr-watch.sh — rozwiązuje default branch, branchuje od niego jeśli trzeba, stage’uje, commituje conventional message, pushuje i otwiera PR przez gh pr create. Agent nie siedzi czekając na “czy mam pushnąć?” — decyzja żyje w kodzie. Hook to deterministyczny shell wpięty w ~/.claude/settings.json. Bez Fazy 4 pętla zwija się do ręcznej księgowości, a Q25 czapuje na 2 punktach niezależnie od tego, jak dobre są Twoje Fazy 1–3.

Faza 5: Review-fix loop (auto-odpowiedź na CodeRabbit/CI/człowieka)

Faza 5 to część, którą większość pomija i powód, dla którego ich Q25 nie sięga maxa. Po otwarciu PR Stop hook obserwuje: top-level komentarze przez gh pr view --comments, inline review comments przez gh api repos/.../pulls/N/comments, review summaries przez gh api repos/.../pulls/N/reviews, status CI przez gh pr checks. Gdy CodeRabbit (od kwietnia 2026 na planach Pro spawnuje własnego coding agenta przez Autofix), Copilot Code Review (~71% actionable-feedback rate per telemetria GitHuba 2026), ludzki reviewer albo failujący run GitHub Actions zostawi nowe komentarze, hook porównuje względem zapisanej sygnatury (action, branch/PR#, head_sha, max_comment_id) i wybudza agenta promptem fix. Agent czyta każdy actionable komentarz, implementuje fix, commituje, pushuje, a hook czeka 4 minuty → 12 minut — 4 minuty mieszczą się w TTL prompt-cache, 12 minut pokrywa wolniejsze CI i ludzkie follow-up. Gdy pętla osiada, gh pr merge --squash --delete-branch --auto kolejkuje merge. Nigdy --admin-override. Plik sygnatury jest tym, co sprawia, że pętla naturalnie terminuje.

Krok po kroku: ustaw pełną pętlę jako default

Audyt ostatnich dziesięciu nietrywialnych zmian. Dla każdej oznacz, które z pięciu faz faktycznie chodziły. Jeśli mniej niż siedem z dziesięciu odpaliło wszystkie pięć, reszta tego przewodnika to fix.
Wepnij trigger Fazy 1. Napisz slash command (.claude/commands/explore-then-plan.md), który otwiera się od “Spawnij trzy Explore subagenty równolegle: zmapuj wszystkie odpowiednie pliki, przeczytaj testy, pobierz zewnętrzne docs przez Context7. Poczekaj na wszystkie trzy, potem wejdź w Plan mode.” Teraz Faza 1 to jeden klawisz. Dla Cursora — zapisany prompt Composera; dla Codex CLI — shell alias.
Ustaw Plan mode jako default boot state. Wciśnij Shift+Tab dwa razy (albo /plan) w momencie odpalania Claude Code, zanim wpiszesz zadanie. Traktuj to jak pasy: nie wybór, odruch. Pełny przewodnik Q6 ma protokół budowania nawyku.
Przypnij zatwierdzony plan do prompta Fazy 3. Wklej zatwierdzony plan do następnej wiadomości jako explicit kotwicę: “Wykonaj ten plan. Nie improwizuj. Jeśli któryś krok okaże się zły, zatrzymaj się i spytaj.” Ta linia to różnica między Fazą 3 trzymającą się na szynach a agentem po cichu przeplanowującym mid-code.
Zainstaluj auto-PR Stop hook. Wepnij ~/.claude/hooks/auto-pr-watch.sh do ~/.claude/settings.json z matcherem Stop. Skrypt powinien dynamicznie rozwiązywać default branch, decydować między ship / fix / noop z sygnatury repo i albo sterować gh bezpośrednio, albo re-wake’ować agenta. Przewodnik Q16 ma szkielet skryptu.
Dostroj backoff Fazy 5 do tempa review. 4 minuty → 12 minut to field-tested default. Z CodeRabbit Pro Autofix dodaj trzeci wait 25-minutowy. Plik sygnatury ~/.claude/auto-pr-state/<hash>.json sprawia, że pętla terminuje sama.
Udokumentuj opt-out phrase. Wybierz zdanie typu “don’t make a PR for this” — agent pomija Fazę 4. Zawór bezpieczeństwa dla spike’ów i prototypów. Dodaj do CLAUDE.md projektu.
Rób audyt tygodniowo przez dwa tygodnie. Target: >70% nietrywialnych zmian przeszło wszystkie pięć faz. Jeśli poniżej, slash command Fazy 1 się nie przyjmuje — zrób go bardziej widocznym. Po dwóch tygodniach >70% pętla jest samopodtrzymująca.

Częste pułapki

Pomijanie Fazy 1, bo “znam codebase.” Najczęstszy failure mode 2026, na który scorecard celuje. Nawet na codebase, który sam napisałeś, model go nie zna — a parallel Explore subagents są tanie (Haiku, izolowany kontekst, 3–4 minuty wall-clock). Koszt pojawia się jako wrong-direction rework w Fazie 3.
Plan mode jako pieczątka. Ekspercka iteracja to dwie do pięciu rund, pushowanie back na założenia i wymaganie konkretów. Zatwierdzenia poniżej 30 sekund na nietrywialnych taskach oznaczają pieczątkowanie.
Ignorowanie planu w trakcie kodu. Agent czasem zauważy “lepsze” podejście i po cichu je weźmie. Przypnij plan w prompcie, każ agentowi zatrzymać się i spytać, porównaj diff z planem przed merge.
Brak review-fix loop. “Mam hooka, który otwiera PR-y, ale przeglądy sprawdzam ręcznie” to mid-tier. Późne komentarze to norma — CodeRabbit follow-up’uje 30–90 sekund po pushu, Copilot 2–5 minut, ludzie w skali godzin. Bez bounded backoff loop płacisz podatek review-roundtrip.
Traktowanie każdego komentarza jako actionable. Acknowledgements, off-topic chatter i pytania już odpowiedziane nie powinny triggerować cyklu Fazy 5. Filtruj explicit.
--admin-override na auto-merge. Nigdy. Failujące checki i CHANGES_REQUESTED reviewy to realne blokery — pętla je wynosi, nie obchodzi.
Brak pliku sygnatury. Bez per-repo sygnatury Stop hook spamuje PR albo zaklinowuje agenta w nieskończonej pętli Fazy 5. Sygnatura sprawia, że Faza 5 terminuje.
Mylenie “zweryfikowane” z “przetestowane.” Bot reviews nie zastępują E2E weryfikacji (Q18). Sparuj pętlę z agent-driven E2E.

Jak zweryfikować, że jesteś na miejscu

Na nietrywialnych taskach spawnujesz dwa do czterech parallel Explore subagentów przed planowaniem, a ich podsumowania wracają do czystego głównego kontekstu.
Plan mode jest default boot state — decydujesz czy go pominąć, nie czy użyć.
Iterujesz w Plan mode dwa do pięciu razy przed zatwierdzeniem; zatwierdzenia poniżej 30 sekund są rzadkie.
Zatwierdzony plan jest przypięty do prompta Fazy 3 jako explicit kotwica.
Gdy praca się kończy, PR pojawia się na GitHubie bez ręcznego gh pr create.
Gdy CodeRabbit / Copilot / człowiek / failujący CI zostawi komentarze, agent budzi się i adresuje je w ~5 minut.
Auto-merge jest kolejkowany przez --auto, nigdy forsowany przez --admin.
Opt-out phrase (“don’t make a PR for this”) faktycznie pomija Fazę 4.
Przez pełny tydzień ponad 70% nietrywialnych zmian przeszło wszystkie pięć faz end-to-end.

Dalsza lektura

Q6 · Plan mode Brama Fazy 2 — Shift+Tab dwa razy lub /plan, iteruj przed zatwierdzeniem, potem Auto-Accept.

Q12 · Własne subagenty Prymityw Fazy 1 — Explore / Plan / General-purpose plus Twoje własne subagenty.

Q16 · Auto-PR workflow Mechanika Fazy 4 + Fazy 5 — Stop hook, review-fix loop, gh pr merge --auto.

Zrób Developer Scorecard Oceń się w 25 pytaniach w ~10 minut.