11 Tiny Coding Agent Fixes With A Stupid Amount Of Payoff

O czym jest ten film

1. Zbiór 11 uniwersalnych porad do agentów kodujących — działają w Claude Code, Codexie i każdym innym narzędziu, bez przewracania dotychczasowego procesu pracy do góry nogami.
2. Piszesz dla agenta, nie dla człowieka: konkretne ścieżki, liczby i polecenia zamiast ogólników, bo każdy niedopowiedziony szczegół agent musi założyć — a założenia to prosta droga do błędów.
3. Reguły się dezaktualizują („dryf reguł”): w przywołanym badaniu co czwarte repozytorium z regułami dla AI zawiera wpisy wskazujące na nieistniejące już pliki czy bazy danych; ratunkiem jest okresowy audyt.
4. Polecenie /compact gubi około 90% szczegółów rozmowy — zamiast kompresji lepiej dawać agentowi mniejsze porcje pracy albo przechodzić do nowej sesji z dokumentem przekazania.
5. Reguły nie dają gwarancji wykonania — wszystko, co musi wydarzyć się za każdym razem (np. uruchomienie testów), warto przenieść do hooka, który odpala się deterministycznie.
6. W kontekście mniej znaczy więcej: nadmiar reguł szkodzi; Anthropic zaleca pilnowanie się poniżej 200 linii, a w globalnych plikach zostawiać wyłącznie specyfikę projektu.
7. Równoległe sub-agenty pochłaniają limity — u autora 39% tygodniowego zużycia przypadło na sesje z czterema i większą liczbą wątków naraz; polecenie /usage pozwala to wychwycić.
8. Nie warto podmieniać modelu w środku zadania: rozmowa nazbierawszy błędów jest „skażona” i mocniejszy model tego nie odkręci — lepiej zamknąć sesję i kontynuować w nowej.
9. Skomplikowane „koordynatory” agentów (lider zespołu, wspólne skrzynki zadań) są zawodne; niezawodniejsze jest proste delegowanie z poziomu jednego głównego agenta. Do tego: wykonawca nie powinien zatwierdzać własnej pracy.
10. Nadmierne iteracje pogarszają kod (w badaniu w 85% przypadków wcześniejsza wersja była lepsza), a walidacja powinna być systemem planowanym przed napisaniem pierwszej linijki.

Redakcyjne tłumaczenie

Wstęp: małe triki, wielka różnica

Przez cały czas pracy inżynierskiej z agentami kodującymi — także przed erą generatywnej AI — przekonałem się, że najcenniejsze wskazówki rzadko przybierają formę wielkich przewrotów. To zwykle proste triki, które przy drobnym nakładzie dają nieproporcjonalnie dużą korzyść. Żeby agent pracował lepiej, nie trzeba wyrzucać do kosza całego dotychczasowego sposobu pracy ani radykalnie zmieniać sposobu, w jaki się go używa. Podejrzewam, że takich obietnic słuchacie już do znudzenia.

Zamiast tego mam dla was 11 trików na zwiększenie niezawodności agentów kodujących — rzeczy, które wystarczy zapamiętać albo wprowadzić drobną korektą w codziennej rutynie. Nie proszę o rezygnację z czegokolwiek. Sam korzystam z nich na co dzień i robią dla mnie ogromną różnicę. Jeśli choć kilka okaże się dla was nowością — to już spory zysk.

Chcę, żeby materiał był zwięzły: na każdą strategię poświęcę dosłownie minutę lub dwie. Każdy z tych punktów zresztą nadawałby się na osobny film, więc dajcie znać w komentarzach, który warto rozwinąć.

Dwie uwagi na start. Po pierwsze, wszystko, o czym mówimy, działa niezależnie od agenta, którego używacie — do pokazów posłużę się Claude Code, ale zasady są uniwersalne. Po drugie, część trików być może już stosujecie. Świetnie — jest jednak spora szansa, że choć kilka pokaże wam nowe spojrzenie. Materiał sprawdzi się zarówno u osób zaczynających przygodę z asystentami kodowania, jak i u tych z wyrobionym procesem pracy.

1.Pisz dla agenta, nie dla człowieka

