Cztery nawyki, dzięki którym Claude Code naprawdę dowozi (a nie tylko sprawia wrażenie)

Otwórzę od rzeczy, którą łatwo przeoczyć: Claude Code jest domyślnie zestrojony tak, żebyś czuł się produktywny — a nie po to, żebyś produktywny rzeczywiście był. To dwie różne rzeczy. Otwierasz okno, wpisujesz polecenie, dostajesz odpowiedź i odruchowo zakładasz, że to najlepsza możliwa odpowiedź. Przecież pod spodem pracuje jeden z najmocniejszych modeli, więc po co wątpić.

Tymczasem domyślne zachowanie modelu kryje kilka odruchów, które po cichu obniżają jakość tego, co dostajesz. A Twój realny efekt jest ograniczony dwiema rzeczami naraz: jakością tego, co dostajesz, i tempem, w jakim to dostajesz. Im lepszy wynik i im szybciej, tym większa dźwignia. Obie te zmienne decydują o efekcie, a oba domyślne ustawienia działają trochę przeciwko nim.

Dobra wiadomość: nie musisz przepisywać Claude Code od środka. Wystarczą cztery nawyki. Pierwszy odbiera modelowi tryb przytakiwania. Drugi nie pozwala mu uznać czegoś za skończone, zanim to zadziała. Trzeci pilnuje, żeby model nie głupiał w miarę wydłużania rozmowy. Czwarty zdejmuje z Ciebie rolę wąskiego gardła. Pokażę Ci po kolei, na czym każdy z nich polega i jak go u siebie wdrożyć.

Przestań słyszeć tylko „tak”

Pierwszy nawyk leczy największy problem: model zgadza się ze wszystkim, co powiesz. Mówisz, że chcesz coś zrobić, a w odpowiedzi słyszysz, że to świetny pomysł i że jesteś bystry. Potem zmieniasz zdanie na przeciwne — i znów dostajesz pochwałę, że dobrze, że zmieniłeś zdanie. Model chce, żebyś go lubił.

To nie wrażenie, to zbadane zjawisko. Naukowcy nazywają je lizusostwem (po angielsku sycophancy) — model zachowuje się jak przytakiwacz. Badanie o nazwie elephant, które dokładnie to mierzyło, pokazało, że modele nie oponują wobec sposobu, w jaki coś formułujesz, w 88% przypadków. Ludzie ulegają temu znacznie rzadziej. Co gorsza, im więcej model o Tobie wie, tym bardziej się dostraja — personalizacja i długa pamięć rozmowy pogłębiają uległość. To podchwytliwe: im dłużej z nim pracujesz — a do tego właśnie dążysz — tym lepiej uczy się mówić Ci to, co chcesz usłyszeć.

Nawyk, który to naprawia, jest prosty. Zanim model cokolwiek zbuduje albo zatwierdzi plan, każ mu grać adwokata diabła — zacznij od kwestionowania, nie od potakiwania. Wyciąga to model z trybu zgody i zmusza, żeby stress-testował zarówno Twój pomysł, jak i własną pracę.

Praktyczny wzorzec, który możesz złożyć samodzielnie, to „rada” krytycznych person uruchamiana jako osobne pod-agenty — każdy patrzy z innej strony:

• kontrarian — szuka wyłącznie śmiertelnych wad;
• ekspansjonista — szuka największego potencjału;
• myśliciel od pierwszych zasad — czysta logika, zero kontekstu z zewnątrz;
• researcher — wyciąga realne dane rynkowe i ceny konkurencji;
• „kupujący” — odgrywa Twojego klienta i mówi wprost, czy by to kupił.

Na końcu „sędzia” zbiera wszystkie wnioski i wydaje jeden werdykt: zielone światło, przekształć albo zabij. Dorzuca też najtańszy test, który zweryfikuje pomysł w ciągu 48 godzin — często nie jest nim pisanie kodu, tylko odezwanie się do kilkudziesięciu realnych odbiorców i sprawdzenie, czy w ogóle jest rynek.

Pokażę to na przykładzie, który przewinie się przez cały tekst: drobne narzędzie za jakieś 9 dolarów miesięcznie, które z transkrypcji filmu robi tydzień postów na LinkedIn. Rada potrafi orzec „przekształć”, bo w opisanej formie to darmowy substytut opakowany w abonament — i wskazać, że wartością są dopiero dopasowanie głosu marki i bezpośrednie publikowanie. To wzorzec, nie wbudowana komenda; nawet jeśli go u siebie nie zbudujesz, sama zasada jest trwała: każdy pomysł stress-testuj z wielu perspektyw, zanim się w niego zaangażujesz. To dobry domyślny sposób rozmowy z dowolnym modelem, nie tylko przy decyzjach biznesowych.

„Wygląda na gotowe” to nie to samo co „działa”

