Plan mode — domyślna bramka dla każdej nietrywialnej zmiany
Pytanie scorecard: Jak często używasz Plan mode? Odpowiedź na maks: Domyślnie dla każdej nietrywialnej zmiany; wychodzę tylko po akceptacji.
Dlaczego to ma znaczenie w 2026
Dział zatytułowany „Dlaczego to ma znaczenie w 2026”Plan mode to najtańszy, najbardziej dźwigniowy pas bezpieczeństwa w setupie agent‑first w 2026, a różnica między “używam jak pamiętam” a “to mój default” jest największym pojedynczym predyktorem throughputu na trudnych zadaniach. Mechanika jest prosta — agent wchodzi w twardy read‑only sandbox, czyta pliki, robi lookupy i odsyła plan, który musisz jawnie zaakceptować zanim cokolwiek z efektami ubocznymi się wydarzy — ale efekty drugiego rzędu się akumulują. Bramkuje side effecty (żadnego rogue rm -rf, żadnej w połowie zaaplikowanej migracji, żadnego przedwczesnego przepisania pliku w środku eksploracji). Wymusza jawny research, co oznacza że agent faktycznie przeczytał call sites i testy zanim zaproponuje diff, zamiast wymyślać go z czuja. I zabija najdroższy failure mode nieograniczonych agentów w 2026: pętlę reworku “w złą stronę”, w której model commituje 30 minut edycji w kierunku, który użytkownik odrzuciłby w pierwsze 60 sekund, gdyby zobaczył plan. Boris Cherny, twórca Claude Code, powiedział publicznie na początku 2026, że większość jego sesji zaczyna się w Plan mode, a workflow którego używa to “start w Plan, iteracja aż plan jest dobry, potem switch na Auto‑Accept i niech Claude executuje”. To max‑score workflow Q6 w jednym zdaniu. Zasada 80/20, którą cytują top deweloperzy AI‑assisted — 80% czasu na planowanie, 20% na nadzór nad execution — działa tylko, jeśli krok planowania jest strukturalnie wymuszony przez narzędzie, nie zostawiony dyscyplinie. Plan mode jest tym, co czyni to strukturalnym.
Jak wygląda “maks” — codzienny workflow z Plan mode jako defaultem
Dział zatytułowany „Jak wygląda “maks” — codzienny workflow z Plan mode jako defaultem”Max‑score setup Q6 wygląda tak samo dzień w dzień: każda nietrywialna sesja agentowa zaczyna się w Plan mode odruchowo, nie z intencji. Nie decydujesz czy planować — narzędzie startuje w Plan, a Ty musisz aktywnie zdecydować, żeby ten krok pominąć (czego dla nietrywialnej pracy nie robisz). Konkretnie: otwierasz Claude Code, naciskasz Shift+Tab dwukrotnie (albo wpisujesz /plan od stycznia 2026) zanim opiszesz zadanie, i status w dolnym pasku świeci się na cyan “plan mode on”. Opisujesz zadanie w 2–4 zdaniach. Agent czyta odpowiednie pliki, robi rg albo grep po kodzie, zadaje jedno‑dwa pytania doprecyzowujące, jeśli zadanie jest niejednoznaczne, i pisze plan — numerowaną listę zmian w plikach, plan testów i ryzyka. Czytasz plan uważnie. Jeśli jest źle, iterujesz w środku Plan mode: “nie, auth check powinien być w middleware, nie w handlerze route”, albo “pomiń krok 4 — już zrobione w #1842”. Kiedy plan wygląda dobrze, akceptujesz przez prompt ExitPlanMode, i dopiero wtedy agent przechodzi w Auto‑Accept (albo normalny edit mode) i wykonuje. Dla trywialnej pracy — literówka, jednolinijkowa zmiana w configu, update komentarza — wychodzisz z Plan mode świadomie, ale to wyraźna mniejszość. Dyscyplina, na którą jesteś oceniany, to nie “planuj wszystko” — to “planuj domyślnie, wychodź świadomie”.
Niższe tiery są łatwe do rozpoznania. 0 pkt (“nigdy nie używam Plan mode”): słyszałeś o tym, może raz spróbowałeś, ale każda sesja to direct edit‑mode. Regularnie patrzysz, jak agent commituje edycje w kierunku, który chcesz od razu cofnąć. 1 pkt (“czasami, na duże refactory”): sięgasz po Plan mode, gdy zadanie wygląda groźnie, ale default to direct execution. Wciąż obrywasz reworkiem “w złą stronę” na średnich zadaniach, gdzie nie chciało Ci się planować. 2 pkt (“często, na złożone taski”): Plan mode jest w polu widzenia dla wszystkiego, co multi‑file, ale zadania graniczące z trywialnym wciąż prześlizgują się do direct execution. 3 pkt (maks): Plan mode jest domyślny. Drzewo decyzyjne się odwróciło — decydujesz, czy pominąć, nie czy użyć. W ciągu pełnego tygodnia sesji agentowych Plan mode obejmuje >70% Twoich interakcji, a przypadki, w których pomijasz, są naprawdę trywialne.
Aktualny krajobraz (zweryfikowany web search)
Dział zatytułowany „Aktualny krajobraz (zweryfikowany web search)”Plan mode w 2026 to feature z trzema bardzo różnymi implementacjami w trzech narzędziach Tier 1 — Claude Code, Cursor Agents i Codex — a jedno z nich (Codex CLI) nie ma w ogóle natywnej bramki planowania. Znajomość różnic to różnica między “Plan mode jako default” a potykaniem się o quirki narzędzia co drugą sesję.
Plan mode w Claude Code (Shift+Tab, narzędzie ExitPlanMode, plik planu w ~/.claude/plans/)
Dział zatytułowany „Plan mode w Claude Code (Shift+Tab, narzędzie ExitPlanMode, plik planu w ~/.claude/plans/)”Claude Code ma najgłębszy i najlepiej udokumentowany Plan mode z całej trójki. Aktywujesz go przez dwukrotne naciśnięcie Shift+Tab, by przejść przez tryby (default → auto‑accept → plan), albo — od stycznia 2026 — wpisując /plan. /plan to najlepiej widoczne wejście i to powinieneś uczyć członków zespołu. Plan mode to twardy read‑only sandbox: Claude fizycznie nie może edytować ani uruchamiać narzędzi z efektami ubocznymi, co jest dokładnie powodem, dla którego jest bezpieczny na produkcyjnym kodzie albo w nieznanych repo. Agent używa Plan mode, żeby czytać pliki (Read, Grep, Glob), zadawać pytania i pisać plan do pliku pod ~/.claude/plans/. Kiedy akceptujesz plan przez prompt narzędzia ExitPlanMode, Claude przechodzi z Plan mode i wykonuje — typowo wprost w Auto‑Accept, jeśli stamtąd przyszedłeś, albo z powrotem do default mode. Znane quirki: jeśli startujesz Claude Code z --dangerously-skip-permissions i potem togglujesz do Plan przez Shift+Tab, flow potwierdzenia ExitPlanMode może nie przełączyć z powrotem do act mode (GitHub issue #32934, naprawione w niedawnych wersjach — zaktualizuj, jeśli trafisz). Osobna pułapka to to, że Claude czasem robi edycje, mając wciąż flagę Plan mode, jeśli agent zgubi swój stan trybu (issue #21292); aktualizuj Claude Code co miesiąc, żeby być przed tym. Power move: naciśnij Ctrl+G, żeby otworzyć plik planu w $EDITOR i edytować bezpośrednio — szybciej i precyzyjniej niż opisywanie edycji w chacie.
Tryby Cursor Agents
Dział zatytułowany „Tryby Cursor Agents”Plan mode w Cursor żyje w oknie Agents (Cursor 3.0+, wydany 2 kwietnia 2026). Skrót jest ten sam — Shift+Tab w input agenta — i mechanika ta sama: agent bada kod, zadaje pytania doprecyzowujące i produkuje review’owalny plan zanim cokolwiek edytuje. Twist Cursora to to, że od 3.0 każdy tab agenta trzyma własny mode, model i worktree, więc możesz zaparkować agenta Plan mode na Opus 4.7 szkicującego refactor w jednym tabie, podczas gdy drugi agent Agent‑mode na Composer 2.5 implementuje inny ticket równolegle. Rekomendowany workflow Cursora na złożone taski to Plan → Ask → Agent: planuj kształt, używaj Ask na pytania i investigation, potem przekaż do Agent na execution. Mocne strony: najgładszy UX, in‑editor diff review w czasie planowania. Słabe: output planu nie jest persistowany jako plik, jak ~/.claude/plans/ Claude’a, więc ciągłość planu między sesjami wymaga więcej wysiłku. Bias: używaj Plan mode Cursora do feature development w IDE; używaj Plan mode Claude Code do refactorów cross‑cutting, które korzystają z research terminal‑native.
Codex /plan-mode (tylko web) i workaroundy CLI
Dział zatytułowany „Codex /plan-mode (tylko web) i workaroundy CLI”To jest gotcha. /plan-mode Codexa (albo /plan [opis] zgodnie z docsami OpenAI z kwietnia 2026) istnieje tylko w web app Codexa — w surface’ie Codex hostowanym przez ChatGPT. Codex CLI nie ma natywnej bramki planowania. Żadnego cycle’a Shift+Tab, żadnego slash command /plan, żadnego promptu narzędzia ExitPlanMode. Jeśli używasz Codex CLI jako primary albo secondary tool, potrzebujesz workaroundu, żeby zdobyć maks w Q6. Standardowy pattern w 2026 to dwukrokowy prompt: pierwszy prompt prosi Codex o “wyprodukuj szczegółowy plan wdrożenia — nie pisz ani nie edytuj plików”, czekasz na plan, iterujesz promptując zmiany, i dopiero kiedy plan jest dobry, promptujesz “teraz wykonaj ten plan”. Sparuj to z --ask-for-approval on-request (albo untrusted), żeby edycje plików i komendy shell wciąż wymagały jawnej akceptacji — to jest Twoja bramka. Drugi pattern to planowanie w Codex web (gdzie /plan-mode jest natywne), potem przekazanie zaakceptowanego planu do Codex CLI na execution. Oba działają; oba zdobywają maks w Q6, bo bramka planowania jest wymuszona, nawet jeśli wymuszenie jest w Twoim prompt scaffoldingu, nie w narzędziu. Nie udawaj, że Codex CLI ma Plan mode — nie ma — ale nie pozwól, żeby to było wymówką do pomijania planowania.
Krok po kroku: jak zrobić Plan mode defaultem
Dział zatytułowany „Krok po kroku: jak zrobić Plan mode defaultem”- Zinwentaryzuj ostatnie 10 sesji agentowych. Otwórz historię shella, scrollback albo logi sesji dla Claude Code / Cursor / Codex. Dla każdej sesji zaznacz, czy startowała w Plan mode, czy weszła wprost w edit mode. Jeśli mniej niż 6 na 10 startowało w Plan, Twój obecny wynik Q6 to 0–1 pkt i reszta tego przewodnika jest fixem. Bądź szczery — score jest dla defaultu, nie intencji.
- Ustaw trigger, którego nie da się zignorować. Największe odblokowanie to zrobienie z “Shift+Tab dwa razy” albo “
/plan” pierwszej rzeczy, którą robią Twoje ręce po uruchomieniu Claude Code, zanim wpiszesz zadanie. Traktuj to jak pasy: nie wybór, odruch. Przez tydzień nakleil karteczkę na monitorze z napisem “Plan first”. Większość ludzi internalizuje to w 3–4 dni. - Wpisz to do swoich slash commands i skills. Napisz slash command
/explore-then-plan(Claude Code:.claude/commands/explore-then-plan.md), który wchodzi w Plan mode i instruuje agenta “najpierw przeczytaj odpowiednie pliki i testy, potem napisz plan z file paths, test plan i ryzykami”. Teraz Plan mode to jedno naciśnięcie zamiast dwóch, i shipuje się z właściwym promptem startowym za każdym razem. Dla Cursora ekwiwalent to zapisany prompt Composera; dla Codex CLI — alias shell, który prependuje plan‑only scaffold. - Opanuj iterację planu, nie akceptację planu. Amatorski ruch to “agent napisał plan, plan wygląda ok, akceptuj”. Ruch eksperta to iterowanie w środku Plan mode 2–5 razy przed akceptacją. Wypychaj założenia, żądaj konkretów (“który plik, która funkcja, który test”), odrzucaj kroki, które są już zrobione, pytaj o rollback. Każda iteracja kosztuje ~20 sekund i oszczędza minuty edycji w złą stronę. W Claude Code Ctrl+G otwiera plik planu w
$EDITOR— używaj do chirurgicznych edycji, do których model nie dotrze przez chat. - Zdecyduj swoją zasadę “pomiń plan” i trzymaj się. Czasem pominiesz Plan mode — literówki, jednolinijkowe zmiany configu, update komentarza, regenerowanie snapshota. Spisz zasadę (jedna linia w
CLAUDE.mdwystarczy): coś jak “pomiń plan tylko gdy: ≤1 plik, ≤5 linii, brak zmiany public API, brak migracji, brak auth, brak pieniędzy”. Cokolwiek poza tym envelope’em — planuj. Sensem zasady jest, żeby “pomiń” było świadomą decyzją, nie nawykiem. - Obsłuż Codex CLI jawnie, jeśli go używasz. Jeśli Codex CLI jest w Twoim toolbelcie, dodaj dwukrokowy prompt planu do swoich aliasów shell albo skryptu wrapping. Uruchamiaj Codex z
--ask-for-approval on-request(albo ostrzej), żeby edycje plików wymagały tapnięcia, i udokumentuj workaround wAGENTS.md, żeby sam agent wiedział o konwencji. Nie próbuj używać Plan mode w Codex CLI — nie istnieje — ale nie pozwól, żeby to było wymówką do pomijania planowania. - Sparuj Plan mode z Auto‑Accept na fazie execution. Plan mode i Auto‑Accept są zaprojektowane, żeby działać razem. Plan mode to bramka; Auto‑Accept to mnożnik throughputu po akceptacji planu. Workflow Cherny’ego: planuj w Plan mode, akceptuj, wpadaj w Auto‑Accept, odchodź. Jeśli ręcznie akceptujesz każdy diff po planie, płacisz koszt poznawczy planowania i koszt nadzoru — wybierz pas.
- Audytuj tygodniowo przez dwa tygodnie. Pod koniec każdego tygodnia spójrz wstecz na sesje i policz użycie Plan mode. Cel: >70% nietrywialnych sesji startujących w Plan, z iteracyjnym dopracowaniem przed akceptacją. Jeśli jesteś poniżej 70%, trigger z kroku 2 nie trzyma — uczyń go bardziej widocznym, slashcommandify mocniej, albo pair‑program z kimś, kto już ma nawyk. Po dwóch tygodniach >70% możesz porzucić audyt; nawyk będzie samonapędzający.
Częste pułapki
Dział zatytułowany „Częste pułapki”- Wychodzenie z Plan mode za wcześnie. Odruch “zaakceptuj i ruszaj” kopie zanim plan jest faktycznie dobry. Objaw: czytasz plan w 5 sekund, klikasz akceptuj, potem patrzysz jak agent commituje edycje, które chcesz od razu cofnąć. Fix: wymuś przynajmniej jeden cykl iteracji. Zmuś się do zadania jednego krytycznego pytania przed akceptacją — “jaki rollback?” albo “który test to łapie?”. Jeśli odpowiedź w planie jest słaba, iteruj. 20 sekund frustracji to cały sens.
- Akceptowanie złych planów, bo agent brzmi pewnie. Plan mode produkuje wiarygodnie wyglądające plany, nawet kiedy agent źle odczytał kod. Objaw: plan referencuje pliki albo funkcje, których nie ma, albo proponuje zmianę w systemie, który już został zrefaktorowany. Fix: skanuj plan pod kątem konkretnych referencji — file paths, function names, test names. Jeśli plan jest cały w abstraktach (“zaktualizuj auth flow”), żądaj konkretów przed akceptacją.
- Plan mode jako teatr. Niektóre zespoły robią z Plan mode rytuał, który produkuje dokument, którego nikt nie czyta, i wykonują niezależnie. Objaw: długie plany, szybkie akceptacje, ten sam rate reworku co wcześniej. Fix: plan istnieje, żeby być zakwestionowanym, nie żeby trafić do archiwum. Jeśli akceptujesz plany bez komentarzy ani zmian w >80% przypadków, naprawdę nie planujesz — pieczętujesz gumową pieczątką.
- Pomijanie Plan mode na “małych” taskach, które nie są małe. “Tylko szybki refactor” to najczęstsza przyczyna reworku w złą stronę. Objaw: trywialnie brzmiący ticket spirala w 90‑minutowy bałagan. Fix: przeczytaj ponownie swoją zasadę pomijania z kroku 5 powyżej. Jeśli nie mieścisz się w niej — to nie jest teren do pomijania — planuj.
- Plan mode bez Auto‑Accept na fazie execution. Planujesz pilnie, potem ręcznie akceptujesz każdy diff w execution. Objaw: czujesz się wyczerpany, throughput ledwo się poprawił. Fix: zaufaj zaakceptowanemu planowi. Cały sens płacenia kosztu planowania z góry jest taki, że execution staje się hands‑off. Jeśli nie ufasz planowi na tyle, żeby Auto‑Accept’ować, plan nie był wystarczająco dobry — iteruj więcej w Plan mode, nie mniej w execution.
- Zapomnienie, że Codex CLI nie ma natywnego Plan mode. Przynosisz nawyk z Claude Code do Codex CLI, naciskasz Shift+Tab oczekując przełączenia trybu, dostajesz nic użytecznego i po cichu zjeżdżasz do edit‑mode na całą sesję. Fix: użyj dwukrokowego workaroundu prompta z kroku 6 albo przekaż planowanie do Codex web (
/plan-mode), a execution do Codex CLI.
Jak sprawdzić, że jesteś na miejscu
Dział zatytułowany „Jak sprawdzić, że jesteś na miejscu”- W ciągu pełnego tygodnia sesji agentowych >70% nietrywialnych zadań startowało w Plan mode domyślnie — nie jako świadoma decyzja “to wygląda groźnie, planujmy”.
- Iterujesz w Plan mode 2–5 razy przed akceptacją na typowym zadaniu; akceptacja pierwszej wersji jest rzadka.
- Masz jawną zasadę pomijania (rozmiar, pliki, obszar) spisaną gdzieś, gdzie możesz pokazać — i jej przestrzegasz.
- Dla Claude Code:
/planalbo Shift+Tab dwa razy to pamięć mięśniowa; użyłeśCtrl+Gdo edycji pliku planu przynajmniej raz. - Dla Cursor Agents: Plan → Ask → Agent to Twój default flow dla złożonych ticketów w oknie Agents.
- Dla Codex CLI: masz udokumentowany dwukrokowy workaround planu i uruchamiasz z
--ask-for-approval on-request(albo ostrzej). - Po akceptacji wpadasz w Auto‑Accept (albo ekwiwalent) i pozwalasz, by execution szło głównie hands‑off — plan jest kontraktem.
- Rework w złą stronę — sesje, w których agent commituje istotną porcję edycji w kierunku, który od razu cofasz — jest mierzalnie rzadszy niż miesiąc temu.