Pierwsza porada jest najoczywistsza — i najlepiej prowadzi do następnej: piszcie dla agenta, a nie dla człowieka. Agent potrzebuje konkretu i nie wolno zostawiać mu pola do domysłów. Powtarzam to często na kanale: planując pracę z agentem, macie przede wszystkim ograniczać liczbę założeń, które musi przyjąć samodzielnie. Dotyczy to również reguł — globalnych i wszelkiego innego kontekstu, jaki mu przekazujecie.

Porozumiewanie się z agentem różni się fundamentalnie od pisania dokumentacji dla ludzi. Między ludźmi możemy pozwolić sobie na ogólniki — i to dobrze, bo taka informacja pasuje do wielu sytuacji i wolniej się starzeje. Przykład: „Ogólnie staramy się trzymać kod dostępu do bazy danych w sensownym porządku” plus dwa zdania wyjaśnień — każdy inżynier w organizacji zrozumie, jak to przełożyć na swój projekt.

Do agenta nie możemy jednak mówić tak wysokopoziomowo. Trzeba po prostu wprost: „Cały kod SQL musi leżeć w katalogu database”. Przykład wydaje się banalny, ale oddaje sedno: ścieżki plików, liczby i polecenia do wykonania formułujemy bezpośrednio. Taka informacja szybciej się dezaktualizuje — co prowadzi prosto do drugiego punktu — ale dla agenta jest niezbędna. Chodzi o świadomy wysiłek: zamiast ogólnych rad zadawać sobie pytanie, jak opisać rzecz tak, żeby agent nie musiał zgadywać.

2.Pliki reguł się dezaktualizują

Właśnie dlatego, że jesteśmy wobec agentów tak konkretni, w plikach reguł zbierają się polecenia i ścieżki, które przestają odpowiadać rzeczywistości — kod ewoluuje, zmienia się architektura. A nic tak nie dezorientuje agenta jak reguła opisująca stan projektu sprzed miesięcy: agent usiłuje pogodzić zasady z tym, co zastaje w repozytorium, i nie rozumie, czemu się rozjeżdżają. Wszystko, co trafia do CLAUDE.md, globalnych reguł czy innego kontekstu, musi odzwierciedlać aktualny stan kodu.

(Informacja dodatkowa: CLAUDE.md to umieszczany w repozytorium plik z instrukcjami dla agenta Claude Code.)

W opisie filmu podlinkowuję omawiane badania; w jednym z nich wyszło, że co czwarte repozytorium mające warstwę reguł dla AI zawiera reguły nieaktualne. Kod poszedł do przodu: reguła wskazuje plik albo katalog dawno usunięte, bazę danych zastąpiono czymś innym, foldery przemianowano i przeniesiono — a instrukcje zostały bez zmian. Nazywam to zjawisko dryfem reguł i trzeba go unikać jak ognia.

I nie martwcie się, mam na to sposób: w osobnym materiale pokazuję swoje repozytorium skillów — zestawów procedur dla agentów, których używam codziennie. Jedna z nich to właśnie kontrola dryfu reguł: wystarczy ją uruchomić, a agent przeprowadzi audyt i wyłapie wszelkie rozbieżności między regułami a faktyczną zawartością kodu. Wystarczy robić taki przegląd od czasu do czasu, a oszczędzicie sobie mnóstwa nerwów.

(Informacja dodatkowa: skill to w tym kontekście gotowa, wielokrotnego użytku procedura, którą agent wykonuje na polecenie.)

3./compact nie jest warte zachodu

Niemal każdy agent ma funkcję w stylu polecenia /compact: rozmowę, która spuchła, spłaszcza się do krótkiego podsumowania, żeby odzyskać miejsce w oknie kontekstu i móc kontynuować w tej samej sesji. Problem w tym, że oddajecie wtedy agentowi decyzję, co jest ważne — a to prosta droga do halucynacji. W przywołanym badaniu w takim streszczeniu przetrwało ledwie około 10% szczegółów pełnej rozmowy. I trudno się dziwić: ściskając materiał w ten sposób, nie da się zachować wszystkiego.

Możecie to sprawdzić sami: w Claude Code wykonajcie /compact na istniejącej rozmowie, a potem dopytajcie o drobne, techniczne detale z jej wcześniejszej części. Agent zawiedzie na całej linii — zwykle sam przyzna, że sporo informacji przepadło.

