Zamiast ciągłego promptowania — buduj pętle

Miesiąc temu Peter Steinberger wrzucił tweeta, który obejrzało osiem milionów osób: "Nie powinieneś już promptować agentów kodujących. Powinieneś projektować pętle, które promptują Twoich agentów." Mniej więcej w tym samym czasie Boris Cherny — twórca Claude Code — powiedział coś podobnego w podcaście Acquired Unplugged: "Nie promptuję już Claude. Mam uruchomione pętle. To one promptują Claude."

Internet zrobił to, co internet robi najlepiej: wszyscy zaczęli się kłócić, nikt nie zobaczył żadnej pętli, a dyskusja zamieniła się w mętny chaos abstrakcji.

Ja od kilku miesięcy faktycznie uruchamiam takie pętle. Nie dlatego, że jestem ahead of the curve — po prostu miałem dość żmudnej pracy z triażem i postanowiłem ją zautomatyzować. To, co odkryłem, było zaskakujące: sposób myślenia oparty na pętlach nie jest zaawansowaną techniką dla AI power userów. To naturalna ewolucja, która następuje w momencie, gdy przestajesz traktować AI agenty jako wyrafinowane narzędzia do copy-paste i zaczynasz traktować je jako systemy, które mogą monitorować, podejmować decyzje i działać w Twoim imieniu.

Trzy smaki "pętli", na które nikt się nie zgadza

Oto dlaczego ta rozmowa tak bardzo się komplikuje: gdy ludzie mówią "pętla", mogą mieć na myśli jedną z trzech rzeczy, a różnice między nimi są istotne.

Pierwszy typ to autonomiczna pętla zadań — zasadniczo "continue until done". Myśl o Geoffreyu Huntley'u i jego skrypcie Ralph (while :; do cat PROMPT.md | claude-code; done), albo o poleceniu /goal, które teraz Codex i Claude Code mają wbudowane. To taki "ustaw i zapomnij" tryb.

Drugi typ to pętla zaplanowana lub sterowana zdarzeniami — praca, która wykonuje się, gdy Ciebie nie ma przy biurku. Przykładem jest HEARTEBEAT.md Petera Steinbergera w OpenClaw: checklist, którą agent przegląda co 30 minut. Potomkami tego wzorca są automatyzacje Codex i zaplanowane rutyny Claude Code.

Trzeci typ to orkiestracja fan-out — dynamiczne workflow z wieloma agentami działającymi jednocześnie. Operacje stylu map/reduce w Claude Code wpisują się właśnie tutaj. To bliższe modelowi aktora niż czemuś, co przypomina zwykłą pętlę.

Moja interpretacja? Steinberger i Cherny opisują drugi typ, podłączony do pierwszego. Pętle, które ja uruchamiam, są zaplanowane i sterowane zdarzeniami na zewnątrz, a kilka z nich wykonuje wewnętrzne pętle eksperymentalne po wyzwoleniu. Ta kombinacja to miejsce, gdzie tkwi prawdziwa siła.

Opiekun PR-a: moja brama do projektowania pętli

Miałem już AI code review na każdym pull request. Claude przeglądał pierwszy, potem wbudowany review z Codex, a potem custom GitHub Action, gdzie kontrolowałem dokładnie, co model widzi — pobierałem pełny kontekst konwersacji plus diff patcha.

Moja faktyczna praca była absurdalna: wysyłałem PR, czekałem na recenzje, a potem copy-paste'owałem komentarze do agenta. Czasami wrzucałem screenshoty. To było manualne, powtarzalne i duszę łamiące.

Pewnego dnia zapytałem mojego agenta: "Czy nie możesz po prostu użyć gh clienta i sprawdzić statusu recenzji sam?" Mogł. Więc naturalnie zapytałem: "Czy nie możesz po prostu ciągle sprawdzać i mówić mi, gdy się skończy?"

To jedno żądanie zmieniło cały mój workflow. Agent teraz obserwuje zmiany statusu recenzji, pobiera nowy kontekst, analizuje feedback i wykonuje faktyczną pracę związaną z jego adresowaniem. Pętla kończy się, gdy osiąga decyzję triażową: zaakceptuj feedback, odpychaj się od niego, albo eskaluj do mnie.

Ten wzorzec generalizuje się świetnie: obserwuj zmiany stanu w zewnętrznych systemach, budź się gdy występują, pobieraj świeży kontekst, analizuj, działaj i triażuj. Gdy raz zobaczysz ten kształt, zaczynasz go dostrzegać wszędzie. Zespół Codex wysyła własną umiejętność babysit-pr, a dokumentacja Claude Code teraz wymienia opiekę nad PR jako główny przypadek użycia dla polecenia /loop.

