---
title: "Plan Mode umarł, planowanie nie"
description: "W naszym workflow Plan Mode ustąpił miejsca własnym skillom. Planowanie zostało: intencja, kontrakty, świadome decyzje i kryterium stopu nadal mają znaczenie."
publishDate: "2026-10-15T10:00:00.000Z"
image: "~/assets/images/blog/thumbnails/plan-mode.webp"
canonical: "https://opanuj.ai/blog/plan-mode-umarl-planowanie-nie/"
draft: false
excerpt: "Nowe modele nie potrzebują prowadzenia za rękę, więc planowanie jest zbędne? Rozkładamy tę tezę na części: co z planu wyrzucić, co w nim zostawić i kiedy w ogóle warto planować."
category: "Poradnik"
tags: ["ai","agenci","planowanie","claude-code","codex","podcast"]
author: "Przemek Smyrdek"
readingTime: 7
type: "post"
language: "pl"
---

Wrzesień przyniósł kolejny nekrolog w świecie programowania z AI. Tym razem pochowano Plan Mode, czyli tryb, w którym agent najpierw czyta kod i pisze plan, a dopiero potem rusza pliki.

W dyskusjach ta teza bywa upraszczana mniej więcej tak: modele najnowszej generacji świetnie rozumieją intencje programisty, więc prowadzenie ich za rękę jest zbędne, a nawet szkodliwe. Prompt, obserwacja, korekta kursu, kolejny prompt... i wracamy do vibe codingu.

Z Marcinem rozłożyliśmy tę tezę na części w [ostatnim odcinku podcastu Opanuj.AI](/podcast/odcinek/plan-mode-to-przeszlosc-planowanie-wrecz-przeciwnie-nowy-cookie-banner-epoki-ai/). Krótka wersja wniosków: w naszym workflow przełącznik w interfejsie w większości przypadków zastąpiliśmy własnymi skillami, czyli instrukcjami prowadzącymi agenta przez konkretny proces. Samo planowanie nadal jest nam potrzebne.

## Skąd ta dyskusja