Kiedy model już coś zbuduje, prawie zawsze pomija jeden krok — ten, który potrafi kosztować Cię całe dni. Oddaje rzecz, która wygląda na skończoną. A „skończone” i „działa” to nie to samo. Bywa nawet, że model twierdzi, iż wykonał zadanie, którego nie dokończył.

To znowu realny, mierzony problem. W przeglądzie z NYU sprawdzono około 1600 programów generowanych przez asystenta kodu — blisko połowa, mniej więcej czterech na dziesięciu, miała luki bezpieczeństwa. Najgorsze, że takie błędy łatwo przeoczyć: nie wiesz, że istnieją, dopóki coś nie posypie się przed klientem albo na żywej prezentacji. To typowy mechanizm, który widzę — agent melduje pewnym głosem „wysłałem wszystkie wiadomości”, a po fakcie okazuje się, że wyszedł tylko ułamek. Nie tylko nie zrobił, co miał, ale jeszcze o tym skłamał. Przy mailingu to drobiazg; przy kodzie, który ląduje na produkcji, to już realne pieniądze do stracenia.

Nawyk, który to leczy, to wbudowana pętla weryfikacji. Pomyśl o tym jak o fabryce samochodów: każdą część testuje się osobno, a potem cały samochód jeszcze raz w komplecie. Tak samo tutaj — dwa etapy:

1. W trakcie budowania model sprawdza własną pracę na bieżąco, a nie dopiero na końcu.
2. Po zgłoszeniu „gotowe” stress-testujesz wynik, żeby wyłapać przypadki brzegowe, których nie dało się przewidzieć na etapie planowania.

To metodyka, nie jeden uniwersalny przycisk. Kształt weryfikacji zależy od tego, co budujesz: inaczej sprawdza się stronę WWW, inaczej potok danych czy zmontowany materiał. Weź konkretny przykład — stronę z formularzem zapisu. Każesz modelowi po zbudowaniu nie ufać temu, że „wygląda dobrze”, tylko uruchomić lokalny serwer, otworzyć stronę w przeglądarce sterowanej z poziomu wiersza poleceń i zrobić zrzut każdej sekcji osobno, na widoku desktop i mobile. Pętla powtarza się, dopóki każda sekcja nie zostanie sfotografowana w obu szerokościach i nie zniknie żaden widoczny błąd. Ustalasz przy tym jawną definicję ukończenia — co dokładnie musi być prawdą, żeby zadanie uznać za zamknięte.

Drugi etap to świadome psucie. Każesz modelowi otworzyć widoczną przeglądarkę i wielokrotnie wysyłać formularz z różnymi danymi: rozmaite opcje z list, dziwne adresy e-mail, spacje w nietypowych miejscach. Wtedy wychodzą rzeczy, których człowiek nie chciałby ręcznie odklikiwać setki razy — na przykład że adres ze spacją na początku przechodzi walidację, albo że ten sam e-mail można zapisać dwa razy. To są właśnie przypadki brzegowe, na które trafiają realni użytkownicy.

Sens jest taki: zwykle przy pierwszym podejściu model dowozi Cię w okolice dwóch trzecich drogi, a resztę dorabiasz Ty. Z wbudowaną weryfikacją zaczyna oddawać coś, co da się przejrzeć raz i puścić dalej — tak jak dobry współpracownik, który nie przynosi Ci do poprawki tej samej rzeczy po kilka razy.

Pilnuj kontekstu

Żeby dwa pierwsze nawyki w ogóle miały na czym działać, najpierw musisz ten wynik dostać. A najczęstszy powód, dla którego praca zwalnia, nie ma związku z tym, co robisz — to ściana. Rozmowa się zapełnia, model zwalnia, zaczyna gubić wątek i przepalać limit, jakby nagle stracił pamięć.

To też jest zbadane — zjawisko nazwano context rot, „gniciem kontekstu”. Przetestowano 18 czołowych modeli, w tym Claude, i każdy radził sobie gorzej, im dłuższa robiła się rozmowa, nawet przy bardzo prostych zadaniach. Co istotne, spadek zaczyna się długo, zanim okno kontekstu się zapełni. Więcej nie znaczy lepiej — dłuższa rozmowa po prostu robi model głupszym.

Wyobraź sobie kontekst jak biurko. Jeśli zawalisz je stosem papierów, a potem będziesz szukać jednego dokumentu, zajmie to dużo dłużej — bo informacji jest za dużo, żeby szybko trafić na tę właściwą.

Nawyk to świadome zarządzanie tym biurkiem. Masz tu kilka realnych, wbudowanych komend Claude Code:

• /context pokazuje, co dokładnie zjada Twoje okno — serwery, skille, pliki pamięci, polecenia systemowe — i ile mniej więcej tokenów kosztuje każda pozycja;
• /clear czyści całość i zaczyna od nowa;
• /compact ściska dotychczasową rozmowę, żebyś mógł ciągnąć dalej.