Moja rekomendacja: zrezygnować z /compact całkowicie. Dawajcie agentom mniejsze porcje pracy, żeby w ogóle nie dochodziło do potrzeby kompresji. A jeśli rozmowa już rozrosła się za bardzo, przygotujcie dokument przekazania — krótkie podsumowanie tego, co zrobiono i co zostało — i zacznijcie nową sesję. Bo /compact to w gruncie rzeczy też dokument przekazania, tyle że praktycznie poza waszą kontrolą: nie widzicie, co do niego trafiło, i ledwie możecie na to wpływać.

4.Reguły krytyczne przenieście do hooków

Poświęciłem temu niedawno osobny film (podlinkowany), więc tylko sedno: reguły nie dają gwarancji. Nie ma pewności, że agent wypełni je za każdym razem, bo modele językowe są niedeterministyczne. Jeśli więc coś w waszym procesie musi wydarzać się zawsze, powinno być hookiem, a nie regułą.

(Informacja dodatkowa: hook to mechanizm uruchamiany automatycznie przy określonym zdarzeniu — na przykład tuż przed użyciem narzędzia albo w momencie, gdy agent ogłasza zakończenie pracy.)

Klasyczny przykład: chcecie, żeby po każdej implementacji przechodziły testy — to warunek niezawodności. Można to zapisać jako regułę: „po napisaniu kodu uruchom wszystkie testy”. Tyle że agent czasem o tym zapomina, a bywa, że twierdzi, iż wszystko przeszedł, choć testy świecą się na czerwono. Hook rozwiązuje problem: w chwili zakończenia pracy testy odpalają się deterministycznie — zawsze. Jeśli wszystko jest zielone, kończymy; jeśli coś się wysypie, wyniki wracają do agenta z komunikatem: „Twierdzisz, że skończyłeś, ale jeszcze nie — napraw to”.

Taka gwarancja jest bezcenna. Ogólna zasada: ilekroć w regułach opisujecie konkretne zdarzenie albo kolejność czynności, powinna wam się w głowie zapalać lampka „to powinien być hook”. Rodzajów hooków jest mnóstwo — jeśli temat jest dla was nowy, odsyłam do wspomnianego materiału.

Przerwa sponsorska: HeyGen

(Informacja dodatkowa: poniższy fragment to płatna promocja sponsora z oryginalnego nagrania; zostawiamy ją w skrócie dla kompletności materiału.)

Sponsorem odcinka jest HeyGen — generator wideo z AI, który zamienia pomysł zapisany tekstem w gotowy film w kilka minut. Wpisujecie opis tak, jak piszecie prompt do agenta kodującego; agent wideo wybiera awatara (albo wskazujecie własnego, łącznie z klonem waszego głosu i wizerunku), ustala tempo, dobiera materiały wizualne i zwraca w pełni edytowalną produkcję — nie slajdy z lektorem, tylko kompletny film. Autor pokazuje taki klip i podkreśla jakość klonowania: do stworzenia kopii wystarczyło mu około 20 sekund nagrania głosu i wideo, synchronizacja ust i mimika trzymają się także przy tematach innych niż nagrane, a żona — jak twierdzi — nie poznała, że materiał wygenerowała AI. Wymienione zastosowania: dema produktowe, dokumentacja wewnętrzna, odświeżanie materiałów szkoleniowych. Usługa ma darmowy plan na start, link w opisie filmu.

5.Kontekst: mniej znaczy więcej

Im sprawniejsze stają się modele językowe, tym bardziej prawdziwa jest zasada: w kontekście mniej znaczy więcej. Coraz więcej badań pokazuje, że nadmiar reguł szkodzi agentowi bardziej, niż pomaga — po prostu przytłacza go ilością materiału do ogarnięcia.

Kiedyś trzeba było tłumaczyć modelom nawet podstawy. Dziś plik globalnych reguł z wpisami typu „tak się pisze pull request”, „tak wygląda review kodu” albo klasyczne zasady inżynierskie — „nie powtarzaj się, trzymaj prostotę” — przynosi więcej szkody niż pożytku i tylko dodaje balastu. Oficjalne zalecenie Anthropic mówi o mniej niż 200 liniach; ja zwykle mówię o mniej niż 300. Nie ma tu sztywnej liczby, ale sedno jest jedno: pora skończyć z wielotysiąclinejkowymi plikami globalnych reguł, które kiedyś były normą. Wam to nie pomaga.

