Claude Code Plan Mode po polsku, TDD i wieloetapowe taski 2026

Spis treści

• Czym jest Plan Mode
• Kiedy włączać Plan Mode
• Jak aktywować Plan Mode
• Anatomia planu Claude
• Weryfikacja i poprawa planu
• TDD z Plan Mode
• Plan Mode dla złożonych refactorów
• 5 praktycznych use case
• Anti-spaghetti workflow
• Koszty Plan Mode
• Antywzorce
• FAQ

Aktualizacja: maj 2026. Plan Mode to mechanizm w Claude Code, który zamienia agenta z reaktywnego edytora w architekta. Zamiast od razu pisać kod, Claude najpierw bada repo, układa krok po kroku plan działania i czeka na Twoją akceptację. To ratunek dla wieloetapowych refactorów, migracji i każdego zadania, w którym chaotic edits oznaczają bugi i rollbacki. W tym tutorialu pokazuję jak Plan Mode działa, kiedy go wymuszać, jak czytać i poprawiać plan oraz 5 use case z prawdziwego workflowu.

Czym jest Plan Mode w Claude Code

Plan Mode to specjalny tryb sesji Claude Code, w którym agent nie wykonuje żadnych destrukcyjnych operacji. Nie edytuje plików, nie pisze nowych, nie uruchamia Bash. Może tylko czytać: Read, Glob, Grep, ewentualnie WebFetch. Wszystko, co normalnie robi w trakcie sesji (Edit, Write, Bash), zostaje wstrzymane.

Zamiast tego Claude wykonuje trzy rzeczy. Po pierwsze, eksploruje repo, by zrozumieć kontekst. Po drugie, generuje plan, czyli numerowaną listę kroków z opisem czego dotyczą, jakie pliki ruszą i jaki będzie expected outcome. Po trzecie, przekazuje plan Tobie i czeka. Dopiero gdy odpowiesz "akceptuję" lub poprosisz o execution, Claude wychodzi z Plan Mode i wykonuje plan krok po kroku.

Analogicznie do terraform plan w infrastrukturze, najpierw widzisz, co się stanie, dopiero potem terraform apply. Albo do code review przed merge: ktoś przegląda diff, zanim wpłynie do main. Plan Mode wnosi taką samą dyscyplinę do interakcji z agentem.

Kiedy włączać Plan Mode, 5 typowych sytuacji

Plan Mode nie jest dla każdego zadania, ma realny overhead (więcej tokenów, więcej czasu). Włączaj go w 5 sytuacjach, w których chaos kosztuje:

1. Refactor obejmujący 5+ plików. Bez planu Claude często zaczyna od jednego pliku, edytuje, potem orientuje się że trzeba zmienić import w 10 innych miejscach. Z planem widzisz całą mapę zmian zanim pierwsza linia padnie.
2. Migracja, np. JavaScript do TypeScript, REST do GraphQL, biblioteki X do Y. Migracja ma kolejność (najpierw types, potem implementacje, potem testy, potem doc), którą Plan Mode wymusza.
3. Debug investigation w nieznanym kodzie. Zamiast od razu próbować fixów, Plan Mode zmusza Claude do hipotezy ("podejrzewam, że problem jest w X bo Y, najpierw sprawdzę Z").
4. Generation kilku powiązanych plików (np. nowy endpoint = route + handler + types + test + doc). Plan Mode gwarantuje że żaden plik nie zostanie pominięty.
5. Code review zmian, które ktoś inny zrobił. Plan Mode = Claude czyta diff, mówi co znalazł, dopiero potem proponuje fixy.

Wspólny mianownik: zadanie z więcej niż jedną decyzją projektową. Każde takie zadanie zyskuje na Plan Mode. Trywialne zadania (zmień string, dodaj jedno pole) tracą.

Jak aktywować Plan Mode

Trzy sposoby, od najprostszego do najbardziej zaawansowanego.