Wewnętrzne pętle: zmuszanie agenta do prowadzenia własnych eksperymentów

Jest jeszcze jeden wzorzec pętlowy, który doceniłem po dłuższym czasie: pętla eksperymentalna. Koncept autoresearch Andreja Karparthy'ego skierował mnie w tę stronę — uruchamianie wielu iteracji, mierzenie wyników, zatrzymywanie tego, co działa. Skierowałem to na wolną ścieżkę w Pythonie i przeprowadziłem 49 eksperymentów w godzinę, obniżając p95 latency z 339ms do 34ms za około 24 dolary.

Ten sam wzorzec stosuje się do trudniejszych problemów: debugowania zachowania agenta w produkcji. Gdy coś idzie nie tak — dziwny trace w Braintrust, feedback użytkownika w Slack, albo coś, co sam zauważę — odpalam worktree, wklejam trace i wywołuję pętlę testową.

Oto co sprawia, że ta pętla jest inna: wymusza dyscyplinę, z którą intuicja modelu naturalnie walczy. Pozostawiony sam sobie, model zahardcoduje "nigdy nie rób X, Y, Z" w system prompt i overfittuje do jednego trace'a, który mu pokazałeś. Referencje umiejętności destylują badania nad tym, dlaczego to podejście nie działa, a kontrakt pętli wymaga hipotezy i macierzy testowej.

Potrzebuję trzech przypadków: oryginalnego przypadku failing, sąsiedniego positive'a, który powinien pójść tą samą ścieżką, i counterexample'a, który powinien pójść inną drogą. Trzy lub cztery próby uruchamiam jednocześnie na local dev, odtwarzając dokładny kontekst użytkownika z trace'a. Każdy run jest punktowany na podstawie tool calls, latency, delta input-token i correctness. Model nie może oszukiwać przez zapamiętywanie — musi faktycznie zrozumieć.

Co tak naprawdę się zmienia, gdy budujesz pętle

Największa zmiana nie jest techniczna — jest koncepcyjna. Gdy promptujesz agenta, nadal Ty jesteś tym, który prowadzi. Jesteś gazem, nawigatorem, kontrolerem jakości. Pętle odwracają tę relację. Stajesz się architektem systemów, które prowadzą się same.

To nie oznacza, że pełna autonomia jest celem. Wciąż jestem przy bramce triażowej przy wszystkim, co ważne. Pętle zajmują się nudami, monitoringiem, powtarzalnością. Ja zajmuję się osądami, które naprawdę mają znaczenie.

Druga zmiana to taka, że pętle zmuszają Cię do bycia eksplicytnym co do kryteriów sukcesu. Dobra pętla ma jasne warunki wyjścia, jasne punkty decyzyjne, jasne ścieżki eskalacji. Nie możesz zbudować pętli bez zdefiniowania, jak wygląda "done". Ta dyscyplina przesiąka do wszystkiego innego.

Po trzecie, pętle są kompozycyjne. Opiekun PR-a pracuje obok pętli eksperymentalnej. Zaplanowane checki wyzwalają odpowiedzi on-call. Zaczynasz budować bibliotekę zachowań, które współpracują, zamiast sterty jednorazowych promptów.

Praktyczny punkt wyjścia

Jeśli chcesz eksperymentować z pętlami, zacznij od czegoś, co już zautomatyzowałeś w kiepski sposób. Prawdopodobnie masz GitHub Action, który robi coś na harmonogramie, albo sesję Claude Code, którą manualnie prze uruchamiasz, albo proces recenzji, który wymaga copy-paste'owania outputów między narzędziami.

Wybierz ten najbardziej irytujący. Zapytaj siebie: jakiej zmiany stanu faktycznie oczekuję? Jaki kontekst agent potrzebuje, gdy ta zmiana nastąpi? Jaką decyzję musi podjąć?

Potem zbuduj pętlę. Nie musi być elegancka. Musi działać i musi zwrócić Ci kontrolę nad własnym czasem.

Pełne konfiguracje, umiejętności i workflow CI stojące za pętlami, które uruchamiam, są w publicznym repozytorium snapshot: camwest/agent-skills. To nie jest wypolerowany produkt — to działający system, który ewoluuje w miarę mojej nauki. O to właśnie chodzi. Pętle nie są celem; są praktyką.

Dyskurs wokół AI agentów tonie w abstrakcji. Oto konkretna wersja: przestań promptować, zacznij budować pętle i zobacz, co się stanie, gdy pozwolisz maszynie zajmować się monitoringiem, a sam weźmiesz się za znaczenie.