W globalnych regułach zostawcie wyłącznie specyfikę projektu: ograniczenia i konwencje obowiązujące niezależnie od tego, nad czym akurat pracuje agent. Całą resztę wyrzućcie albo przenieście do osobnego pliku kontekstowego, po który agent sięgnie, gdy będzie pracować nad danym rodzajem zadania.

6.Sub-agenty potrafią pochłonąć limity

Zastanawialiście się kiedyś, dlaczego limity użycia w Claude Code czy Codexie znikają w zawrotnym tempie? Z dużą dozą pewności mogę powiedzieć, że przynajmniej częściowo winne jest nadmierne sięganie po agentów równoległych — zbyt liberalne używanie sub-agentów. Rozgałęzienia zadań (fan-out) do głębszych poszukiwań czy praca nad wieloma rzeczami naraz kosztują znacznie więcej tokenów, niż się wydaje.

W Claude Code — a podobne polecenie ma w zasadzie każdy inny agent — wystarczy /usage, a potem klawisz W, by zobaczyć zestawienie tygodniowe. U mnie 39% zużycia przypadło na czas, gdy pracowały cztery lub więcej sesji równolegle. To nieproporcjonalnie dużo, bo wcale nie spędzam tak większości czasu. Trzeba być czujnym — Claude Code aż nadto chętnie uruchamia dziesiątki sub-agentów, o które nikt nie prosił. Widziałem to zbyt wiele razy. Pilnujcie więc, jak formułujecie polecenia, i ograniczajcie sub-agenty, gdy zbliżacie się do limitów albo regularnie je przekraczacie.

Niech was nie myli ton: sub-agenty są świetne i naprawdę ważne — chronią kontekst głównego agenta. Po prostu zbyt łatwo sięga się po nie zbyt często, wczytując mnóstwo kontekstu w sesje, które potem znikają bezpowrotnie.

7.Nie przełączaj modelu w środku zadania

Dla oszczędności nie zawsze pracujemy na najsilniejszym modelu — świadomie schodzimy klasę niżej. I widzę, co ludzie robią, gdy w trakcie zadania agent zaczyna utykać: podmieniają model w tej samej rozmowie (w Claude Code przez /model) i jadą dalej. To poważny błąd, bo taka rozmowa jest już skażona. Gdy agent zszedł na złą ścieżkę i zaczyna hojnie zmyślać, mocniejszy model tego nie naprawi — w konwersacji nazbierały się błędy i skrzywienia, które przeniosą się dalej niezależnie od wszystkiego.

Jest w tym szersza lekcja. Kiedy agent popełnia wyjątkowo dużo pomyłek, to nie tylko wasza skrócona cierpliwość zawyża ocenę. Modele językowe potrafią naprawdę ugruntować schemat w obrębie jednej rozmowy — bo to w gruncie rzeczy mechanizmy przewidywania: jeżeli dotąd wyszło im samo złe, to najbardziej prawdopodobną kontynuacją jest kolejny błąd, nawet gdy próbujecie prostować kurs. I stąd ta frustracja.

Zamiast podmieniać model albo na siłę przepychać się dalej z własnym udziałem w pętli, weźcie się za dokument przekazania: zapiszcie, co już zrobiono i gdzie utknęliśmy — a potem bez żalu zamknijcie rozmowę na dobre. Nowej sesji każcie przeczytać dokument i kontynuować pracę. Świeży start daje o niebo lepsze wyniki niż rozmowa, w której pomyłki i błędne założenia piętrzą się jedna na drugiej.

8.Koordynatorzy agentów? Nie warto

Jedyny punkt, który nazwałbym kontrowersyjnym: nie lubię koordynatorów. Istnieje mnóstwo wyszukanych frameworków, w których jakiś „lider zespołu” rozdziela pracę, a agenci komunikują się między sobą. To nie jest niezawodne — i nie jest wam potrzebne. Własną wersję takiego rozwiązania ma nawet Claude (agent teams) i od miesięcy pozostawia ją w stanie eksperymentu. Nie bez powodu: to po prostu nie jest najbardziej niezawodny sposób pracy z agentami kodującymi.

