Plan Mode: pokaż co zrobisz, zanim to zrobisz

Czego się nauczysz

• Kiedy Plan Mode obniża ryzyko błędnej implementacji
• Jak używać Plan agenta i /plan do rozpisania kroków, weryfikacji i pytań doprecyzowujących
• Jak przejść z planu do wykonania bez utraty kontekstu

Najdroższy błąd to zacząć implementację zbyt wcześnie

Im większa zmiana, tym bardziej opłaca się zatrzymać na moment przed kodowaniem.

To właśnie rozwiązuje Plan Mode. Nie służy do generowania kodu. Służy do tego, żeby agent najpierw zrozumiał zadanie, zadał pytania i rozpisał sensowną ścieżkę implementacji wraz z weryfikacją.

Jeśli Agent jest trybem “zrób to”, to Plan jest trybem “najpierw pokaż, jak chcesz to zrobić”.

Jak uruchomić Plan Mode

Dokumentacja podaje dwie główne ścieżki:

• wybierasz Plan z listy agentów w Chat View
• albo wpisujesz /plan i od razu opisujesz zadanie

To drugie jest szczególnie wygodne, bo pozwala szybko przełączyć intencję rozmowy bez klikania po UI.

Przykład dobrego użycia:

• /plan dodaj autoryzację dla endpointów API i rozpisz kroki wdrożenia oraz testy regresyjne

Tu widać ważną rzecz: plan powinien obejmować nie tylko implementację, ale też sposób sprawdzenia, czy zmiana naprawdę działa.

Dobry plan to nie lista ogólników

Plan agent, zgodnie z dokumentacją, robi trzy rzeczy:

• bada temat
• zadaje pytania doprecyzowujące
• generuje plan z częścią implementacyjną i weryfikacyjną

To znaczy, że dobry plan nie powinien kończyć się na punktach w stylu:

• zmień backend
• zmień frontend
• przetestuj

To jest zbyt ogólne, żeby miało wartość.

Dobry plan pokazuje:

• które obszary kodu są dotknięte
• w jakiej kolejności ruszać zmiany
• jakie są ryzyka albo decyzje do podjęcia
• jak zweryfikować wynik

Plan nie musi być przesadnie szczegółowy, ale musi być operacyjny.

Clarifying questions są funkcją, nie przeszkodą

W praktyce wiele osób irytuje się, gdy agent zaczyna dopytywać. To błąd myślenia.

Pytania doprecyzowujące to sygnał, że system próbuje zawęzić problem przed wejściem w kosztowną implementację.

To szczególnie ważne w zadaniach typu:

• refaktor bez zmiany API
• migracja biblioteki
• feature obejmujący backend, frontend i testy

Jeżeli odpowiesz na pytania precyzyjnie, plan zwykle staje się wyraźnie lepszy. Jeśli je zignorujesz, zwiększasz szansę, że agent ruszy w złą stronę, tylko szybciej.

Plan zapisuje się do plan.md w session memory

To bardzo praktyczny detal z dokumentacji. Plan agent automatycznie zapisuje plan do pliku /memories/session/plan.md.

Po co to ważne?

Bo plan przestaje być chwilową odpowiedzią na czacie, a staje się artefaktem sesji. Możesz go otworzyć, przeczytać na spokojnie i użyć jako punktu odniesienia podczas implementacji.

Trzeba tylko pamiętać o jednym ograniczeniu: session memory znika po zakończeniu rozmowy. To nie jest trwała dokumentacja projektu, tylko pamięć robocza aktualnej sesji.

Kiedy Plan Mode ma największy sens

Nie do wszystkiego.

Plan Mode warto odpalać wtedy, gdy:

• zmiana obejmuje kilka plików albo warstw systemu
• są możliwe różne ścieżki implementacji
• trzeba ustalić kryteria weryfikacji przed kodowaniem
• koszt błędnego startu jest wyraźnie większy niż koszt krótkiego planowania

Dla małej lokalnej poprawki Plan Mode bywa zbędny. Wtedy to tylko dodatkowy krok bez realnego zwrotu.

Handoff z planu do implementacji

Po dopracowaniu planu możesz przejść do implementacji. Dokumentacja dopuszcza kilka wariantów:

• kontynuujesz w tej samej sesji
• przekazujesz plan do implementującego agenta
• uruchamiasz implementację w tle, na przykład przez Copilot CLI

Najważniejsze jest to, że plan nie jest tylko raportem do przeczytania. Jego wartość rośnie dopiero wtedy, gdy staje się briefingiem dla wykonania.

Customize planning ma sens, ale dopiero gdy masz proces

VS Code pozwala ustawić:

• domyślny model dla planowania
• osobny model dla implementacji
• dodatkowe narzędzia dla plan agent
• custom planning agent z własnymi regułami

To potężne możliwości, ale warto je ruszać dopiero wtedy, gdy masz już własny, powtarzalny workflow. Inaczej zbyt wcześnie optymalizujesz narzędzie, zamiast najpierw uporządkować sposób pracy.

Ćwiczenie praktyczne

Weź zmianę, która obejmuje kilka plików, i uruchom /plan.

Następnie zrób trzy rzeczy:

1. Odpowiedz na pytania doprecyzowujące.
2. Poproś o dopisanie kroków weryfikacji, jeśli plan ich nie zawiera.
3. Oceń, czy plan jest na tyle konkretny, żeby dać go do wykonania bez dodatkowych wyjaśnień.

Na końcu porównaj dwa warianty:

• plan po pierwszej odpowiedzi agenta
• plan po doprecyzowaniu ograniczeń i kryteriów jakości

To zwykle bardzo dobrze pokazuje, że wartość Plan Mode rośnie wraz z jakością dopowiedzianych wymagań.

Kluczowe wnioski

• Plan Mode służy do rozpisania implementacji i weryfikacji przed wejściem w zmiany w kodzie.
• Największy zysk pojawia się przy zadaniach wieloplikowych, niejednoznacznych albo kosztownych w cofnięciu.
• Clarifying questions nie są przeszkodą, tylko mechanizmem redukcji ryzyka.
• Plan zapisuje się do plan.md w session memory, więc może działać jako roboczy briefing sesji.
• Dobrze użyty Plan Mode skraca nie tyle sam czas pisania kodu, ile liczbę nietrafionych iteracji.

Co dalej

Masz już plan i wykonanie. Teraz trzeba opanować trzeci element bezpiecznego workflow: reviewowanie AI-generated edits plik po pliku i zmiana po zmianie.