Sposób 1: Shift+Tab w trakcie sesji

Najszybszy sposób. W aktywnej sesji Claude Code naciśnij Shift+Tab, by przełączyć permission mode. Claude pokaże komunikat "Plan Mode active" i od tego momentu nie wykonuje destruktywnych narzędzi. Ponowne Shift+Tab wraca do normalnego trybu (lub Auto Mode, zależnie od rotacji).

Sposób 2: Flaga CLI przy starcie

claude --permission-mode plan

Uruchamia całą sesję od razu w Plan Mode. Przydatne, gdy wiesz, że to będzie sesja eksploracyjna (np. onboardujesz się do nowego repo i nie chcesz żeby Claude przypadkiem coś zedytował).

Sposób 3: Prompt-driven, "zaplanuj najpierw"

Najbardziej naturalny pattern. W normalnej sesji wpisujesz prompt, który jasno sygnalizuje plan-first:

Zaplanuj refactor modułu auth z JWT na session cookies.
Zanim cokolwiek zmienisz, wypisz wszystkie pliki które
zostaną dotknięte, kolejność zmian i zależności między
krokami. Czekaj na moją akceptację przed pierwszą edycją.

Claude rozumie ten pattern i przechodzi w Plan Mode-style behavior nawet bez formalnego trybu. Różnica od formalnego Plan Mode: tu Claude technicznie może edytować, więc trzeba mu jasno powiedzieć "nie edytuj". Dla 100% gwarancji read-only używaj flagi.

Sposób 4: Custom slash command /plan

Możesz zdefiniować własny slash command w .claude/commands/plan.md:

---
description: Wymuś Plan Mode + standardowe instrukcje
---

Wejdź w Plan Mode. Dla zadania poniżej:

1. Przeczytaj relevant pliki (Read, Glob, Grep)
2. Wypisz plan jako numerowaną listę z polami:
   - Plik
   - Akcja (Read, Edit, Write, Bash)
   - Expected outcome
   - Dependencies (które kroki muszą być wcześniej)
3. Czekaj na akceptację przed execution

Zadanie: $ARGUMENTS

Od teraz /plan zrefactoruj auth na sessions uruchamia spójny workflow planowania.

Anatomia planu Claude

Dobrze wygenerowany plan ma 4 elementy w każdym kroku:

1. Numer i tytuł kroku, np. "Krok 3: Usuń JWT middleware".
2. Lista plików, które krok ruszy. Bez konkretnych ścieżek plan jest bezużyteczny.
3. Akcja (Read, Edit, Write, Bash, Delete). Mówi Tobie, co się stanie.
4. Expected outcome, jeden ze trzech zdań co po tym kroku ma być prawdziwe (np. "Po kroku 3 build kompiluje się bez JWT importów").

Przykład realnego planu wygenerowanego przez Claude (skrót):

Plan refactoru: JWT → session cookies