Pokusa jest realna — obietnica skalowania, agent samodzielnie budujący całe dokumenty wymagań… ale w praktyce to nie wychodzi. Jeśli chcecie koordynować pracę i działać równolegle, polecam co innego: żadnych wyszukanych kanałów komunikacji między agentami, żadnego monitoringu przez lidera. Zostaje główny agent, któremu w zwykłym, zrozumiałym języku opisujecie, czego chcecie, a on rozdziela zlecenia do agentów pracujących w tle. Idea podobna, ale niezawodność znacznie większa, bo główny agent jest tu czystym delegatem. Jeśli zależy wam na maksymalnej pewności, nie potrzebujecie „współpracowników”, wspólnej listy zadań ani skrzynki, przez którą agenci wymienialiby wiadomości. Brzmi to świetnie — tylko tak się nie buduje systemów, które mają działać na produkcji.

9.Wykonawca nie zatwierdza własnej pracy

Zasada, którą sztywno stosuję w każdym workflow z AI: nigdy nie pozwalam agentowi-autorowi na ostateczną ocenę jego pracy. Autor — w tym agent — nazbierał w trakcie implementacji sporo uprzedzeń i założeń; gdy prosi się go o weryfikację własnych rezultatów, zwykle stwierdzi, że wszystko gra, nawet jeśli nie jest idealnie. Nie wyłapie własnych założeń. Dlatego każdą wytworzoną pracę powinno oglądać świeże spojrzenie.

Praktycznie wygląda to tak: w rozmowie implementacyjnej można uruchomić skill, który prześwietla efekt, i pozwolić agentowi poprawiać własny kod — dobrze jest też, żeby sam odpalał testy i łapał błędy. Ale ostateczny przegląd zawsze odbywa się w osobnej rozmowie: przekazujecie dokument przekazania tego, co właśnie powstało, prosicie o review pull requesta albo o przegląd niezatwierdzonych jeszcze zmian — cokolwiek, co pomoże agentowi zidentyfikować nowy kawałek pracy. Sedno: ocenia zupełnie nowa konwersacja, więc bez uprzedzeń i założeń — albo z o wiele mniejszą ich ilością.

10.Da się przesadzić z poprawkami

Tak — z agentem kodującym można przerobić dzieło za dużo razy. Jeśli pozwolicie mu iterować w nieskończoność, jakość spadnie. W pewnym momencie agent znajduje najlepsze rozwiązanie — najlepszy kod, najlepszy skrypt — a wymuszanie kolejnych zmian sprawia, że zaczyna wynajdować „poprawki” tylko po to, żeby zrobić wam przyjemność. To przymilność modeli językowych w czystej postaci, a skutki ma dokładnie odwrotne do zamierzonych.

Pokusa jest ogromna — sam się na nią łapałem, zwłaszcza gdy tuż przed resetem limitów zostaje mnóstwo tokenów: „no dawaj, popraw to jeszcze ze dwadzieścia razy, doprowadź do doskonałości”. W efekcie dostaje się chałturę. W przywołanym badaniu wymuszono na agentach po 10–20 przebiegów i w 85% przypadków któraś z wcześniejszych iteracji była wyraźnie lepsza od ostatniej. Wniosek prosty: więcej iteracji to nie to samo co lepszy kod.

11.Walidacja to system, nie krok

Ostatnia rada, szerzej omawiana w innych materiałach na moim kanale: traktujcie walidację jako system, a nie pojedynczy etap. Typowy scenariusz wygląda tak: agent pisze kod, a testy zostają dopisane na koniec, mimochodem — „no dobrze, dodaj może jakieś testy jednostkowe” albo „rzucę okiem, czy aplikacja wygląda sensownie”. A to powinien być jeden z najwyższych priorytetów. Zanim powstanie choć linijka kodu, zaplanujcie całą infrastrukturę weryfikacji: jakie narzędzia ma agent do samokontroli, jakie konwencje obowiązują przy testach jednostkowych i integracyjnych, jak dokładnie przetestujecie efekt sami i w jaki sposób agent ma szukać przypadków brzegowych. Zaplanowanie walidacji przed napisaniem kodu to jeden z najlepszych sposobów na niezawodne workflow.

