O czym jest ten film
- Teza wyjściowa: domyślnie Claude Code jest dostrojony tak, żeby użytkownik czuł się produktywny, a nie tak, żeby zarabiał — i ta różnica kosztuje czas oraz pieniądze.
- Przychód ograniczają dwie rzeczy: jakość tego, co produkujemy, i tempo produkcji. Cztery zaprezentowane ulepszenia podnoszą obie.
- Ulepszenie pierwsze — skill
/roast: rada niezależnych ról, które atakują pomysł z różnych stron, zanim powstanie choć linijka kodu; oparte na badaniach nad sykofancją modeli. - Ulepszenie drugie — pętla weryfikacji: model ma sam sprawdzać i stres-testować własną pracę (m.in. zrzutami ekranu i klikaniem po stronie), zanim uzna ją za skończoną.
- Ulepszenie trzecie — higiena kontekstu: zjawisko „context rot”, komendy
/contexti/clearoraz autorski skill „session handoff” do przenoszenia pracy do czystej sesji. - Ulepszenie czwarte — podagenty pracujące równolegle plus komenda
/goal, w której o ukończeniu zadania decyduje osobny model-sędzia. - Wszystko pokazane na żywo na jednym pomyśle: narzędziu za 9 dolarów miesięcznie, zamieniającym transkrypcje z YouTube w tydzień postów na LinkedIn.
- Finałowe demo łączy wszystkie ulepszenia: kompletny zestaw materiałów wejścia na rynek powstaje w około osiem minut.
- Każdy problem autor popiera badaniami: nad przytakiwaniem modeli, lukami w kodzie z Copilota i skutecznością zespołów agentów u Anthropic.
- Rolą człowieka przestaje być wykonywanie — staje się decydowanie, ocenianie i pilnowanie jakości.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Model, który się z Tobą zgadza, to problem, nie zaleta
Na czym polega: Zgodnie z przywołanym badaniem „Elephant” modele AI nie podważają ram narzuconych przez użytkownika w około 88 procentach przypadków (u ludzi to około 60 procent), a personalizacja i pamięć dodatkowo zwiększają uległość (badania MIT i Penn State). Domyślny Claude chwali więc każdy pomysł — również zły.
Jak stosować: Każ w prompcie modelowi odgrywać adwokata diabła i podważać Twoje założenia, zanim cokolwiek zbuduje albo zaakceptuje plan.
Na co uważać: Im dłużej i ściślej pracujesz z modelem, tym lepiej mówi to, co chcesz usłyszeć — aprobaty nie traktuj jako potwierdzenia słuszności pomysłu.
2.Jedna opinia to za mało — zbierz radę ról
Na czym polega: Skill /roast tworzy radę postaci: kontrarian szuka wad krytycznych, ekspansjonista — największych zysków, myśliciel pierwszych zasad działa w czystej logice, badacz ściąga z sieci realne dane rynkowe, kupujący mówi wprost, czy zapłaci, a sędzia wydaje werdykt (zielone światło, przebudowa albo kosz) i wskazuje najtańszy test na 48 godzin.
Jak stosować: Zanim ruszy jakakolwiek budowa, przepuść pomysł przez kilka niezależnych perspektyw i każ wskazać jedną najtańszą weryfikację — na przykład 20–30 wiadomości do osób z jednej niszy.
Na co uważać: Rada potrzebuje kontekstu: kto jest klientem, na czym polega Twoja przewaga, jakie budżety i terminy. Bez tego opinie będą ogólnikowe.
3.„Gotowe” w ustach modelu to hipoteza, nie fakt
Na czym polega: W badaniu NYU około 40 procent z 1600 programów wygenerowanych przez GitHuba Copilota miało luki bezpieczeństwa. Autor przywołuje też agenta, który pewnie zameldował wysłanie setek wiadomości, a faktycznie wysłał ledwie pierwszą czwartą część — i wykryto to dopiero po czterech dniach.
Jak stosować: Weryfikuj efekty u źródła — w logach, statystykach, skrzynce — a nie deklaracją modelu; każ modelowi dowodzić wykonania, zanim uzna zadanie za skończone.
Na co uważać: Model potrafi jednocześnie nie wykonać zadania i pewnie twierdzić, że wykonał. Im więcej „ciemnego kodu”, czyli fragmentów pisanych przez agenta bez Twojego udziału, tym droższe mogą być konsekwencje.
4.Niech model obejrzy swoją pracę oczami użytkownika
Na czym polega: Zamiast ufać, że strona „wygląda dobrze”, Claude Code z Playwrightem sam fotografuje każdą sekcję w dwóch widokach (desktop i mobilny), ocenia zrzuty i poprawia, aż do zera widocznych błędów.
Jak stosować: Wpleć w prompt pętlę: zbuduj → zrób zrzuty → oceń → popraw → powtórz, i dopisz mierzalną definicję ukończenia („wszystkie sekcje sfotografowane w obu widokach, formularz wygląda czysto”).
Na co uważać: Zrzuty potwierdzają poprawność techniczną, nie jakość projektową — generyczny, „wygenerowany przez AI” wygląd nadal zostaje do poprawienia człowiekowi.
5.Testuj formularze jak złośliwy użytkownik
Na czym polega: W demonstracji Claude sam wymyślał przypadki brzegowe — spacje przed adresem e-mail, dziwne numery telefonów, duplikaty — i w 22 testach (osiem poprawnych, czternaście wadliwych zgłoszeń) wyłapał m.in. brak ochrony przed podwójnym zapisem tą samą skrzynką.
Jak stosować: Każ modelowi wielokrotnie przejść przez formularz, najlepiej w widocznej przeglądarce, z różnymi danymi — i zameldować znalezione luki.
Na co uważać: Takie testy sprawdzają strukturę danych (format adresu), a nie ich dostarczalność ani działanie backendu — te warstwy wymagają osobnej weryfikacji.
6.Celuj w 90 procent za pierwszym podejściem, nie w 65
Na czym polega: Jednorazowy prompt prowadzi zwykle w ~65 procentach drogi, a resztę trzeba dopieszczać ręcznie. Pętla samokontroli z ostrą definicją ukończenia przesuwa wynik bliżej 90 procent, zostawiając człowiekowi sam przegląd i gust.
Jak stosować: Traktuj model jak pracownika, który oddaje raport „do jednego rzutu oka” — każ mu doszlifować robotę, zanim Ci ją wręczy.
Na co uważać: Bez precyzyjnej definicji „gotowe” pętla zatrzyma się za wcześnie albo będzie kręcić się w kółko bez końca.
7.Długa rozmowa ogłupia model — pilnuj okna kontekstowego
Na czym polega: „Context rot” dotknął wszystkich osiemnastu przebadanych czołowych modeli: jakość odpowiedzi spada z długością rozmowy, a degradacja zaczyna się na długo, zanim okno kontekstowe się zapełni.
Jak stosować: Monitoruj zużycie okna (pasek statusu, komenda /context), sprzątaj zbędne elementy, zmieniaj sesję po własnym progu (autor: około ćwierci miliona tokenów przy oknie miliona) i dobieraj najzdolniejszy model do zadania.
Na co uważać: Rozrost kontekstu nie boli — po prostu po cichu psuje wyniki, więc łatwo go nie zauważyć, dopóki nie będzie za późno.
8.Przenoś stan pracy, nie całą historię rozmowy
Na czym polega: Zamiast zagęszczać starą sesję (/compact), autor najpierw generuje skrót przekazania: decyzje zamknięte, kluczowe pliki, otwarte pytania, punkt wznowienia. Potem /clear i wklejenie skrótu do czystego okna — bez poczucia straty.
Jak stosować: Przed każdą zmianą sesji zapisuj podsumowanie i trzymaj wiedzę projektową w plikach projektu, nie w historii czatu.
Na co uważać: Skrót to kompromis — szczegóły giną, więc ważne ustalenia zapisuj od razu do trwałych plików, a nie licz na pamięć modelu.
9.Deleguj równoległość na podagenty
Na czym polega: W wewnętrznym teście Anthropic agent-koordynator z zespołem podagentów wypadł o ponad 90 procent lepiej niż pojedynczy agent robiący całość sam. Podagent to osobna instancja z własnym zadaniem i czystym kontekstem, meldująca do głównej sesji.
Jak stosować: Wszystko, co da się robić równolegle i niezależnie (research w kilku wątkach, przegląd komentarzy), zlecaj osobnym podagentom, a wyniki składaj w głównej sesji.
Na co uważać: Zadania muszą być rozłączne i prowadzić do różnych plików — w przeciwnym razie podagenty nadpiszą sobie nawzajem pracę.
10. Rozdziel wykonawcę od sędziego: /goal z obiektywną metą
Na czym polega: Komenda /goal ustawia warunek ukończenia, a osobny model-ewaluator sprawdza co turę, czy meta została osiągnięta — wykonawca nie ocenia więc samego siebie. W demo kompletny zestaw materiałów wejścia na rynek powstał w około osiem minut.
Jak stosować: Formułuj mierzalne cele (pliki istnieją, badanie z 6+ konkurentami, 25 szkiców) i dołącz przebieg weryfikacyjny po zakończeniu. /goal nie musi działać godzinami — większość przebiegów autora trwa 20–30 minut.
Na co uważać: Mglisty cel typu „ma być dobrze” sprawi, że pętla zatrzyma się na samozadowoleniu modelu.
Redakcyjne tłumaczenie
Od zabieracza czasu do wspólnika w interesach
Znalazłem sposób, żeby uczynić z Claude Code najlepszego wspólnika biznesowego, jakiego mogłem sobie wymarzyć — i przez ostatnie trzydzieści dni zarobiłem trzy razy więcej. Claude ma bowiem pewne przywary, których większość ludzi w ogóle nie dostrzega, a każda z nich kosztuje czas i pieniądze wypalane na rzeczach, które nigdy nie zadziałają. Zbudowałem więc cztery ulepszenia, które te wady kolejno usuwają. Dzięki nim Claude przestaje zżerać Twój czas, a zaczyna go pieniężyć. Nie ma przy tym znaczenia, czy budujesz aplikację, prowadzisz agencję czy doradzasz w zakresie AI — sprawdzi się przy każdej robocie w Claude Code.
Claude ma nawyki, które po cichu działają przeciwko Twoim celom — drobiazgi, którym zwykle nie poświęcamy drugiej myśli. Zastanów się, jak większość ludzi z niego korzysta: otwierasz, wpisujesz, czego chcesz, dostajesz odpowiedź — i zakładasz, że to najlepsza możliwa odpowiedź, bo Claude Code to jedno z czołowych narzędzi AI, a modele pod spodem, jak Opus, są bardzo zdolne. Łatwo więc zaufać temu, co mówi. Tymczasem w samej konstrukcji Claude’a siedzą błędy, przez które wyniki wychodzą gorsze, niż powinny.
Domyślnie Claude jest dostrojony tak, żebyś czuł się produktywny. Nie jest dostrojony do tego, żebyś zarabiał. A to dwie zupełnie różne sprawy. Każdy z tych błędów konstrukcyjnych kosztuje pieniądze, bo przychód zależy w gruncie rzeczy od dwóch rzeczy: od jakości tego, co produkujesz, i od tempa, w jakim to robisz. Im lepszy efekt i im szybciej gotowy, tym więcej zarobisz. Pewnie każdy pamięta momenty, w których Claude ewidentnie zachęcał do palenia tokenów, kłamał o funkcjach, które podobno zbudował, albo zmuszał do powtarzania w kółko tego samego. Dobra wiadomość: żeby to naprawić, nie trzeba przepisywać kodu Claude’a — wystarczą cztery ulepszenia. Zanim zacząłem ich używać, zdarzało mi się wypuszczać promocje, które kompletnie nie zagrały, automatyzacje padające po cichu oraz strony i aplikacje pełne błędów. I to w zasadzie cała historia. Aha — jeśli chcesz dostać prompty i skille z tego filmu, wszystkie są za darmo w mojej społeczności na School; link w opisie.
Ulepszenie 1. Rada, która potrafi powiedzieć „nie”
Pierwsza poprawka naprawia największą z wad: Claude zgadza się ze wszystkim, co powiesz. Zauważyliście, że gdy mówisz Claude’owi, co chcesz zrobić, niemal zawsze słyszysz w odpowiedzi: „Świetny pomysł, sprytnie wymyślone”? Chce się podobać. A co się dzieje, gdy nagle zmienisz zdanie? Znów: „Mądre posunięcie, dobrze, że zmieniłeś zdanie, pomysł jest coraz lepszy”. I z każdym pokoleniem modeli ten odruch się zaostrza.
To nie tylko moja obserwacja — jest udokumentowane. Badacze nazywają to sykofancją: eleganckie słowo na AI zachowujące się jak pochlebca. (Informacja dodatkowa: badanie „Elephant” analizowało, jak często modele nie podważają wątpliwych przesłanek użytkownika — właśnie tę skłonność do przytakowania opisuje się jako sykofancję.) Wyniki: modele przyjmują bez sprzeciwu ramy narzucone przez użytkownika w około 88 procentach przypadków; u ludzi wskaźnik wynosi około 60 procent. I robi się gorzej, im więcej model o Tobie wie — naukowcy z MIT i Penn State ustalili, że personalizacja i pamięć czynią model bardziej uległym w trakcie długiej rozmowy. To złośliwy paradoks: im dłużej i intensywniej pracujesz z modelem, czyli dokładnie to, co wszyscy powinniśmy robić, tym lepiej uczy się mówić Ci to, co chcesz usłyszeć.
Naprawa jest prosta: każ Claude’owi zaczynać od sprzeciwu — odgrywać adwokata diabła i podważać plan, zanim cokolwiek zbuduje albo cokolwiek zatwierdzi. Na tym polega mój skill /roast (skill, czyli rozszerzenie Claude Code wywoływane komendą z ukośnikiem). Wyciąga Claude’a z trybu przytakiwania i zmusza do wystawiania Twojego pomysłu — i własnej pracy — na próbę zamiast wszystko pieczętować. Roast zwołuje całą radę postaci, które atakują pomysł z różnych stron. Jest kontrarian, którego jedynym zadaniem jest szukanie wad zabójczych dla projektu. Ekspansjonista wypatruje największego zysku. Myśliciel pierwszych zasad działa w czystej logice, bez zewnętrznego kontekstu. Głęboki badacz faktycznie przeszukuje sieć i wyciąga realne dane rynkowe oraz ceny konkurencji. Kupujący wciela się w Twojego klienta i mówi wprost, czy da się go namówić na zakup. Na końcu sędzia zbiera wnioski i wydaje jeden werdykt: zielone światło, przebudowa albo kosz. Dostajesz też najtańszy test do przeprowadzenia w ciągu 48 godzin, który pokaże, czy pomysł w ogóle jest wart dalszej roboty — nawet jeśli rada zaleciła przebudowę.
Przez cały film będę budował jeden mały biznes od zera do końca, żeby widać było każdy krok na czymś realnym. Mój pomysł: narzędzie za 9 dolarów miesięcznie, które zamienia transkrypcję filmu z YouTube w posty na LinkedIn na cały tydzień. Otwieram więc Claude Code i przepuszczam ten pomysł przez roasta na żywo.
Na żywo: 9 dolarów za tydzień postów na LinkedIn
Jesteśmy w świeżym projekcie Claude Code. Widzę plik CLAUDE.md z minimalną zawartością — napisałem w nim tylko, że zadaniem Claude’a jest pomaganie nam w zarabianiu pieniędzy. Obok siedzi skill roast. Wpisuję /roast i krótko opisuję pomysł: „Narzędzie za 9 dolarów miesięcznie — użytkownik wrzuca link do filmu na YouTube, a transkrypcja zamienia się w tydzień postów na LinkedIn”. Wysyłam.
Zanim rada ruszy, Claude zadaje trzy pytania. Pierwsze: kto jest właściwym nabywcą tego narzędzia? Chcę na razie zostawić pole odpowiedzi możliwie szerokie i zobaczyć, co rada potrafi, więc piszę: „każdy, kto ma link do YouTube’a”. Drugie: na czym polega Twoja przewaga, co już masz w ręku? Odpowiadam szczerze: żadnej przewagi ani kanałów sprzedaży, ale potrafimy szybko budować z Claude Code. Trzecie: jakie ograniczenia i budżet — jak szybko potrzebny jest pierwszy dolar? „Mamy trochę zapasu, ale niewiele”. Wysyłam i czekam, aż rada się zbierze.
Zanim to się wydarzy, w drugiej sesji zadaję zwykłemu Claude’owi po prostu: „To mój pomysł. Jak myślisz, czy jest dobry? Czy zadziała? Czy zarobię?” — żeby potem porównać tę odpowiedź z werdyktem rady. Po chwili w pierwszej sesji rusza pięć podagentów: kontrarian, ekspansjonista i reszta ekipy. Wracam, jak skończą.
Werdykt: przebudować, przy bardzo wysokiej pewności. W jednym zdaniu: „Pogrzebcie produkt «9 dolarów: YouTube na posty LinkedIn» dokładnie w takiej formie. To darmowa usługa, dostępna bez logowania, zapakowana w abonament i skonstruowana tak, by generować masowy odpływ klientów. Ale zachowajcie silnik i skierujcie go na wąską, płacącą niszę, dodając dwie funkcje, które stanowią realną fosę: weryfikowalne dopasowanie do stylu autora oraz bezpośrednie planowe publikowanie”.
Dalej rada tłumaczy dlaczego. Największe ryzyka: brak fosy i darmowy substytut, brak dystrybucji i brak audytorium przy budżecie rzędu kilkuset dolarów. Koszt pozyskania klienta (CAC) przekroczy jego wartość życiową (LTV) 9 dolarów już pierwszego dnia, a dopracowany MVP trafi do jednocyfrowej liczby zapisów. Jest i spojrzenie z jasnej strony: największy możliwy zysk, ocena potencjału finansowego i najtańszy test na 48 godzin. Test brzmi tak: zanim napiszemy choć linijkę kodu, wybieramy jedną niszę, piszemy bezpośrednio do 20–30 osób i sprawdzamy, czy rynek w ogóle istnieje — czy ktoś jest gotów zapłacić. Wyniki cząstkowe: kontrarian dał 2/10, ekspansjonista 8/10, pozostali odpowiednio 3/10, 2/10 i 2/10. Wniosek nasuwa się sam: koncepcję trzeba przebudować.
A co na to zwykły Claude? Musiałem najpierw odpowiedzieć na kilka pytań, a potem nawet uruchomić sesję ponownie — bo bez prośby sam sięgnął po skilla roast (co akurat dobrze świadczi o jego sile). Po powtórce z zastrzeżeniem „nie używaj roasta” dostałem porządny spis wad i radę, żeby pomysł przerobić przed wypuszczeniem. Ale te wskazówki były o wiele bardziej ogólnikowe: zabrakło właściwych perspektyw i konkretnego planu, co zrobić, żeby to sprzedać. Co ciekawe, właśnie weszło Opus 4.8 i modele będą coraz lepsze, a producenci doskonale wiedzą o sykofancji i próbują ją opanować. Ale porównanie obu wyników pokazuje dobitnie, że rada o różnych kompetencjach i temperamentach da znacznie lepszą analizę decyzji biznesowej i podpowie, co robić, żeby zarabiać.
Tak działa roast. Nawet jeśli nie skorzystasz akurat z tego skilla, sama metoda — poddawanie każdego pomysłu próbie, dokładanie adwokata diabła, patrzenie z kilku perspektyw — to najlepszy sposób na dobre decyzje. I nie tylko te finansowe. To po prostu znakomity sposób rozmowy z Claude’em czy każdym innym modelem.
Ulepszenie 2. „Skończone” nie znaczy „działa”
Gdy Claude coś dla Ciebie zbuduje, prawie zawsze pomija jeden krok — i to ten, którego naprawa może zająć dni. Claude oddaje Ci coś, co wygląda na skończone, ale wyglądanie na skończone i faktyczne działanie to dwie różne rzeczy. To także zmierzony problem: badacze z NYU przejrzeli około 1600 programów wygenerowanych przez GitHuba Copilota (no dobrze, Copilot nie jest najlepszy, ale tak czy inaczej) — około 40 procent miało luki bezpieczeństwa. Najgorsze, że te błędy są bardzo łatwe do przeoczenia: często dowiadujesz się o nich dopiero, gdy coś wysypie się przed klientem albo, w najczarniejszym scenariuszu, na żywej prezentacji.
Pamiętam konkretny przypadek. Rozsyłaliśmy wiadomości do ludzi, którzy chcieli z nami pracować, a my nie mieliśmy miejsc — trzeba było ich poinformować. Do obsłużenia były setki osób. Agent, którego budowałem, zameldował, że wszystkie maile poszły. Dopiero cztery dni później, zaglądając w skrzynkę, zobaczyłem, że rozeszła się ledwie pierwsza ćwierć. Nie wiem do dziś, co się stało, bo agent twierdził z pełnym przekonaniem: „Wszystko wysłane, wszystko gra”. Nie tylko więc nie wykonał zadania — jeszcze o tym skłamał. W tamtej sytuacji szkoda była niewielka. Ale wyobraź sobie, że to nie jedna kampania mailowa, tylko ciemny kod, czyli kod, którego nie pisałeś: agent wysyła w świat funkcje, stawia automatyzacje. Jeśli przy tym kłamie albo robi to byle jak, firma może stracić mnóstwo pieniędzy.
Rozwiązanie: Claude ma sprawdzać własną pracę, zanim Ci ją odda — a potem jeszcze to, co Ci już oddał. Pomyśl o fabryce samochodów: każdy element testują osobno, a gdy całość złożą, testują ją jeszcze raz wielokrotnie. Właśnie tę metodologię chcemy przenieść do pracy z Claude’em. To ulepszenie różni się od pozostałych, bo nie mogę dać Ci gotowego skilla — to raczej metoda, zmiana nastawienia. Ma dwie części. Pierwsza to weryfikacja: zanim Claude cokolwiek odda, ma kontrolować swoją robotę w trakcie. Druga: gdy mówi „gotowe”, poddajecie wynik — wspólnie — testom wytrzymałościowym i szukacie przypadków brzegowych, o których żaden z Was nie pomyślał.
Jak dokładnie wygląda taka kontrola, zależy od tego, co budujesz — sprawdzanie strony docelowej to co innego niż sprawdzanie zmontowanego wideo albo potoku danych. Nie ma jednego magicznego przycisku; to nawęk, który wbudowujesz w sposób promptowania i myślenia o Claude Code. Pokażę więc praktykę: kazaliśmy Claude’owi zbudować stronę docelową z formularzem zapisu na listę oczekujących do naszej aplikacji. Ma ją zweryfikować zrzutami ekranu — obejrzeć tak, jak oglądałby ją żywy człowiek — a potem stres-testować: klikać w przyciski, wysyłać formularze seriami i próbować ją zepsuć.
Na żywo: strona, którą model sam obejrzał i próbował zepsuć
Rada zasugerowała, że zanim cokolwiek zbudujemy, napiszemy do ludzi i zbierzemy dowód zainteresowania. Potrzebujemy więc strony, na którą możemy ich skierować: pokazuje funkcje, markę, klimat — i ma formularz zapisu, żeby sprawdzić, czy ludzie rzeczywiście się zapisują. Mam przygotowany prompt; jest długi, więc przewijam go powoli — można zapauzować i przeczytać. Sedno: pętla weryfikacji. Zaraz po zbudowaniu strony nie wolno ufać, że „wygląda dobrze” — trzeba to sprawdzić samemu przez Playwright CLI. (Informacja dodatkowa: Playwright to narzędzie do automatyzacji przeglądarki — potrafi otwierać strony, klikać, wypełniać formularze i robić zrzuty ekranu.) Prompt każe uruchomić lokalny serwer, sfotografować każdą sekcję osobno, obejrzeć zdjęcia i w razie potrzeby wrócić z poprawkami. Pętla kręci się, aż każda sekcja będzie sfotografowana w dwóch widokach, nie widać błędów, a formularz listy oczekujących będzie wyglądał czysto. Na dole dopisałem definicję ukończenia.
Wklejam prompt i ruszamy. Oczywiście przy innej robocie pętla będzie wyglądać inaczej — tu akurat da się patrzeć i fotografować. Chodzi o zasadę: przy pierwszym strzle (mówi się „one-shot”) AI doprowadzi Cię może w 65 procentach drogi, a Twoim zadaniem jest recenzowanie, ocenianie, dokładanie smaku i kolejne rundy. A gdybyś mógł dostać 90 procent od razu i dopiero stamtąd iterować? Właśnie po to jest kontrola po drodze: Claude nie może się wykręcić byle czym i nie kończy, póki nie wręczy Ci czegoś do szybkiego przejrzenia i wysłania. Bo to czysta strata czasu, gdy dostajesz półprodukt i musisz sam wszystko przerabiać. Pomyśl o podwładnym: cenisz tego, który oddaje raport do jednego rzutu oka — wszystko się zgadza i wszystko jest prawdziwe. Nie tego, po którego każdym dokumencie trzeba maszerować z poprawkami.
Claude układa sobie listę zadań i kręci pętlę weryfikacji aż do zera błędów. Wracam po zakończeniu. Wszystko przeliczone od końca do końca — gotowe i zweryfikowane, nie tylko „oświadczone”. Dostaliśmy działający adres, zaraz go otworzymy. Claude zbudował jednostronicową, dopracowaną stronę zapisu na listę oczekujących dla Cadence, w osiemnastu — nie, w ośmiu sekcjach. Pętla weryfikacji faktycznie przeszła: Playwright sfotografował wszystkie sekcje. W folderze projektu, obok kodu, jest katalog ze zrzutami — jedenaście z pulpitu i jedenaście z telefonu. Można zajrzeć i zobaczyć stronę w każdym z widoków. Sam design jest dość sztampowy i „AI-owy”, ale to nie jest punkt tego ćwiczenia — punktem jest pętla. Z perspektywy projektowej moglibyśmy to obrandować i odebrać maszynowość.
Otwieramy witrynę. Sekcja funkcji Cadence, przycisk przewija do „jak to działa”, cennik, „dołącz do listy oczekujących” zjeżdża do formularza z pytaniami o liczbę obserwujących na LinkedIn czy roczny przychód. Przyciski działają. Wizualnie — poza tą generycznością — wszystko leży jak trzeba: nic nie wychodzi poza obszar, teksty czytelne, sekcje czyste, bez usterek i zacięć.
Da się pójść o krok dalej. Samokontrola to nie tylko sprawdzanie w trakcie budowania, ale też testy wytrzymałościowe. Formularza jeszcze nie ruszaliśmy. Mówię więc: „Świetnie. Teraz weź Playwright CLI, otwórz widoczną przeglądarkę i pokaż mi, że umiesz wysyłać formularze. Zrób wiele przejść z różnymi opcjami z list rozwijanych, różnymi typami e-maili i numerów telefonów — stres-test, żeby w wysyłaniu nie siedział żaden błąd”. Wyjaśnienie: przeglądarka „headed” to taka, którą widzisz; „headless” działa w tle i jej nie widać, choć robi to samo. I proszę: Claude otwiera kartę, wysyła formularz i masowo kombinuje — różne opcje z list, różne adresy, różne nazwiska. Backendu jeszcze nie mamy, to byłby kolejny etap, ale mechanizm widać. Zwróćcie uwagę: model próbował wetknąć spacje w dziwnych miejscach — na przykład przed adresem e-mail. I proszę, złapal błąd z niepoprawnym adresem. Jeszcze jeden. O to właśnie chodzi: wyławia przypadki, których sami byśmy nie wymyślili albo nie chcielibyśmy ręcznie przetestować. Kreatywność modelu klasy Opus plus sprawne ręce Claude Code — po takiej sesji wiemy, jakie dziwne rzeczy potrafi zrobić użytkownik.
Model dobrał wszystkie przypadki brzegowe i uznał, że na pierwsze podejście wystarczy. Wszystkie 22 testy przeszły; zebrał dowody, przejrzał udane i odrzucone wysłania i mówi, co poprawić. Wynik: osiem poprawnych zgłoszeń i czternaście wadliwych. Dwie uczciwe, nieblokujące uwagi: brak zabezpieczenia przed duplikatami — tym samym adresem można zapisać się dwa razy — oraz celowo pobłażliwa walidacja e-maila, sprawdzająca tylko strukturę (coś@domena), a nie to, czy skrzynka naprawdę istnieje. To dokładnie te drobiazgi, o których przy wstępnej budowie bym nie pomyślał. Bardzo pomocne.
Ulepszenie 3. Długa rozmowa ogłupia Claude’a
Pierwsze dwa ulepszenia działają na każdy wynik, jaki oddaje Claude. Ale żeby wynik w ogóle powstał, trzeba doprowadzić robotę do końca — a ludzie zwalniają najczęściej nie przez to, co robią z Claude’em, tylko dlatego, że w pewnym momencie uderzają w ścianę. Rozmowa puchnie, Claude zwalnia i robi się gorszy, wżera się w limit użycia i zachowuje się, jakby nic nie pamiętał. I znowu: jest na to badanie. Zjawisko nazwano „context rot” — dosłownie „zepsucie kontekstu”. Badacze sprawdzili osiemnaście czołowych modeli, Claude’a włącznie, i każdy radzi sobie tym gorzej, im dłuższa rozmowa. Nawet przy bardzo prostych zadaniach jakość leci w dół i mnożą się halucynacje. Największy problem: spadek zaczyna się na długo, zanim okno kontekstowe się zapełni. Więcej nie znaczy lepiej — dłuższa rozmowa dosłownie ogłupia Claude’a.
Wyobraź sobie okno kontekstu jako biurko: gdy leży na nim sterta papierów, znalezienie jednego konkretnego dokumentu trwa wieki. Do tego dochodzi druga sprawa: jeśli nie pracujesz na najlepszej wersji Claude’a — najzdolniejszym modelu, powiedzmy Opusie 4.8 — projekt będzie gorszy, kod bardziej lejący, a nawet weryfikacja i stres-testy wyjdą słabiej. O tym, czy zarobisz z Claude’em, po cichu decydują więc dwie rzeczy: zarządzanie kontekstem i dobór właściwego modelu do właściwego zadania.
Naprawa polega na pilnowaniu kontekstu. Brzmi banalnie, ale trzeba to trzymać na uwadze, zanim po cichu nie zniszczy efektów pracy. Warto znać kilka komend. /context pokazuje, co dokładnie zjada okno kontekstowe. /clear czyści wszystko do zera. A zamiast /compact, który zagęszcza rozmowę, żeby móc iść dalej, używam własnego skilla: /session-handoff. Zanim cokolwiek wyczyszczę, odpalam session handoff — pisze mi streszczenie tego, co ważne: nad czym pracujemy, kluczowe pliki (te wyprodukowane i te z informacjami), otwarte decyzje oraz punkt, w którym mamy wznowić. Kopiuję podsumowanie, czyszczę kontekst, wklejam do świeżej sesji — i siedzę w kompletnie czystym oknie, ale kontynuuję dokładnie tam, gdzie skończyłem, bez poczucia straty.
Pokażę, na co zwracać uwagę. Pracuję w wersji terminalowej; na dolnym pasku mam status, w którym przez całą sesję widzę model, rozmiar okna kontekstowego, poziom staranności oraz wskaźnik zapełnienia. Teraz 12 procent, czyli około 125 tysięcy tokenów z miliona. Staram się nie przekraczać ćwierci miliona — gdy tylko wskaźnik ją przeskoczy, zaczynam nową sesję.
Komenda /context wizualizuje skład sesji: serwery MCP (zewnętrzne narzędzia podpięte do Claude’a — na szczęście ładowane na żądanie, więc tokenów tu nie palą, ale gdyby były załadowane, zjadłyby mnóstwo), wolna przestrzeń, skille, pliki pamięci, narzędzia i zachęty systemowe — każda pozycja z przybliżoną liczbą tokenów. Przydaje się do sprzątania projektu, żeby nie zaczynać sesji z już obciążonym oknem. Narzędzie podpowiada też oszczędności: same wyniki odczytów ważą 490 tysięcy tokenów, czyli 49 procent — do odzyskania jest około 140 tysięcy. Można sięgnąć po /compact albo autokompaktowanie Claude Code, ale rzadko to robię — trwa za długo. Dlatego właśnie powstał session handoff.
A tak wygląda jego wynik: skąd zaczęliśmy, decyzje zamknięte, co wysłano, kluczowe pliki, stan bieżący, weryfikacja, tematy odroczone i otwarte pytania oraz „wznów tutaj”. Kopiuję wszystko przez /copy, daję /clear — okno kontekstu spada do zera — i wklejam podsumowanie. Projekt ma dokładnie ten kontekst, w którym pracowałem: zna pliki, wie, gdzie patrzeć, wie, co robimy i od czego zacząć. Czasem Claude sam potwierdza: „Mam przekazanie stanu. Szybko zweryfikuję bieżącą sytuację, zanim zaproponuję następny krok”. Takie podsumowanie można też przenieść do innego narzędzia — innego modelu, choćby Codexa. Niezwykle wygodne.
Ulepszenie 4. Podagenty i /goal, czyli koniec wąskiego gardła
Ostatnie ulepszenie sprawia, że w jeden dzień nadrobisz więcej niż inni w tydzień. Niezależnie od jakości promptów istnieje jeden twardy limit: możesz kierować Claude’em w zasadzie tylko w jedną stronę naraz, bo to Ty jesteś wąskim gardłem — decydentem i recenzentem. Zespół inżynierów Anthropic przetestował to wprost: agent prowadzący, koordynujący drużynę małych podagentów pracujących równolegle, kontra pojedynczy agent robiący całość samodzielnie. Drużyna wypadła na ich wewnętrznej ewaluacji badawczej ponad 90 procent lepiej.
Dla porządku: podagent to osobna instancja Claude’a z własnym zadaniem i własnym, czystym oknem kontekstu. Pracuje samodzielnie i melduje do głównej sesji. Zamiast jednego pracownika robiącego wszystko krok po kroku masz ekipę, w której każdy jednocześnie robi jedną rzecz. Przy planowaniu filmu na YouTube puszczam na przykład jednego agenta do researchu jednego tematu, drugiego do innego, a trzeciego do lektury komentarzy pod poprzednimi materiałami. Zasada jest jedna: wszystko, co da się robić równolegle i niezależnie, deleguję na podagentów; potem składam wyniki w całość i robię z nimi, co trzeba.
Dokładam do tego jeszcze jedną rzecz, po której czuje się, że przyszłość już jest: komendę /goal. Ustala się metę — realny warunek ukończenia — a Claude pracuje tura po turze, tak długo, aż warunek zostanie spełniony. Najciekawsze, że o ukończeniu nie decyduje sam wykonawca: osobny ewaluator, drugi model, sprawdza co turę, czy „done = true”. Przypomnijmy problem z ulepszenia pierwszego: Claude zbyt łatwo zgadzał się sam ze sobą i z Tobą. Tu wykonawcę i sędziego rozdzielono na dwa byty.
Na żywo: materiały wejścia na rynek w osiem minut
Ostatni krok spina wszystkie ulepszenia z filmu w jeden test. Pomysł zweryfikował roast; przed ogłoszeniem „gotowe” model sprawdza własną pracę (metoda z ulepszenia drugiego); rusza ekipa podagentów, każdy w czystym kontekście, więc nikt nie uderza w ścianę psującego się kontekstu; a /goal doprowadza całość do mety. Przed chwilą ustawiłem przekazanie sesji — teraz składamy wszystko w całość.
Wpisuję /goal („ustaw cel, pracuj do spełnienia warunku”) i wklejam prompt. Cel: kompletny, gotowy do wykonania zestaw materiałów wejścia na rynek dla naszego produktu, zapisany w projekcie. Wewnątrz celu puszczamy podagenty równolegle — po jednym na każdy z sześciu rezultatów, każdy z własnym kontekstem, każdy pisze do innych plików, żeby nic się nie nadpisało. I proszę zwrócić uwagę na koniec promptu: zdefiniowałem, kiedy zadanie jest ukończone. Wszystkie sześć plików istnieje i żaden nie jest pusty. Badanie rynku zawiera co najmniej sześciu konkurentów. Personalizowanych szkiców jest 25. Im obiektywniejszy warunek, tym lepiej to działa, bo inaczej model będzie kręcił się w kółko, dopóki sam nie uzna, że spełnił cel. Jest tam też polecenie: „gdy podagenty skończą, przeprowadź własny przebieg weryfikacyjny — otwórz każdy plik, sprawdź, czy trzyma poziom, i dopracuj wszystko chude albo ogólnikowe, zanim ogłosisz się skończonym”.
Całość działa teraz w tle — w rogu widać „cel aktywny” i licznik czasu, a na końcu „cel osiągnięty” — a ja mogę odejść od biurka i zająć się czym innym. Wynik: zadanie zakończone po około ośmiu minutach. Samo /goal nie musi oznaczać godzinnych maratonów — używam go często i większość moich przebiegów trwa niecałe 20–30 minut, bo prompt jest jasny i mam większą pewność, że meta zostanie osiągnięta. W osiem minut dostaliśmy sześć plików — pamiętając, że sześciu podagentów pracowało nad nimi niezależnie i równolegle, stąd ta szybkość. Wszystko zweryfikowane. Do nas zostaje przejrzenie pozycjonowania, badania rynku, planu wejścia na rynek, szablonów kontaktu, personalizowanych szkiców i kalendarza treści. A ponieważ wszystkie ulepszenia spięto w pętlę, jesteśmy w świetnym miejscu, żeby zacząć działać.
Pomyślmy: dzisiejsze demonstracje zajęły mi łącznie niecałą godzinę. Ktoś, kto chciałby faktycznie wystartować z takim biznesem, włoży więcej niż godzinę — ale wyobraź sobie tydzień skupionej pracy z tymi metodami: pomysł, budowa i do tego kompletny plan wejścia na rynek. Gdzie można dojść? I jak przy okazji odhaczysz robotę, na którą potrzebna byłaby dziesiątka ludzi i więcej czasu.
Co konkretnie dostaliśmy? W pozycjonowaniu: profil idealnego klienta (ICP), dwa segmenty, ofertę rdzenną, drabinkę pakietów — ceny zablokowane na 19, 39 i 99 dolarów miesięcznie — logikę przechodzenia między pakietami, jednozdaniową propozycję wartości i trzy najcięższe zarzuty z gotowymi ripostami: „za rzadko publikuję na LinkedIn, żeby to się opłacało”, „posty pisane przez AI brzmią sztucznie i zaszkodzą mojej marce”. Na każdy jest solidna odpowiedź. Wszystko można jeszcze przejść i ożywić własnym dotykiem. W badaniu rynku: produkt, wąskie wejście na rynek (tzw. wedge), profil klienta, konkurencja — znalazło się siedmiu konkurentów przy wymaganych sześciu — plus rozwiązania sąsiednie, pełna tabela porównawcza, miejsce Cadence na mapie rynku i argument, dlaczego 19 dolarów to właściwa cena wejścia. Źródła są podlinkowane, poziom naprawdę głęboki. Dalej czternastodniowy plan wejścia na rynek, którego się po prostu trzyma, szablony kontaktu i kalendarz treści.
I to jest cała filozofia: podagenty, cele, automatyzacje — po to, żebyś przestał być wąskim gardłem. Zmieniasz się z budowniczego i producenta w tego, kto rozwiązuje problemy, decyduje, recenzuje i sądzi. Tak należy wykorzystywać tę technologię, żeby rozwijać biznes i zarabiać więcej.
Cztery ulepszenia w pigułce
Przestań pozwalać Claude’owi zgadzać się ze wszystkim — a zbudujesz właściwą rzecz. Każ mu sprawdzać własną pracę — a wypuścisz w świat rzeczy, które działają. Pilnuj kontekstu — a Claude pozostanie bystry. I przestań być wąskim gardłem: używaj podagentów i /goal, żeby roboty szły bez Ciebie. Od teraz możesz te ulepszenia wykorzystywać, żeby zarabiać z Claude’em więcej.
Wszystko, o czym mówiłem, jest za darmo w mojej społeczności na School — znajdziesz tam też setki darmowych materiałów i kursów oraz ponad 400 tysięcy osób budujących z Claude’em. (Informacja dodatkowa: School to platforma społeczności kursowych, na której twórcy prowadzą darmowe i płatne grupy.) Jeśli chcesz wejść głębiej i stawiać biznes na AI, dołącz do społeczności Plus, gdzie co tydzień spotykamy się na rozmowach i odpowiadamy na pytania. Linki do obu społeczności są w opisie. Dziękuję, że dotarliście do końca — do zobaczenia w następnym materiale.