Krok 1: Audit bieżącego użycia JWT
- Pliki: src/auth/*, src/middleware/auth.ts
- Akcja: Read, Grep
- Outcome: Lista 12 miejsc używających jsonwebtoken

Krok 2: Dodaj express-session i konfigurację
- Pliki: package.json, src/app.ts
- Akcja: Edit
- Dependencies: brak
- Outcome: Session store skonfigurowany, brak konfliktu z JWT

Krok 3: Nowy middleware sessionAuth
- Pliki: src/middleware/session-auth.ts (nowy)
- Akcja: Write
- Dependencies: Krok 2
- Outcome: sessionAuth zastępuje jwtAuth na poziomie API

Krok 4: Migracja endpointów (12 plików)
- Pliki: src/routes/users.ts, src/routes/api.ts, ... (12)
- Akcja: Edit
- Dependencies: Krok 3
- Outcome: Wszystkie endpointy używają sessionAuth

Krok 5: Usuń JWT middleware i dependencies
- Pliki: src/middleware/auth.ts (delete), package.json
- Akcja: Delete, Edit
- Dependencies: Krok 4
- Outcome: jsonwebtoken usunięty z node_modules

Krok 6: Update testów (8 plików)
- Pliki: tests/auth.spec.ts, tests/routes/*.spec.ts
- Akcja: Edit
- Dependencies: Krok 4
- Outcome: 47 testów PASSED

Krok 7: Dokumentacja
- Pliki: docs/auth.md, README.md
- Akcja: Edit
- Dependencies: Krok 6
- Outcome: Doc reflektuje session-based auth

Zauważ: każdy krok można zweryfikować ("expected outcome") i każdy ma jasne dependencies. To znacznie więcej niż zwykła lista TODO.

Jak czytać i poprawiać plan przed execution

Czytaj plan jak code review. Trzy pytania na każdym kroku:

1. Czy lista plików jest kompletna? Najczęstszy błąd, brakuje pliku z testami albo dokumentacją. Powiedz wprost: "Dodaj do kroku 4 też plik src/types/auth.ts".
2. Czy kolejność dependencies jest poprawna? Czasem Claude zaczyna od refactoru bez prereq. Powiedz: "Krok 3 zależy też od kroku 1, nie tylko 2".
3. Czy expected outcome jest mierzalne? "Wszystko działa" nie wystarcza. Wymagaj konkretu: "Po kroku 4 npm test daje 47 PASSED".

Akceptacja planu to nie "ok robimy". To "tak, ten plan jest poprawny, dependencies się zgadzają, expected outcomes są mierzalne". Jeśli choć jeden punkt budzi wątpliwości, NIE akceptujesz, prosisz o korektę.

TDD z Plan Mode, red, green, refactor jako 3 kroki

Test-Driven Development naturalnie mapuje się na Plan Mode bo cykl red, green, refactor to trzy fazy z jasnymi expected outcomes. Pattern wygląda tak:

Wejdź w Plan Mode. Implementuj nową funkcję
calculateDiscount(order, user) w TDD style.

Wygeneruj 3-krokowy plan:

Krok 1 (RED): Napisz failing test
- Plik: src/__tests__/discount.spec.ts
- Test pokrywa 3 cases: VIP user 20%, regular 0%,
  order > 500 zł dodatkowe 5%
- Expected outcome: npm test fails on calculateDiscount

Krok 2 (GREEN): Minimalna implementacja
- Plik: src/discount.ts (nowy)
- Tylko tyle kodu żeby testy z kroku 1 PASSED
- Expected outcome: 3/3 tests PASSED

Krok 3 (REFACTOR): Wydziel reguły do data structure
- Plik: src/discount.ts, src/discount-rules.ts (nowy)
- Refactor bez zmiany behavior
- Expected outcome: 3/3 tests nadal PASSED, no duplikacji

Czekaj na akceptację przed Krokiem 1.

Po akceptacji Claude wykonuje krok 1, uruchamia testy (powinny fail, to red), potem krok 2, uruchamia testy (powinny pass, to green), potem krok 3 (testy nadal pass). Każdy krok ma weryfikowalny expected outcome, dlatego TDD i Plan Mode są jak małżeństwo.

Plan Mode dla złożonych refactorów (10+ plików)

Im więcej plików, tym bardziej Plan Mode ratuje. W refactorze 20+ plików bez planu Claude często:

• Edytuje 5 plików, potem orientuje się, że trzeba też w 6, ale już zapomina o 3 wcześniejszych dependencies.
• Zaczyna od najłatwiejszych plików (low-hanging fruit), zostawia hardcore na koniec, gdy kontekst już się rozjechał.
• Robi inconsistent changes, jeden plik używa nowego API, drugi starego, łapiesz to dopiero na code review.

Plan Mode wymusza top-down: najpierw mapa wszystkich zmian, potem dependencies, potem execution w poprawnej kolejności. Dla 20-file refactor plan zajmuje 200-400 linii (norma, nie problem), execution zajmuje 30-60 minut, ale rollback nie potrzeba.

5 praktycznych use case Plan Mode

1. Migracja JavaScript do TypeScript

Prompt: "Wejdź w Plan Mode. Zmigruj src/utils/*.js do TypeScript. Zaplanuj kolejność (file by file lub batch?), strategie dla loose typing (any vs unknown), update tsconfig, update imports w plikach które referują utils."

Plan Claude zwykle: 1) Add tsconfig dla utils, 2) Convert utils/helpers.js (least dependencies first), 3) Convert utils/formatters.js, ... 8) Update wszystkie importy w innych plikach, 9) Run tsc, fix type errors, 10) Update tests.

2. Multi-file refactor (np. extract shared component)

Prompt: "Zaplanuj wyciągnięcie UserCard komponentu z trzech miejsc (UserList, Dashboard, AdminPanel) do src/components/UserCard.tsx jako shared. Zachowaj backward compatibility przez prop interfejs."

Plan: audit wszystkich 3 wariantów, identyfikacja wspólnych props, stworzenie shared component z prop union, podmiana w 3 miejscach, weryfikacja że UI nie zmienił się.

3. Debug investigation (intermittent test failure)

Prompt: "Test tests/api/payment.spec.ts czasem pada, czasem zalicza. Zaplanuj investigation. NIE zmieniaj kodu yet, tylko zbierz dane."

Plan: 1) Read testu i implementacji payment, 2) Grep dla shared state, 3) Sprawdź czy nie ma race condition w setup, 4) Uruchom test 20x w pętli i zbierz logi, 5) Hipoteza + propozycja fixu (read-only proposal).

4. Generation powiązanych plików (nowy CRUD endpoint)

Prompt: "Zaplanuj dodanie endpointu POST /api/teams z pełnym stackiem: route, validation schema, controller, service, repository, types, OpenAPI doc, test."

Plan: 8 plików do utworzenia + 2 do edycji (router index, OpenAPI registry), z jasnymi dependencies (types przed implementacjami, doc po implementacji, test na końcu).

5. Code review zmian (PR review)

Prompt: "Wejdź w Plan Mode. Zrób review PR git diff main..feature/new-payment. Wskaż 3 największe ryzyka, propozycje fixów (jako plan, nie execution)."

Plan: Read diff, Grep dla error handling, sprawdzenie test coverage delta, security review (input validation, sql injection risk), lista 3 ryzyk z propozycjami fixów do akceptacji.

Anti-spaghetti workflow, jak Plan Mode chroni przed chaotic edits

Spaghetti workflow to typowy anti-pattern bez Plan Mode: prompt → Claude edytuje plik A → orientujesz się, że plik B też trzeba ruszyć → kolejny prompt → Claude rusza B, ale teraz A ma stale references → kolejny prompt fix references → ... 8 promptów później kontekst jest rozjechany, kod w pół-stanie, trudno cofnąć.

Plan Mode chroni przed tym przez wymóg frontloadingu decyzji. Wszystkie zmiany są zaplanowane w jednym dokumencie zanim padnie pierwsza linia kodu. Skutki:

• Atomic execution, plan akceptowany jako całość, więc rollback (jeśli potrzebny) jest też atomic (git reset jednego commita zamiast 8).
• Code review przed execution, Ty (a nie reviewer 3 dni później) widzisz mapę zmian.
• Dependencies explicit, jeśli krok 4 zależy od kroku 2, plan to mówi, nie zorientujesz się dopiero na kroku 5 że coś brakuje.
• Zero "scope creep", plan definiuje granice. Claude nie dorzuca losowo "a przy okazji zrefactorowałem też utils".

Koszty Plan Mode, czy planning to dodatkowy token cost

Tak, Plan Mode kosztuje więcej tokenów na input. Konkretnie:

• Eksploracja: Claude w Plan Mode robi więcej Read i Grep, by zrozumieć kontekst (typowo 8-15 narzędzi zamiast 3-5 w normalnym trybie). Każdy Read = tokeny inputu.
• Generacja planu: sam plan to 300-800 tokenów outputu (numerowana lista, opisy, expected outcomes).
• Iteracja na planie: jeśli prosisz o poprawki, każda iteracja = kolejny exchange.

W praktyce, dla zadania typu 5-file refactor, Plan Mode dodaje 15-30% do całkowitego token cost. Brzmi dużo, ale alternatywa to:

• Chaotic edits z bugami = 2-3 dodatkowe iteracje promptów dla fixów = 50-100% więcej tokenów + Twój czas debugowania.
• Rollback (git reset, restart) = stracony czas i tokeny zainwestowane w pierwszym podejściu = 200% wasted.

TCO (total cost of ownership) Plan Mode jest niższe dla zadań nietrywialnych. Dla trywialnych Plan Mode rzeczywiście jest droższy bez korzyści, dlatego nie używaj go do "zmień nazwę zmiennej".

Antywzorce, kiedy Plan Mode szkodzi

1. Plan Mode dla trywialnych zadań. "Zmień string X na Y" nie potrzebuje planu. Overhead tokenów + czasu Twoich oczu czytających "Krok 1: Edit file.ts, change X to Y". Plan to ceremonia, ceremonia ma sens tylko gdy zadanie jest tego warte.
2. Akceptacja planu bez czytania. Plan Mode bez review = false sense of security. Claude wygenerował coś, co wygląda mądrze, ale ma błąd w deps między krokiem 3 a 5. Nie złapiesz tego bez czytania.
3. Eksploracja w Plan Mode. Plan Mode wymaga jasnego celu. Jeśli sam nie wiesz, czego chcesz ("pokaż mi co jest w tym repo"), Plan Mode jest niewłaściwy, użyj zwykłego trybu lub --permission-mode acceptEdits.
4. Hardcore planowanie bez fallbacku. Nawet najlepszy plan może spotkać surprise w execution (np. test, którego nie było w mapie). Pozwól Claude w trakcie execution wyjść z planu i zaadresować surprise (ale niech zatrzyma się i powie Tobie).
5. Plan Mode w pętli (planuj plan planu). Czasem Claude prosi o "plan dla planowania". To znak, że zadanie jest niejasno zdefiniowane. Zatrzymaj się, doprecyzuj zadanie, zacznij od nowa.

Co dalej, łączenie Plan Mode z resztą stosu

Plan Mode to jeden filar agentic workflow w Claude Code. Pełen stos to plan + subagents + hooks + Agent SDK. Każdy filar zamyka inną klasę problemów:

• Claude Code tutorial po polsku, kompletny przewodnik, fundament
• Claude Code subagents po polsku, paralelne execution kroków planu
• Claude Code hooks po polsku, gwarancje na każdym kroku
• Claude Agent SDK po polsku, headless workflow w CI

Najczęściej zadawane pytania

Powiązane artykuły

Claude Code•9 min

Claude Code cena 2026, ile kosztuje i czy jest darmowy

Claude Code cena w PLN i USD, plany Pro i Max, API pay-as-you-go, darmowe kredyty i alternatywy. Najtańsza legalna ścieżka. Stan maj 2026.

Czytaj

Claude Code•9 min

Claude Max plan po polsku, ceny i limity 2026

Plan Claude Max po polsku: ceny Max 5x i 20x, ile zapytań daje, Claude Pro vs Max, Max vs API. Limity sesji i tygodniowe. Stan maj 2026, dla kogo warto.

Czytaj

Claude Code•15 min

Claude Code Skills po polsku, tutorial Agent Skills 2026

Pierwszy polski tutorial Agent Skills w Claude Code. SKILL.md, frontmatter, progressive disclosure, jak tworzyć skille krok po kroku, vs subagents i MCP.

Czytaj