O czym jest ten film
- We wrześniu Tarik z zespołu Claude Code zasugerował usunięcie trybu planowania (plan mode). Wpis zebrał około 3 tysięcy odpowiedzi, a Boris poparł go na Hacker News — mimo że przez cały rok była to najczęściej polecana funkcja.
- Co się zmieniło? Nowe modele: Opus 5.5 sam zastanawia się przed odpowiedzią, sam ocenia rozmiar neededgo namysłu i utrzymuje kontekst na długich zadaniach, więc przypominanie „jeszcze nie koduj” nic już nie wnosi.
- Prawdziwa wartość plan mode’u leżała po stronie człowieka: plan był listą założeń Claude’a, które można było potwierdzić lub obalić, zanim cokolwiek powstało.
- Zamiennik: czteropunktowy brief w pierwszej wiadomości — jak wygląda „gotowe”, jak sprawdzisz efekt, co jest poza zakresem, czego nie wolno tknąć. Jeśli nie znasz odpowiedzi, poproś Claude’a, żeby najpierw cię przesłuchał.
- Claude.txt: Anthropic ucięło ponad 80% własnego promptu systemowego Claude Code bez mierzalnego spadku jakości; dokumentacja zaleca mniej niż 200 linii, a badanie pokazało, że pliki kontekstowe generowane narzędziowo podnoszą koszt działania o około 20%.
- Ale kasowanie całości to błąd — to problem jakościowy, nie ilościowy. Rozwiązanie: audyt linia po linii (pytanie kontrolne: „czy bez tej linii Claude zacznie robić błędy?”) zaczynając od /doctor prompt audit.
- Zespoły agentów: człowiek z zespołu Codex mówi o „podatku od koordynacji” przy ponad dwóch agentach, a Anthropic trzy tygodnie później pokazało 8000 agentów w jednym zadaniu (66 z 70 ukrytych bugów). Konsensus: jeden agent-orkestrator, który sam dzieli robotę.
- Haiku 5.5 jest około 40 razy tańszy od Opusa per token, ale na Terminal Bench zdobywa 39% wobec 71% Sonneta 5.5 — błędy wracają do naprawy i tanie zadanie robi się drogie.
- Test dziewięciu najpopularniejszych paczek umiejętności (w tym Superpowers): 450 uruchomień na Opusie 5.5 przeciwko neutralnemu plikowi-placebo. Tylko dwie z dziewięciu pokonały placebo — Superpowers nie.
- Ogólna zasada: optymalizuj koszt całego zadania (tokeny + własny czas + rundy poprawek), a nie cenę pojedynczego tokenu, linii pliku czy agenta.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Plan mode możesz odstawić, planowania nie
Na czym polega: Opus 5.5 sam planuje kroki wykonania i sam podejmuje sensowne założenia, więc polecenie „jeszcze nie koduj” straciło sens. Wartość trybu zawsze leżała po twojej stronie — plan ujawniał założenia do sprawdzenia, zanim agent zbudował coś źle.
Jak stosować: w pierwszej wiadomości podaj cztery rzeczy: (1) definicję „gotowe”, (2) sposób weryfikacji efektu, (3) co jest poza zakresem, (4) czego model nie może tknąć. Chcesz zachować stary nawyk — poproś o jednozdaniowy plan przed startem lub użyj /plan.
Na co uważać: krótkie zlecenie bez tych czterech punktów przenosi wykrywanie braków na etap wykonania, a poprawianie gotowca jest dużo droższe niż sprostowanie planu.
2.Nie wiesz, co napisać w briefie? Poproś o wywiad
Na czym polega: jeśli nie potrafisz odpowiedzieć na którykolwiek z czterech punktów zlecenia, brakujące decyzje może z ciebie „wyciągnąć” sam Claude — zanim ruszy do roboty.
Jak stosować: zacznij od prośby w rodzaju: „Zanim zaczniesz, zadaj mi pytania potrzebne do doprecyzowania definicji gotowości, walidacji, zakresu i ograniczeń”. Dopiero po odpowiedziach puszczaj zadanie.
Na co uważać: wywiad ma być etapem, nie rozmową w nieskończoność — domknij go konkretnymi ustaleniami i wpisz je do pierwszego polecenia.
3.Claude.txt: mniej znaczy więcej, ale nie zero
Na czym polega: Anthropic ścieło ponad 80% promptu systemowego Claude Code bez strat na testach, dokumentacja zaleca plik poniżej 200 linii, a badania pokazują, że nadmiarowe linie kontekstu potrafią podnieść koszt o ~20% i pogorszyć wyniki.
Jak stosować: trzymaj plik krótki i traktuj każdą linię jak pozycję w budżecie — usuwaj instrukcje, które Claude spełnia nawet bez polecenia.
Na co uważać: zbyt długi plik sprawia, że model ignoruje zasady — tracisz właśnie te najważniejsze, na przykład ustalenia zespołu czy preferencje klienta.
4.Audytuj plik linia po linii, zamiast kasować całość
Na czym polega: regularne „świeże” kasowanie całego pliku miesza problem jakościowy z ilościowym — tracisz reguły, które realnie działały, choć nie wiesz które.
Jak stosować: najpierw uruchom /doctor prompt audit — wyłapie instrukcje pisane pod starsze modele i odwołania do nieistniejących plików. Potem każdą pozostałą linię oceniaj pytaniem: „Czy usunięcie sprawi, że Claude zacznie robić błędy?”. Zostaw to, czego model nie wyczyta z repozytorium.
Na co uważać: ocena wymaga założeń — przy wątpliwościach lepiej przetestować linię na kilku zadaniach niż zgadywać.
5.Jeden plik agents.txt może obsłużyć dwa narzędzia
Na czym polega: Claude Code czyta teraz plik agents.txt, gdy nie znajdzie Claude.txt, więc jeśli pracujesz również w Codex, nie musisz prowadzić dwóch równoległych zestawów instrukcji.
Jak stosować: prowadź jeden agents.txt jako wspólne źródło zasad dla obu narzędzi.
Na co uważać: pilnuj, by zawierał tylko zasady wspólne — różnice między narzędziami trzymaj osobno, inaczej każde z nich dostanie instrukcje, których nie rozumie.
6.Zamiast stałej ekipy — jeden orkiestrator
Na czym polega: strona Codex ostrzega przed „podatkiem od koordynacji” — agenty, które sobie nie ufają, spędzają czas na wzajemnym sprawdzaniu swojej pracy. Anthropic mimo wszystko radzi zaczynać od małej skali, a nowe „projekty” w Claude Code działają jak jedna rozmowa prowadząca, która sama otwiera wątki, gdy ich potrzebuje.
Jak stosować: oddaj zadanie jednemu agentowi-orkiestratorowi i pozwól mu zdecydować, kiedy rozbić pracę na role. Agentów będących wyłącznie opisem roli („jesteś senior copywriterem”) usuń.
Na co uważać: zostaw tych agentów, którzy niosą wiedzę niedostępną w plikach (np. checklistę twojego procesu) albo celowo ograniczony zestaw narzędzi, gdy chcesz coś mocno zawęzić.
7.Przy dużym rozbiciu zadań — z limitem rozmiaru
Na czym polega: dla zadań faktycznie wymagających wielu podagentów (research po wielu źródłach) Anthropic pokazało skalę do 8000 agentów — rozproszona ekipa znalazła 66 z 70 ukrytych bugów — ale obie firmy zgodnie mówią: zaczynaj od małej skali, bo to pożeracz tokenów.
Jak stosować: korzystaj z wbudowanego deep research albo poproś o workflow w trybie Ultra, wcześniej ustawiając jego rozmiar na „small” w konfiguracji.
Na co uważać: przed skalowaniem porównaj zysk jakości z kosztem — wieloagentowość szybko rośnie w tokenach, a zysk bywa płaski.
8.Tańszy token nie znaczy tańsze zadanie
Na czym polega: Haiku 5.5 jest około 40 razy tańszy od Opusa 5.5 w przeliczeniu na token, ale na Terminal Bench zdobywa 39% wobec 71% Sonneta 5.5. Każdy błąd taniego modelu wraca do głównego, więc zadania kończą się dwiema–trzema rundami poprawek i kosztują łącznie więcej.
Jak stosować: przepuść to samo zadanie dwiema drogami — na modelu tanim i mocnym — i porównaj całkowite zużycie: tokeny, liczbę rund poprawek i swój czas na sprawdzanie. Ceny pojedynczego tokenu nie porównuj.
Na co uważać: przy prostej pracy przeszukiwawczej tania opcja może się opłacać; przy wnioskowaniu i decyzjach zwykle nie.
9.Wtyczki testuj przeciwko placebo
Na czym polega: dziewięć najpopularniejszych paczek umiejętności — z Superpowers włącznie — uruchomiono 450 razy na Opusie 5.5 i porównano z neutralnym plikiem o tej samej długości. Tylko dwie z dziewięciu pokonały placebo. Wtyczki powstawały dla modeli, które pomijały kroki; nowe topowe modele coraz lepiej radzą sobie bez nich.
Jak stosować: przepuść swoje zwykłe procesy — z jasnym, czteropunktowym zleceniem — przez model bez wtyczek i z wtyczkami, potem porównaj wyniki. Może się okazać, że jedną z nich odinstalujesz i zaoszczędzisz tokeny.
Na co uważać: to nie jest wezwanie do odinstalowania wszystkiego — modele wciąż nie są doskonałe i niektóre dodatki realnie pomagają. Decyduj testem, nie trendem.
10.Optymalizuj koszt całościowy, nie jednostkowy
Na czym polega: wszystkie omówione mity łączy jeden schemat: ludzie patrzą na cenę jednostki (tokenu, linii pliku, agenta), a powinni na koszt całego zadania wraz z własnym czasem.
Jak stosować: każdą zmianę konfiguracji — model, długość Claude.txt, wtyczkę — sprawdzaj pomiarem przed i po na zadaniu, które faktycznie robisz.
Na co uważać: wynik jednego testu nie musi przenosić się na inne typy zadań — testuj na tych, które stanowią trzon twojej pracy, nie na wymuszonych przykładach.
Redakcyjne tłumaczenie
Tryb planowania pod nożem
We wrześniu Tarik z zespołu Claude Code napisał, że zespół rozważa likwidację trybu planowania. „Nie sądzę, żeby modele jeszcze go potrzebowały”. Wpis zebrał około trzech tysięcy odpowiedzi i sporą lawinę emocji. Wkrótce wsparł go Boris, na Hacker News: tryb planowania był kiedyś przydatny — dziś już nie. Tymczasem jeszcze przed tą burzą było to prawdopodobnie najczęściej polecana rada w całym ekosystemie Claude Code. Co się więc realnie zmieniło i kto ma rację? To pierwszy z pięciu popularnych sposobów pracy z Claude, które moim zdaniem są już nieaktualne albo prawdziwe tylko w połowie.
Co się zmieniło: dojrzały modele
Zmieniły się modele. Boris tłumaczy, że tryb planowania był w gruncie rzeczy krótkim przypomnieniem w promptcie, w rodzaju: „Jesteś w trybie planowania. Jeszcze nie koduj”. Starsze modele naprawdę tego potrzebowały — zostawione same sobie rzucały się od razu do budowania. Nowe już nie. Opus 5.5 zawsze zastanawia się, zanim odpowie, i sam ocenia, jak długo ma myśleć. Przeglądnie twoje pliki, sam poczyni sensowne założenia i utrzyma wątek na dłuższych zadaniach, nie gubiąc ważnego kontekstu. Rada „jeszcze nie koduj” niewiele więc dziś wnosi — dlatego Boris przestał z niej korzystać.
Dlaczego wszyscy pokochali plan mode
Warto jednak zrozumieć, skąd brała się sympatia do tej funkcji. Plan, który dostawałeś, był tak naprawdę listą założeń, jakie poczynił Claude — listą, którą mogłeś potwierdzić albo obalić. Widziałeś, których plików siętknie, co według niego znaczy „gotowe” i co zamierza zmienić w strukturze kodu. Czytałeś, wyłapywałeś błędne założenia i prostowałeś je, zanim cokolwiek powstało. Czysta oszczędność tokenów: poprawienie planu jest dużo tańsze niż cofanie godziny pracy, którą agent wykonał w tle. Dokładnie to miał na myśli najwyżej oceniony komentarz pod wpisem Tarika: „Tryb planowania nie jest dla agenta. Jest dla mnie”.
Jak to wyglądało w praktyce: sekcja wydatków reklamowych
Weź typowy przykład: chcesz dodać do cotygodniowego raportu klienta sekcję z wydatkami na reklamę. Klasycznie, w trybie planowania, wpisywało się coś po chwylipilnego: „dodaj sekcję z wydatkami reklamowymi do raportu klienta”. Dwa razy Shift+Tab i Claude wracał z planem — a podczas czytania zaczynały wychodzić problemy. Agent sięgnie po zeszłomiesięczny arkusz, przy okazji przerobi stronę podsumowującą. Wyłapywałeś błędy, kazałeś je poprawić, plan się aktualizował, zatwierdzałeś i dopiero wtedy ruszało wykonanie.
Haczyk w tym, że samo zlecenie było słabe. To plan miał być momentem, w którym wyjdzie, co przegapiłeś w poleceniu i jakich założeń nie podałeś. Podejmowałeś te same decyzje co zwykle — tylko czekałeś, aż Claude poczyni założenia za ciebie. Dziś te decyzje podejmujesz przed wciśnięciem entera i to działa, bo Opus 5.5 potrafi sam zaplanować wykonanie kroków: otworzyć folder, znaleźć właściwe szablony, wybrać właściwy arkusz i ustalić kolejność. Starsze modele potrafiły to schrzanić nawet przy lepszym zleceniu — dlatego trzeba było czytać plan i weryfikować go z wyprzedzeniem.
Czteropunktowy brief zamiast plan mode
Teraz wystarczy podać w pierwszej wiadomości to, czego agent nie wyczyta z twoich plików — czyli dokładnie to, co kiedyś musiał zgadywać. Do polecenia „dodaj sekcję z wydatkami reklamowymi do raportu klienta” dochodzą cztery stałe elementy:
- Jak wygląda „gotowe” — na przykład: „układ ma się zgadzać z październikowym, a nowa sekcja ma trafić zaraz za danymi o leadach”.
- Jak sprawdzisz efekt — na przykład: „sumy mają się bilansować z arkuszem z października”.
- Co jest poza zakresem — na przykład: „nie ruszaj strony podsumowującej”.
- Czego nie wolno tknąć — na przykład: „trzymaj się z dala od folderu współdzielonego z klientem, pracuj tylko na tym arkuszu”.
Ammar Nadeem, który odpalił cały wątek o śmierci plan mode, ujął to celnie: „Myliłem planowanie z planem”. Sam tryb to mit — planowanie nie jest. Moja rekomendacja: pomiń tryb planowania, ale te cztery punkty wpisuj zawsze w pierwszej wiadomości. Jeśli nie znasz jeszcze odpowiedzi na któreś z nich — poproś Claude’a, żeby najpierw przeprowadził z tobą wywiad i w ten sposób zdobył te informacje. A jeśli mimo wszystko chcesz widzieć jego założenia, poproś po prostu o jednozdaniowy plan przed rozpoczęciem pracy. I na wypadek, gdyby tryb został ostatecznie wycofany: polecenie /plan prawdopodobnie zostanie, więc będziesz mógł wrócić do dawnego procesu.
Claude.txt: dodawać linię czy kasować cały plik?
Druga sprawa: Claude.txt. W ciągu samych ostatnich dziesięciu miesięcy słyszeliśmy o nim zupełnie sprzeczne rady. Kiedyś: dodawaj linię za każdym razem, gdy Claude coś schrzani. Potem: kasuj cały plik co pół roku i buduj od zera. Obie pochodziły od Borisa.
Argument za kasowaniem jest mocny. Przy premierze modeli Claude 5 Anthropic ucięło ponad 80% własnego promptu systemowego Claude Code — i twierdzi, że na testach kodowania nie doszło do mierzalnego spadku. Dokumentacja zaleca teraz trzymać plik poniżej 200 linii, bo zbyt rozbudowany Claude.txt sprawia, że model ignoruje twoje zasady — a wtedy tracimy właśnie te reguły, na których nam naprawdę zależy. Nie tylko Anthropic tak mówi: badanie wykazało, że pliki kontekstowe pisane przez samo narzędzie lekko pogarszały wyniki agentów i podnosiły koszt działania o około 20%. Każda linijka w tym pliku więc kosztuje — niezależnie od tego, czy realnie pomaga.
Audyt zamiast kasowania całości
Ale kasowanie wszystkiego ma też wadę: tracisz reguły, które faktycznie działały, a nie wiesz, które to były. Repo Rails ujął to świetnie: „Kasowanie całości traktuje problem jakościowy tak, jakby był ilościowy”. Części rzeczy Claude nie wymyśli sam — decyzji, które podjął twój zespół, czy klienta, który nie znosi określonych sformułowań.
Werdykt: obie rady są w połowie słuszne, więc usuwać trzeba z wyczuciem. Skasuj to, co Claude robi i bez polecenia; zostaw to, czego nie zobaczy w twoich plikach. Test Anthropicu na każdą linię brzmi: „Czy usunięcie sprawi, że Claude zacznie robić błędy?”. W praktyce: najpierw uruchom /doctor prompt audit — wyłapie instrukcje pisane pod starsze modele i odwołania do plików, których już nie ma. Potem przejdź po tym, co zostało, linia po linii i oceniaj każdą względem tego pytania. A jeśli używasz również Codex — dobra wiadomość: Claude Code czyta teraz plik agents.txt, gdy nie znajdzie Claude.txt, więc jeden plik może obsłużyć oba narzędzia.
Zespoły agentów: spór dwóch obozów
(Przy okazji autor dziękuje za 100 tysięcy subskrypcji i zapowiada nowy kurs w swojej społeczności, mający uczyć przechodzenia od promptowania agentów do pełnego oddawania im procesów.)
Trzecia sprawa: zespoły agentów. Znasz te schematy — agent do researchu, agent-pisarz, agent-recenzent, czasem cała rada doradcza. I akurat ludzie budujący Codex i ludzie budujący Claude Code są w zupełnym sporze, czy to w ogóle ma sens.
We wrześniu Eric Provencher z zespołu Codex twierdził, że uruchamianie więcej niż dwóch agentów naraz prawie zawsze zużywa mnóstwo tokenów bez zysku jakości. Jego argument: agenty sobie nie ufają, więc spędzają czas na wzajemnym sprawdzaniu swojej pracy. Nazywa to „podatkiem od koordynacji”. Trzy tygodnie później Anthropic wypuściło podejście dokładnie odwrotne: Claude potrafi teraz uruchomić do 8000 agentów w jednym zadaniu na swojej platformie hostingowej. Ukryli 70 bugów w dużej bazie kodu — pojedynczy agent znalazł od 14 do 27 z nich, a większa, rozproszona ekipa aż 66 na 70.
Co obie strony mają wspólnego? Anthropic, podobnie jak OpenAI, mówi: zaczynaj od małej skali, bo to spore zużycie tokenów. W ich wersji Claude pisze dla siebie wewnętrzny plan podziału pracy — sam tworzy zespół. Tak w skrócie działają nowe „projekty” w Claude Code: jedna wiodąca rozmowa, która otwiera własne wątki tylko wtedy, gdy ich potrzebuje.
Dawniej kazano nam składać zespoły samodzielnie — były do tego nawet specjalne funkcje w Claude, a agentom nadawaliśmy dedykowane role. Dziś rekomendacja jest inna: porzuć sztywną ekipę, oddaj zadanie jednemu agentowi-orkiestratorowi i pozwól Claude zdecydować, kiedy rozb pracę na role. Jeśli masz agentów, którzy są wyłącznie „rolą” — w stylu „jesteś senior copywriterem” — możesz ich śmiało usunąć. Zostaw tych, którzy niosą wiedzę, której Claude nie ma (np. checklistę twojego procesu), albo mają celowo zawężony zestaw narzędzi, gdy chcesz coś mocno ograniczyć. A przy zadaniach naprawdę wymagających dużego rozbicia — jak research po wielu źródłach — korzystaj z wbudowanego deep research albo poproś o workflow w trybie Ultra, wcześniej ustawiając jego rozmiar na „small” w konfiguracji, żeby nie wymknął się z rąk pod względem tokenów.
Haiku 5.5 dla pomocników: tanio per token, drogo per zadanie
Gdy ludzie dzielą już robotę między agenty, chętnie powtarzają kolejną poradę: posadź pomocników na najtańszym dostępnym modelu. I tu wchodzi Haiku 5.5, wydany 7 października, tańszy od Opusa 5.5 w przeliczeniu na token około czterdziestokrotnie. Czterdzieści razy — brzmi absurdalnie. W ciągu kilku dni najchętniej udostępniana rada brzmiała więc: przenieś wszystkich agentów przeszukujących pliki na Haiku 5.5. Na pierwszy rzut oka rozsądne — pomocnicy w końcu głównie wyszukują. Tyle że na Terminal Bench (Informacja dodatkowa: benchmark zadań wykonywanych w terminalu, mierzący skuteczność agentów kodujących.) Haiku 5.5 zdobywa 39%, a Sonnet 5.5 — 71%. Tańszy model myli się po prostu częściej, a każdy błąd wraca do głównego modelu, żeby go naprawić. Ktoś na Reddicie wypróbował to w praktyce i błyskawicznie wrócił do Opusa na wszystko, bo każde zadanie kończyło się dwiema–trzema rundami poprawek i łącznie zjadało więcej tokenów oraz czasu niż praca od razu na mocniejszym modelu.
Tańszy token nie znaczy tańsze zadanie. Płacisz mniej za każde słowo, ale potencjalnie dużo więcej za własny czas na sprawdzanie i za dłuższą drogę do efektu. Pytanie brzmi: co właściwie optymalizujesz? Jeśli chcesz to sprawdzić — przepuść to samo zadanie dwiema drogami i porównaj całkowite zużycie na koniec, nie cenę pojedynczego tokenu. A „zużycie” to zarówno tokeny, jak i twój czas.
Frameworki i wtyczki: test z placebo
Wszystko dotąd dotyczyło domyślnych ustawień. A co z poradami, żeby dokładać do Claude frameworki i popularne wtyczki? Czy są tak dobre, jak obiecywano? Są dodatki typu Superpowers, które dają Claude całą metodę planowania, budowania i testowania — i należą do najczęściej instalowanych rozszerzeń. Od premiery Opusa 5.5 ludzie pytają, czy są jeszcze potrzebne. Najwyżej oceniona odpowiedź na forum Claude AI na Reddicie na pytanie „czy Superpowers jest wciąż potrzebne” brzmiała krótko: „Niepotrzebne już”. Zwolennicy wtyczek odpowiadają: „Czysty Claude Code na większych zadaniach nadal oddaje byle jak przemyślaną robotę”. Ten argument rozumiem.
Ale ktoś przeprowadził rzetelny sprawdzian: dziewięć najpopularniejszych paczek umiejętności — z Superpowers włącznie — uruchomił 450 razy na Opusie 5.5, za każdym razem porównując efekt z neutralnym plikiem-placebo o tej samej długości. Tylko dwie z dziewięciu pokonały placebo — i Superpowers nie było wśród nich. Co zresztą w żaden sposób nie jest zarzutem pod adresem tej wtyczki. Powstała dla modeli, które pomijały kroki, a Opus 5.5 i pozostałe czołowe modele coraz lepiej radzą sobie z tym od razu, bez dodatków. Nie są doskonałe, ale robią wyraźne postępy. Zresztą chce mi się wierzyć, że gdyby nie frameworki pokroju Superpowers, Anthropic i OpenAI wolniej wykrywałyby luki w swoich modelach — to właśnie one zasiliły rozwój produktu i sprawiły, że dziś modele rozwiążą te problemy natywnie.
Nie namawiam do odinstalowania wszystkich wtyczek jeszcze dziś i nie twierdzę, że wszystkie się zestarzały — modelom daleko do doskonałości. Ale to dobry moment na eksperyment: przepuść swoje zwykłe prompty i procesy, z jasnymi instrukcjami obejmującymi omówione cztery punkty, przez model bez wtyczek i porównaj z wynikami na wtyczkach. Może się okazać, że jedną z nich wywalisz, uprościsz sobie życie i zaoszczędzisz na tokenach.
Na koniec
Jeśli chcesz przenieść te rady na prawdziwe procesy, nowy kurs w Agentic Academy jest zbudowany dokładnie wokół tego tematu: w ciągu 30 dni oddajesz Claude jeden cały proces, zaczynając od tego, jak napisać dobre czteropunktowe zlecenie. Link w opisie filmu. Dzięki za obejrzenie — do następnego.