Zakończenie

To wszystkie 11 trików na uczynienie każdego agenta kodującego bardziej niezawodnym. Mam nadzieję, że choć kilka skłoni was do przyjrzenia się własnemu procesowi pracy. Jeśli materiał był pomocny i interesują was tematy AI w kodowaniu oraz inżynierii agentowej, polubienie i subskrypcja bardzo pomagają. Do zobaczenia w następnym odcinku.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Konkret zamiast ogólników — pisz dla agenta, nie dla człowieka

Na czym polega: Agent nie domyśla się kontekstu tak jak człowiek. Ogólne rady zmuszają go do przyjmowania założeń, a każde założenie to ryzyko błędu. Dokumentacja dla ludzi może być ogólna — reguły dla agentów muszą wskazywać konkretne ścieżki, liczby i polecenia.

Jak stosować: Przy planowaniu zadania i pisaniu reguł pytaj: „co agent musiałby tu założyć sam?”. Zamieniaj „trzymaj porządek w kodzie” na „cały SQL leży w katalogu database”.

Na co uważać: Konkret szybciej się dezaktualizuje — to cena tej metody; łącz ją z okresowym audytem reguł (punkt 2).

2.Reguły „dryfują” — zaplanuj ich audyt

Na czym polega: Wraz z ewolucją repozytorium (zmiany architektury, usunięte pliki) konkretne reguły przestają odpowiadać stanowi faktycznemu. W przywołanym badaniu co czwarte repozytorium z regułami dla AI miało wpisy nieaktualne. Agent próbujący pogodzić sprzeczne informacje traci niezawodność.

Jak stosować: Raz na jakiś czas uruchamiaj audyt zgodności reguł z repozytorium (np. gotową procedurę typu „rules drift check”), który wyłapie odwołania do nieistniejących plików, katalogów czy dawno zastąpionych baz danych.

Na co uważać: Dryf jest podstępny, bo zmiany w kodzie rzadko idą w parze z aktualizacją reguł — audyt musi być cykliczny, nie jednorazowy.

3.To, co musi się wydarzyć, opakuj w hook

Na czym polega: Reguły nie dają gwarancji — model może ich nie wypełnić albo o nich „zapomnieć”. Hook uruchamia się deterministycznie przy określonym zdarzeniu (np. zakończeniu pracy), więc daje pewność wykonania.

Jak stosować: Przejrzyj swoje reguły: wszędzie tam, gdzie opisujesz konkretne zdarzenie lub kolejność („po skończeniu uruchom testy”), przenieś mechanizm do hooka. Testy zielone — koniec; czerwone — wyniki wracają do agenta do poprawy.

Na co uważać: Nie każdy wymóg nadaje się na hook — rezerwuj je dla punktów krytycznych procesu, o których wykonaniu bezwzględnie zależy.

4.Krótki plik reguł pracuje lepiej niż gruby

Na czym polega: Nadmiar kontekstu szkodzi — podstawowe zasady inżynierskie i opisy procesów to dziś balast, który przytłacza model. Anthropic zaleca pilnowanie globalnych reguł poniżej 200 linii (autor: poniżej 300).

Jak stosować: W globalnych regułach zostaw tylko specyfikę projektu — ograniczenia i konwencje obowiązujące przy każdym zadaniu. Instrukcje zadaniowe (np. standardy pull requestów) przenieś do osobnych plików czytanych przy okazji danego rodzaju pracy.

Na co uważać: Nie ma magicznej liczby linii — miarą jest to, czy wszystko w pliku jest rzeczywiście niezbędne przy każdym zadaniu.

5.Sub-agenty zjadają limity — mierz, zanim zabraknie

Na czym polega: Równoległe sub-agenty i rozgałęzienia do researchu kosztują nieproporcjonalnie dużo tokenów — u autora 39% tygodniowego zużycia przypadło na sesje z czterema i większą liczbą wątków naraz. Claude Code potrafi sam uruchomić dziesiątki sub-agentów bez wyraźnego polecenia.

Jak stosować: Regularnie sprawdzaj /usage (w Claude Code; odpowiedniki istnieją w innych agentach) i patrz, ile zużycia przypada na pracę równoległą. Przy zbliżaniu się do limitu ograniczaj równoległość i doprecyzuj polecenia.

