Plan mode w Claude Code: kiedy wystarcza w zespole?

Plan mode w Claude Code sprawia, że Claude bada kod i proponuje plan, zanim cokolwiek zmieni. Zatwierdzają Państwo plan i dopiero wtedy zaczynają się zmiany. Dla jednego programisty w jednej sesji to często wystarcza. W zespole nie, bo plan żyje w jednej sesji na jednym laptopie i nikt inny nie może go przejrzeć ani później sprawdzić.

Dlatego plan mode służy nam do szkicu, a plan trzymamy tam, gdzie pracuje zespół: w issue na GitHubie, z kryteriami akceptacji, na które recenzent może odpowiedzieć tak lub nie. Zanim nasz agent cokolwiek zbuduje, sprawdzenie tylko do odczytu porównuje założenie issue z kodem.

Jak działa plan mode w Claude Code?

Plan mode to jeden z trybów uprawnień. Według dokumentacji trybów uprawnień Claude czyta pliki, uruchamia polecenia powłoki, żeby rozpoznać kod, i pisze plan, ale nie edytuje kodu źródłowego, dopóki go Państwo nie zatwierdzą. Przebieg:

Zatwierdzenie wyprowadza sesję z plan mode i Claude zaczyna edytować. Plik planu trafia do ~/.claude/plans/, chyba że ustawią Państwo plansDirectory.

Przewodnik po kosztach samego Anthropic zaleca plan mode przy złożonych zadaniach, bo zły kierunek wykryty przed zmianami jest tańszy niż wykryty po nich.

Gdzie plan mode nie wystarcza w zespole?

Plan mode odpowiada na pytanie „czy Claude rozumie, czego teraz chcę”. Zespół potrzebuje odpowiedzi na trzy kolejne:

• Kto jeszcze widział plan? Żyje w jednej sesji. Kolega, który jutro przejmie pracę, ani recenzent pull requesta nigdy nie zobaczy, co ustalono.
• Czy założenie było prawdziwe? Plan opiera się na tym, co wpisał programista. Jeśli issue mówi „eksport gubi puste wiersze”, a kod już je obsługuje, plan naprawia błąd, którego nie ma.
• Skąd będziemy wiedzieć, że gotowe? Plan wymienia kroki. Recenzent potrzebuje kryteriów, najlepiej każdego potwierdzonego testem.

To nie są rywale. Plan mode to dobry sposób na napisanie issue.

Jak planujemy zamiast tego?

Każde zadanie to issue na GitHubie z typem i wymaganym wynikiem:

Issue mówi, co dostarczyć. Kto je podejmuje, człowiek czy nasz agent AI, uzupełnia brakujący wynik lub kryterium jako jawne założenie, zamiast po cichu zgadywać.

Jak wygląda sprawdzenie READY?

Zanim nasza pętla agenta cokolwiek zbuduje, uruchamia krok READY. To nie jest plan mode. To osobne wywołanie tylko do odczytu z typowaną odpowiedzią:

claude -p "$(cat ready.md; cat issue.md)" \
  --permission-mode default --permission-prompts none \
  --tools "Read,Grep,Glob,WebFetch" \
  --json-schema "$(cat ready.schema.json)" --output-format json --max-turns 40

Schemat wymusza odpowiedź w polach: ready, done_when (kryteria, na które recenzent odpowie tak lub nie), verify (jak każde z nich się udowadnia), understood, premise i verifiable, które ma wartość test albo human. Brak poprawnego obiektu liczy się jako porażka, nigdy jako wartość domyślna.

Sesja budowania dostaje potem te kryteria jako zlecenie. Działa z --disallowedTools AskUserQuestion ExitPlanMode: na tym etapie plan jest ustalony, więc agent nie może się zatrzymać, żeby zapytać, ani wrócić do planowania. Całą pętlę, od READY do pull requesta, opisujemy w Harness engineering w praktyce.

Co wyłapie sprawdzenie założenia, czego nie wyłapie plan mode?

Plan zrobiony w dobrej wierze na fałszywym założeniu. Prompt READY każe modelowi sprawdzić w repozytorium każde twierdzenie issue o obecnym zachowaniu i podać file:line. Jeśli twierdzenie się nie potwierdza, odpowiedź zaczyna się od REFUTED: i wymienia, co już nie jest prawdą, a co nadal jest.

Co dalej, zależy od tego, ile zostało:

• Nie zostało nic do zrobienia. Issue wraca do człowieka z dowodami i propozycją zamknięcia.
• Część jest obalona. Pętla proponuje w issue poprawiony zakres i czeka, aż człowiek odpowie OK, zanim cokolwiek zbuduje.
• Zweryfikować może tylko człowiek. Gdy verifiable ma wartość human, agent mówi, na co ktoś musi spojrzeć, zanim zacznie.

Tę lukę zamyka sprawdzenie założenia. Planowanie jest tanie. Drogie jest planowanie nie tego, co trzeba, a do code review wygląda to dokładnie jak postęp.

Kiedy plan mode wystarcza?

Bardzo często. Ta lista pomoże zdecydować, czy plan musi wyjść poza sesję:

Plan mode pasuje do krótkich, lokalnych zmian, w których są Państwo jedynym czytelnikiem. Wszystko inne zasługuje na plan, który zespół może przeczytać. Jak spisana specyfikacja staje się umową między ludźmi a agentami, opisujemy w Spec-driven development z agentami AI.

Chcą Państwo planów, które przetrwają sesję?

Kontrakty issue, sprawdzenia READY i pętlę agenta wdrażamy bezpośrednio w repozytoriach zespołu w ramach AI-native SDLC dla zespołów deweloperskich. Większość naszego kodu pisze AI. Każdą zmianę przegląda senior i odpowiada za produkcję. Od 2023 roku dostarczyliśmy ponad 15 projektów produkcyjnych.

Odezwiemy się w ciągu dwóch dni roboczych z kilkoma pytaniami o Państwa pracę. Potem ustalimy, co zrobimy najpierw.

Jeśli wolą Państwo najpierw porozmawiać, proszę zarezerwować 15-minutową rozmowę wstępną.

Kto w Państwa zespole znalazłby dziś wczorajszy plan?

Najczęstsze pytania

Czym jest plan mode w Claude Code?

To tryb uprawnień, w którym Claude czyta pliki i uruchamia polecenia rozpoznawcze, a potem proponuje plan bez edytowania kodu źródłowego. Zmiany pozostają zablokowane, dopóki nie zatwierdzą Państwo planu.

Jak włączyć plan mode w Claude Code?

Nacisnąć Shift+Tab, aby się do niego przełączyć, zacząć pojedynczy prompt od /plan albo uruchomić sesję poleceniem claude --permission-mode plan.

Czy mogę edytować plan, zanim Claude zacznie?

Tak. Ctrl+G otwiera proponowany plan w edytorze. Można też wybrać dalsze planowanie i powiedzieć Claude, co zmienić.

Gdzie Claude Code zapisuje plany?

Domyślnie w ~/.claude/plans/ albo w katalogu ustawionym w opcji plansDirectory. W obu przypadkach na jednej maszynie, dlatego plan zespołu powinien trafić także do issue.

Czy plan mode to to samo co spec-driven development?

Nie. Plan mode to funkcja jednej sesji. Spec-driven development utrzymuje plan jako spisany artefakt, który przegląda cały zespół i który mogą zweryfikować testy. Plan mode może przygotować jego szkic.