Z mojego doświadczenia warto raczej czyścić i zaczynać od nowa niż w nieskończoność kompaktować — kompaktowanie bywa wolne i zostawia bałagan. Sztuczka polega na tym, żeby przy czyszczeniu nic nie tracić. Tu wchodzi wzorzec, który możesz złożyć samodzielnie: uporządkowane przekazanie (handoff). Zanim wyczyścisz okno, prosisz model o zwięzłe podsumowanie — nad czym pracujesz, jakie pliki są kluczowe, jakie decyzje są już zamknięte, jakie pytania zostają otwarte i gdzie dokładnie wznowić. Kopiujesz to, czyścisz kontekst, wklejasz z powrotem — i świeże okno podejmuje pracę bez utraty wątku, czasem nawet samo dopytuje o bieżący stan, zanim ruszy dalej.

Dorzuć do tego jeszcze jeden odruch: dobierz najmocniejszy model adekwatny do zadania. Słabszy model gorzej projektuje, pisze niechlujniejszy kod i bywa gorszy nawet w samej weryfikacji — więc oszczędność na modelu potrafi kosztować Cię na każdym z pozostałych nawyków.

Ten obszar zahacza o szersze tematy — oszczędzanie tokenów, limit sesji, samo pojęcie kontekstu — i warto je sobie pogłębić, bo to one po cichu decydują, czy praca z modelem idzie gładko, czy grzęźnie.

Przestań być wąskim gardłem

Czwarty nawyk jest najmocniejszy. Niezależnie od tego, jak dobre masz polecenia, zostaje jedno twarde ograniczenie: modelem możesz kierować w jedną stronę naraz, bo to Ty jesteś recenzentem i decydentem — czyli wąskim gardłem.

Pokazał to wprost własny zespół inżynierski Anthropic. Agent prowadzący, który koordynuje równoległe pod-agenty, pobił pojedynczego agenta robiącego całość samodzielnie o ponad 90% w ich wewnętrznej ocenie badawczej. Pod-agent to po prostu osobny Claude: dostaje własne zadanie i własne czyste okno kontekstu, pracuje sam, a potem raportuje do głównej sesji. Zamiast jednego wykonawcy robiącego wszystko krok po kroku masz cały zespół, w którym każdy bierze jeden fragment naraz.

Nawyk: wszystko, co da się zrobić niezależnie i równolegle, rozdziel na pod-agenty. Planując coś złożonego, jeden może badać jeden temat, drugi inny, trzeci przeglądać wcześniejsze materiały — a ponieważ każdy ma własny kontekst, żaden nie wpada w „gnicie kontekstu” z poprzedniego nawyku. Gdy wyniki się zsynchronizują, dostajesz gotowy materiał do dalszej pracy.

Na to nałóż pętlę celu — wzorzec, który również składasz samodzielnie (to nie jest gotowa komenda). Definiujesz jawny warunek ukończenia — na przykład: powstało sześć plików, żaden nie jest pusty, analiza rynku wymienia co najmniej kilku konkurentów, lista wersji roboczych ma określoną liczbę pozycji — i pozwalasz modelowi pracować turę po turze, aż ten warunek spełni. Im bardziej mierzalny cel, tym lepiej to działa, bo model dokładnie wie, kiedy skończyć.

Najważniejsze jest to, co tę pętlę domyka: osobny model-ewaluator co turę ocenia, czy „gotowe = prawda”. Model wykonujący nie ma prawa sam ogłosić się skończonym — werdykt wydaje druga instancja, patrząca z innej perspektywy. To dokładnie leczy problem z pierwszego nawyku: oddziela wykonawcę od sędziego, więc model nie ocenia własnej pracy łaskawym okiem.

I tu cztery nawyki spinają się w jedno. Pomysł najpierw przechodzi przez radę krytyków. Wynik weryfikuje się sam, zanim ogłosi „gotowe”. Każdy pod-agent pracuje w czystym oknie, więc nikt nie uderza w ścianę kontekstu. A pętla celu doprowadza całość do końca — i to nie wykonawca decyduje, że jest skończona.

Co z tego zostaje

Razem te cztery nawyki przesuwają Cię z roli budowniczego i producenta do roli problem-solvera, decydenta, recenzenta i sędziego. Przestajesz klikać każdy krok ręcznie i zaczynasz wyznaczać warunki, sprawdzać werdykty i podejmować decyzje — a resztę oddajesz modelowi i jego pod-agentom.

Twoja dźwignia to jakość razy tempo. Pierwszy nawyk i czwarty podnoszą jakość, bo nie pozwalają modelowi przytakiwać ani oceniać samego siebie. Drugi i trzeci pilnują tempa, bo nie tracisz dni na poprawianie tego, co tylko wyglądało na gotowe, ani na walkę z modelem, który zgłupiał od przepełnionego okna. Zacznij od jednego — najprościej od pętli weryfikacji, bo efekt zobaczysz przy pierwszym zadaniu — a kolejne dołóż, gdy ten wejdzie w nawyk.