Na co uważać: Sub-agenty nie są wrogiem — chronią kontekst głównej sesji; chodzi o proporcje i świadomą kontrolę, nie o rezygnację.

6.„Skażoną” rozmowę kończ, a nie ratuj mocniejszym modelem

Na czym polega: Gdy w jednej sesji nazbiera się dużo błędów, model utrwala schemat — najbardziej prawdopodobną kontynuacją jest kolejna pomyłka, nawet mimo waszych korekt. Podmiana modelu w trakcie zadania nie czyści historii: błędy i skrzywienia przenoszą się dalej. Dotyczy to też /compact, który dodatkowo gubi około 90% szczegółów.

Jak stosować: Zamiast ratować sesję, napisz dokument przekazania (co zrobione, gdzie utknęliśmy), zamknij rozmowę na dobre i w nowej każ go przeczytać i kontynuować. Ten sam mechanizm zastępuje /compact — z tą różnicą że to ty decydujesz, co trafia do podsumowania.

Na co uważać: Wymaga to dyscypliny — kusi „jeszcze jedna” poprawka w tej samej rozmowie; zamykając sesję bez podsumowania, tracisz wykonaną pracę.

7.Rezygnuj z koordynatorów — deleguj z jednego miejsca

Na czym polega: Systemy typu „lider zespołu plus komunikujące się agenty” są zawodne — stąd m.in. eksperymentalny status agent teams u Claude. Obietnica skalowania w praktyce się nie sprawdza.

Jak stosować: Cel opisuj zwykłym językiem głównemu agentowi i pozwól mu rozdzielać zlecenia do agentów pracujących w tle — jako czystemu delegatowi. Zrezygnuj ze współdzielonych list zadań i „skrzynek pocztowych” między agentami.

Na co uważać: Nie myl tego z rezygnacją z równoległości — chodzi o porzucenie wyszukanych mechanizmów komunikacji między agentami, nie z pracy równoległej jako takiej.

8.Wykonawca nie ocenia własnej pracy

Na czym polega: Agent-autor nazbierał w trakcie implementacji założenia i uprzedzenia, których sam nie wyłapie — jego samoocena będzie nadmiernie łaskawa, nawet gdy efekt jest wadliwy.

Jak stosować: Iteracje i testy mogą odbywać się w rozmowie implementacyjnej, ale ostateczny przegląd rób zawsze w nowej sesji — z dokumentem przekazania, review pull requesta albo przeglądem niezatwierdzonych zmian.

Na co uważać: Nowa rozmowa musi dostać precyzyjny opis zakresu tego, co powstało — recenzent bez kontekstu nie będzie wiedział, co właściwie ocenia.

9.Nie iteruj w nieskończoność

Na czym polega: Po znalezieniu dobrego rozwiązania kolejne wymuszone zmiany pogarszają jakość — model przymilnie wymyśla „poprawki”, żeby zaspokoić oczekiwania użytkownika. W przywołanym badaniu w 85% przypadków wcześniejsza iteracja była lepsza niż ostatnia.

Jak stosować: Ustal z góry budżet iteracji i konkretne kryteria akceptacji. Po ich spełnieniu kończ — nawet jeśli „zostały tokeny” przed resetem limitu.

Na co uważać: Najsilniejsza pokusa pojawia się właśnie przy nadwyżce tokenów — hasło „zrób to idealnie” niemal zawsze kończy się chałturą zamiast doskonałości.

10.Walidację projektuj przed kodem, nie po nim

Na czym polega: Testy dopisywane na końcu mimochodem obniżają niezawodność całego procesu. Walidacja powinna być systemem: narzędzia samokontroli agenta, konwencje testów jednostkowych i integracyjnych, plan własnej weryfikacji, sposób szukania przypadków brzegowych.

Jak stosować: Zanim agent napisze pierwszą linię, ustal komplet zasad weryfikacji i wbuduj je w zadanie oraz w hooki (np. automatyczne testy po zakończeniu pracy).

Na co uważać: To koszt na starcie — plan walidacji wymaga czasu przed kodowaniem, ale zwraca się mniejszą liczbą błędów wykrywanych na samym końcu.