Punktem wyjścia był tekst [„Plan mode is dead” Ayman Nadeem](https://www.aymannadeem.com/artificial/intelligence,/developer/tools/2026/09/24/plan-mode-is-dead.html), założycielki Nuanced, desktopowej aplikacji do kodowania z AI, wcześniej pracowniczki GitHuba. [Wątek na Hacker News](https://news.ycombinator.com/item?id=49840054) przekroczył 580 punktów i 500 komentarzy, a dyskusja szybko dotarła też na polski YouTube.

Sama Nadeem rozróżnia planowanie od dokumentu z planem. Krytykuje przede wszystkim interfejs, który każe człowiekowi czytać długą specyfikację i oddziela myślenie od budowania. Hasło „planowanie jest zbędne” idzie więc dalej niż jej argument.

W tym samym wątku [Boris Cherny, twórca Claude Code, opisał historię Plan Mode](https://news.ycombinator.com/item?id=49850929). Plan Mode był jego pomysłem - miał dość ciągłego przypominania modelowi, żeby najpierw zaplanował implementację, a dopiero potem zabrał się za kod.

Jak wyjaśnia Cherny, mechanizm opierał się na przypomnieniu w prompcie i nie zmieniał zestawu dostępnych narzędzi. To opis konkretnego rozwiązania w Claude Code, a nie wszystkich trybów planowania.

## W czym grabarze mają rację

W kilku punktach się z nimi zgadzamy.

- **Przełącznik w interfejsie zwykle nie jest nam potrzebny.** My dość szybko przeszliśmy na własne prompty i skille do planowania, bo prompt dopasowany do zadania frontendowego czy backendowego radzi sobie lepiej niż generyczny. Wyjątkiem jest Codex, gdzie Plan Mode włączamy dla wygodnego interfejsu, ale cały proces i tak prowadzi nasz skill.
- **Sam Plan Mode nie gwarantuje bezpieczeństwa.** Łatwo pomyśleć: „model tylko przegląda kod, co najwyżej napisze markdowna”. Samo polecenie w prompcie nie jest jednak blokadą techniczną. [Dokumentacja Claude Code opisuje osobne reguły uprawnień podczas planowania](https://code.claude.com/docs/en/permission-modes), zależne od konfiguracji sesji. Trzeba sprawdzić te reguły, a nie ufać nazwie trybu.
- **Nie każda zmiana potrzebuje planu, a plan zwykle nie potrzebuje linijek kodu.** Nie potrzebujemy wieloetapowego procesu do dodania przycisku. A jeśli bardzo inteligentnemu modelowi dasz zbyt dokładną instrukcję ("tu napisz ifa, tam switcha"), tracisz część jego inteligencji, bo model idzie twoim tokiem myślenia zamiast wybrać coś lepiej dopasowanego do problemu.

Półtora roku temu szczegółowe planowanie było w naszej pracy niezbędne, bo model łatwo gubił się w czymkolwiek złożonym. Dziś wbudowane tryby potrafią długo planować i palić masę tokenów, a w naszych zadaniach lepsze rezultaty dają własne skille.

## Prompt bez ram też kosztuje

Nawet na poziomie czysto ekonomicznym da się obronić podpowiadanie modelowi. Bez wyznaczonych granic agent może błądzić po systemie i sprawdzać obszary, które nie mają znaczenia dla zadania.

Do tego dochodzi brak determinizmu - po dwóch identycznych promptach agent może odwiedzić inne pliki i wywołać inne narzędzia. Różne ścieżki nie muszą być błędem, ale każda zbędna wycieczka kosztuje tokeny i czas. Wystarczy podejrzeć kilka sesji, żeby zobaczyć, gdzie agent traci czas.

Ile planowania potrzebujemy, żeby te granice ustalić?

## Kiedy w ogóle planować

Hasła w stylu "planowanie umarło" upraszczają rzeczywistość i zwykle psują workflow. W odcinku zaproponowaliśmy trzy poziomy:

1. **Mała, odwracalna zmiana.** Zadanie da się opisać jednym zdaniem i łatwo sprawdzić testem. Rozmawiasz z agentem, pozwalasz mu wykonać zmianę, sprawdzasz wynik testu i przeglądasz diffa. Osobny plan zwykle nic tu nie wniesie.
2. **Większa zmiana, którą łatwo odwrócić.** Działasz na nieznanym kodzie albo nie masz pewności, czy podejście się sprawdzi. Wystarczy krótki, szybki plik ze specyfikacją.
3. **Zmiana ma poważne konsekwencje albo nieoczywiste wymagania.** Ruszasz kluczowy schemat danych, autoryzację, obsługę pieniędzy lub zdrowia albo publiczne API, od którego zależą inni. Być może praca rozciąga się na kilka zmian i kilka dni. Wtedy trzeba przysiąść, przeanalizować i wykorzystać model w samym procesie planowania. Samo zapromptowanie skończy się tu źle, nawet jeśli na pierwszy rzut oka tego nie zauważysz.

Na trzecim poziomie najlepiej sprawdza się u nas przemyślany proces planowania oparty o skill. Zawiera to, co trzeba, i pomija to, co nie wnosi wartości - z detalami implementacyjnymi na czele.

## Co zostaje w planie

W [zaleceniach OpenAI dotyczących pracy z Codexem](https://learn.chatgpt.com/docs/prompting#prompting-codex) znajdziesz oczekiwany efekt, ograniczenia i sposób weryfikacji. [Anthropic zaleca też wyjaśniać powód stojący za instrukcją](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices). To dobrze pasuje do tego, co zostawiamy w naszych planach:

1. **Intencja.** Co rozwiązujemy, dla kogo i jaki jest oczekiwany efekt: metryka do poprawienia, stan, który ma się zmienić, funkcja, która ma się pojawić. Dojście do tego to wciąż praca intelektualna po twojej stronie. Nie pojawia się sama tylko dlatego, że zaczynasz pisać prompta.
2. **Kontrakty.** Co ma zostać nietknięte: publiczne API, schematy danych, elementy wymagające wstecznej kompatybilności, integracje z innymi systemami. Do tego zasady, których trzeba przestrzegać, i rzeczy, których absolutnie nie chcemy zobaczyć po zakończeniu pracy.
3. **Świadome decyzje.** Co nie jest przypadkiem, tylko wynikiem szerszej analizy. I gdzie są znane niewiadome, które model powinien rozpracować po drodze.
4. **Faza projektu.** O tym za chwilę, bo to najczęściej pomijany element.
5. **Kryterium stopu.** Kiedy kończymy pracę: czy bez końca szukamy kolejnych usprawnień, czy celujemy w konkretną metrykę, czy zatrzymujemy się na określonym etapie i sterowanie wraca do człowieka.

Żaden z tych punktów nie wymaga rozpisywania kodu. Model może pomóc nam je opracować, ale to my zatwierdzamy cel, granice i decyzje.

Przy okazji tej wrześniowej dyskusji Anthropic opublikował [opis optymalizacji claude.ai](https://claude.dev/blog/how-we-made-claude-ai-faster/). Zespół określał cele, budował benchmarki i obserwował wyniki, a każda zmiana wymagała akceptacji człowieka.

Po osiągnięciu celów zespół wyznaczał kolejne i szukał dalszych usprawnień. Ludzie rozstrzygali też, kiedy dalszy zysk nie uzasadnia już kosztu utrzymania rozwiązania. Ten przykład dobrze pokazuje, że swoboda implementacji nadal potrzebuje ram i decyzji po stronie człowieka.

## Decyzje po naszej stronie

Marcin podał w odcinku taki przykład: użytkownik zmienia adres e-mail na taki, do którego jest już przypisane inne konto. Co robimy?

Scalamy oba konta? Odrzucamy operację? Blokujemy użytkownika? A może budujemy jeszcze inny mechanizm?

Każda z tych opcji ma mocne i słabe strony. Model zaimplementuje dowolną z nich całkiem nieźle, ale to ty i twoi użytkownicy będziecie z tą decyzją żyć.

Co chcemy obsługiwać jako zespół? Jakie doświadczenie chcemy dać ludziom? Jaką cenę jesteśmy gotowi za to zapłacić?

Tego nie da się obliczyć. Te decyzje muszą trafić do planu, zanim agent wybierze za ciebie.

## Czynnik czasu

W regułach i README najczęściej brakuje mi opisu dynamiki projektu.

Rzadko kto pisze w instrukcjach dla agenta, że zmiana jest wdrażana stopniowo: najpierw trafia do 1% użytkowników, a później do pozostałych 99%. A to wpływa na cały sposób pracy: co robimy odważniej, a co bardziej defensywnie. Znaczenie ma też dostępność feature flag, czyli przełączników pozwalających włączać funkcję dla wybranych użytkowników.

Przykład z naszego ogródka: toolkit do benchmarkowania, na którym cały czas intensywnie iterujemy. Model bardzo pilnuje tam, żeby niczego nie zepsuć, nie złamać kontraktów i zachować wsteczną kompatybilność. Ja z kolei zwykle mówię mu wprost: to jest piaskownica, nie bój się łamać schematów, a jeśli masz w głowie coś bardziej rewolucyjnego, to po prostu to wprowadźmy.

Statyczny opis modułów, funkcji i endpointów tego nie odda. Inne decyzje są właściwe w projekcie back-office'owym rozwijanym bez presji czasu, a inne, kiedy pracujesz nad trzema aplikacjami produkcyjnymi, z których jedna płonie. Jeśli nie zapiszesz tego w instrukcji lub planie, który model widzi, będzie albo zbyt ofensywny, albo zbyt defensywny.

## Plan jako moment zatrzymania

Jest jeszcze jeden argument, mniej techniczny. Agent potrafi podjąć się niemal każdego pomysłu, który mu podsuniesz. Dlatego paradoksalnie wartość pojawia się wtedy, gdy czegoś nie zrobisz, zatrzymasz się albo zwolnisz.

Nawet krótka rozmowa o tym, co właściwie chcesz osiągnąć, wyrywa cię z pracy i myślenia na autopilocie. Modele są w tym zresztą świetne - jeśli o to poprosisz, zadają pytania, podsuwają opcje i pomagają dojść do rozwiązania, którego nie było ani w twojej głowie, ani w pierwszej propozycji modelu. Na takim dociekliwym zadawaniu pytań opiera się choćby [skill `grill-me` Matta Pococka](https://github.com/mattpocock/skills/tree/main/skills/productivity/grill-me).

Chętnie zobaczyłbym benchmark porównujący tryb brute force ("idziemy do przodu i korygujemy kurs") z podejmowaniem kluczowych decyzji na starcie. Takiego porównania nie mam, ale intuicja podpowiada mi, że ten pierwszy częściej wyprowadza w maliny - i czasowo, i kosztowo, i jakościowo.

Kiedy jesteś wyspany i się nie spieszysz, może dojdziesz w to samo miejsce bez planu. Tylko jak często tak jest?

## Na koniec

W naszym workflow Plan Mode stracił znaczenie na długo przed ostatnimi premierami. Planowanie zostaje, zwłaszcza tam, gdzie podejmujesz trudne decyzje, z którymi potem będziesz żyć.

Zanim odpalisz agenta przy takiej zmianie, zapisz, co robimy, czego nie robimy, na czym nam zależy, gdzie są granice i kiedy kończymy. Resztę zostaw modelowi.

W [pełnym odcinku o Plan Mode i planowaniu](/podcast/odcinek/plan-mode-to-przeszlosc-planowanie-wrecz-przeciwnie-nowy-cookie-banner-epoki-ai/) rozmawiamy też o nowym modelu działającym jak szybki klasyfikator, o oznaczaniu reklam radiowych z lektorem AI w świetle AI Act oraz o premierach Opusa 5.5 i nowych modeli GPT-6 wraz z tym, co mówią o cenach subskrypcji i API. Na stronie odcinka znajdziesz też pełną transkrypcję.