Wcześniejsze lekcje kończyły się zwykle na jednym poleceniu: napisz plik, sprawdź coś, popraw fragment. Ta idzie o krok dalej – zamiast pojedynczego zadania, przechodzisz przez cały cykl, który potem wraca przy każdej kolejnej pracy z Claude Code: najpierw plan, potem wykonanie, na końcu sprawdzenie wyniku.

Brzmi to jak dodatkowa praca w porównaniu z samym napisaniem „zrób X” i czekaniem na wynik. W praktyce jest odwrotnie – plan pokazuje, co Claude Code zamierza zrobić, zanim cokolwiek ruszy w twoich plikach, a to jest dokładnie ten moment, w którym najłatwiej sprawdzić, czy Claude Code zrozumiał, o co ci chodzi.

Do ćwiczenia wystarczy folder, w którym masz już zainstalowany Claude Code i podstawowy CLAUDE.md.

Wybierz zadanie, które da się ocenić

Cykl ma sens tylko na zadaniu, o którym umiesz powiedzieć, czy zostało zrobione dobrze. Nie musi być duże – wręcz przeciwnie, na pierwszy raz lepiej sprawdza się coś małego, co mieści się w jednym posiedzeniu.

Kilka przykładów, które pasują do tego ćwiczenia: dopisanie sekcji do dokumentu, który już istnieje, uporządkowanie listy zadań rozrzuconej po kilku plikach, dodanie jednej funkcji w skrypcie, który znasz na pamięć.

Test jest prosty: jeśli po zobaczeniu wyniku umiesz od razu powiedzieć „o to mi chodziło” albo „nie, to nie to” – zadanie się nadaje. Jeśli trzeba się nad tym długo zastanawiać, wybierz coś mniejszego.

Poproś o plan, zanim cokolwiek się zmieni

Domyślnie Claude Code czyta pliki i pyta o zgodę przed każdą zmianą – to tryb Manual, w którym pracujesz do tej pory. Do tego ćwiczenia potrzebny jest inny tryb: plan, w którym Claude Code może czytać projekt i sprawdzać go poleceniami, ale nie rusza żadnego pliku, dopóki nie zatwierdzisz tego, co zaplanował.

Najprościej wejść w niego przy jednym poleceniu – dopisz /plan przed treścią zadania, na przykład:

/plan Dodaj sekcję FAQ na końcu README, z trzema pytaniami, które najczęściej pojawiają się w rozmowach o tym projekcie.

Możesz też przełączyć się na stałe skrótem Shift+Tab – ten sam skrót przyda ci się później, bo tak samo przełączasz się między pozostałymi trybami pracy Claude Code.

Dokumentacja trybów uprawnień

Pasek stanu na dole terminala potwierdza wejście w tryb planowania – zobaczysz tam napis ⏸ plan mode on. Claude Code czyta pliki, może uruchamiać polecenia sprawdzające projekt, i po chwili przedstawia plan zamiast od razu zabierać się do pracy.

Popraw plan, zanim go zatwierdzisz

Plan to zwykły tekst – kroki, które Claude Code zamierza wykonać, czasem z krótkim uzasadnieniem każdego z nich. Czytaj go tak, jakbyś czytał czyjś pomysł na rozwiązanie twojego problemu, nie gotowe rozwiązanie: to wciąż jest propozycja.

Jeśli czegoś brakuje albo któryś krok idzie w złą stronę, nie musisz akceptować planu, żeby to poprawić. Wybierz opcję „No, keep planning” i napisz zwykłym zdaniem, co ma się zmienić – Claude Code przerobi plan i pokaże go jeszcze raz.

Jest też skrót dla bardziej szczegółowych poprawek: Ctrl+G otwiera plan w twoim edytorze tekstu i pozwala zmienić go bezpośrednio, zamiast opisywać poprawki słowami.

Zatwierdź plan i pozwól działać

Gdy plan wygląda dobrze, wybierz „Yes, manually approve edits”. Ta opcja przełącza sesję z powrotem w tryb, w którym każda zmiana pliku czeka na twoją zgodę – więc mimo zatwierdzenia całego planu, wciąż widzisz i akceptujesz poszczególne kroki, zamiast puszczać wszystko naraz.

Jest też opcja „Yes, and use auto mode”, która ogranicza pytania o zgodę do minimum. Na pierwszą pełną sesję zostań przy ręcznym zatwierdzaniu – masz wtedy więcej okazji zobaczyć, co dokładnie się dzieje, zanim zaufasz temu cyklowi na dłuższych zadaniach.

Claude Code zaczyna wykonywać kroki z planu, jeden po drugim, pytając o zgodę przy każdej zmianie pliku – dokładnie tak, jak w trybie Manual, tyle że teraz każdy krok ma już swoje uzasadnienie z planu.

Sprawdź wynik sam, nie z podsumowania

Po skończonym zadaniu Claude Code napisze podsumowanie tego, co zrobił. Przeczytaj je – ale nie kończ na nim ćwiczenia. Podsumowanie mówi, co Claude Code sądzi, że zrobił, nie co faktycznie się zmieniło w plikach.

Otwórz zmieniony plik i przeczytaj fragment, którego dotyczyło zadanie. Jeśli pracujesz z gitem, git diff pokaże ci same zmienione linijki, bez czytania pliku od nowa.

Sprawdzaj konkretnie to, o co prosisz, nie ogólne „czy wygląda dobrze”. Jeśli zadaniem było dopisanie trzech pytań do sekcji FAQ, policz je – dosłownie policz, czy jest ich trzy.

Ten sam nawyk przyda się później do dłuższych zadań, gdzie sprawdzenie „na oko” jest jeszcze łatwiej pominąć. Im wcześniej stanie się odruchem, tym mniej razy skończysz z podsumowaniem, które nie pasuje do rzeczywistości w plikach.

Zapisz, co zadziałało, na przyszłość

Ostatni krok łatwo pominąć, bo nic już nie przypomina o jego zrobieniu: zapisanie, co z tej sesji warto przenieść na następną. Nie chodzi o dziennik z każdego zadania – tylko o rzeczy, które faktycznie ułatwią kolejną sesję.

Jeśli podczas planowania Claude Code czegoś nie wiedział i trzeba było mu to podpowiedzieć – na przykład że pewnego folderu nie wolno ruszać bez pytania, albo jak nazywacie coś w projekcie – to jest dokładnie ten typ informacji, który warto dopisać do CLAUDE.md. Powiedz to Claude Code wprost, tak samo jak dyktujesz mu inne poprawki:

Do CLAUDE.md dopisz notatkę: plików w folderze dane/ nie zmieniamy bez pytania.

Na koniec sesji zapytaj, czego Claude Code się właśnie nauczył i czy warto to zapisać. Kolejna zaczyna się wtedy nie od zera, tylko tam, gdzie skończyła się ta.

Zadania

Odhacz, gdy zrobisz. Stan zapamięta się w przeglądarce, więc możesz wrócić do tej listy jutro.

  • Małe, konkretne zadanie wybrane – takie, które umiesz ocenić na oko
  • Zadanie zaczęte w trybie planowania
  • Plan przeczytany do końca, zanim padła decyzja
  • Poprawki do planu wprowadzone, jeśli czegoś brakowało
  • Plan zatwierdzony opcją „Yes, manually approve edits”
  • Wynik sprawdzony w samym pliku, nie tylko w podsumowaniu
  • Notatka na przyszłość dopisana do CLAUDE.md, jeśli było co zapisać