Pętle kodowania agentów: od jednoliniowego skryptu Bash do /goal, sprawdzania i bezwzględne zatrzymania
Pętle kodowania agencyjnego krok po kroku: jednoliniowy skrypt bash, Claude Code /goal i /loop, weryfikacja z zewnątrz, trzy limity wydatków oraz umiejętności, które warto zachować.
Jedno zdanie Petera Steinbergera zdominowało rozmowy na temat kodowania przy użyciu sztucznej inteligencji w czerwcu 2026 roku i osiągnęło dwa miliony wyświetleń: agenci do kodowania nie powinni już być sterowani ręcznie, lecz powinny być projektowane z wbudowanymi pętlami sterującymi. Odpowiedzi przerodziły się w spór na temat tego, co to oznacza. Gdy ktoś zapytał, jak to wygląda w praktyce, najczęściej cytowana odpowiedź żartobliwie stwierdziła, że tylko dwie osoby o tym wiedzą. To zabawne, ale błędne. Ta koncepcja nie jest mistyczna, a sposób jej zastosowania polega na jednym poleceniu.
Zamiast debatować o tym, czy inżynieria promptów umarła, bardziej przydatne jest stworzenie takiego narzędzia, wychodząc od linijki tekstu, którą można wkleić w ciągu pięciu minut.
Trzy punkty stanowią podstawę dla reszty:
- Pętla to skrypt, który wysyła polecenie do agenta, sprawdza wynik, ocenia, czy zadanie zostało wykonane, i powtarza proces w przypadku braku sukcesu. Człowiek nie musi już siedzieć wewnątrz tego cyklu i wpisywać instrukcji. Pętlę tworzy się raz, a model pełni rolę podprogramu w jej ramach.
- Najprostszą przydatną pętlą jest jedna linijka kodu bash, a najskuteczniejszą – pojedyncze polecenie z użyciem średnika. Nie jest potrzebne żadne narzędzie do orkiestracji, aby ją uruchomić, a rozpoczęcie pracy bez niego to błąd.
- To, co odróżnia skuteczną pętlę od tej, która wyczerpuje budżet, sprowadza się do dwóch elementów: sposobu sprawdzania jej własnego wyniku w odniesieniu do zewnętrznej prawdy oraz jasnych warunków zatrzymania, które powodują jej przerwanie.
Definicja i podstawa działania
Boris Cherny stworzył Claude Code, a według jego słów Claude Code sam napisał każdy z jego własnych wkładów w ciągu ostatniego miesiąca – 259 pull requestów – podczas gdy jego IDE zostało zdeinstalowane już w listopadzie. Opisuje ten sposób w prosty sposób: nie pyta już Claude’a, pętle są uruchamiane i to one decydują, co nastąpi dalej, a jego zadaniem jest tylko pisanie tych pętli.
Jego drabina z trzema szczeblami ucieleśnia tę ideę. Rok temu praca polegała na ręcznie pisanym kodzie z funkcją autodopisywania. Następnie pojawiły się kilka sesji agentów równolegle, z którymi każda była kierowana ręcznie. Teraz to program kieruje agentem, a inżynier może zająć się czymś innym. Praca awansowała o poziom – z pisania kodu na tworzenie narzędzia do pisania kodu. Podkreśla on, że to nie oznacza emerytury inżynierów. Ktoś nadal decyduje, co należy stworzyć, dobrzy inżynierowie są ważniejsi, a sprawdzanie wyników zawsze ma znaczenie. Naciskanie klawiszy przetrwało, a osąd pozostał.
Najmniejszy pętla: jedna linia bash
Cała koncepcja mieści się w jednej linii kodu, a jej uruchomienie raz daje możliwość jej zrozumienia. Nazywa się ona pętlą Ralpha, od imienia Ralph Wiggum, a Geoffrey Huntley upowszechnił ją w 2025 roku.
while :; do cat PROMPT.md | claude -p --dangerously-skip-permissions; done
To jest cała sprawa. Ten sam plik z zapytaniem jest podawany do Claude Code w trybie bezinterfejsowym, agent działa aż do zakończenia, a następnie cykl rozpoczyna się od nowa z identycznym zapytaniem. Każda próba nie pamięta poprzedniej, więc agent czerpie informacje z plików, listy kontrolnej oraz komitetów pozostawionych przez poprzednie próby. Nie ma tu żadnego frameworku ani maszyny stanu – tylko nieskończony pętla wokół agenta do programowania.
Uważaj przed wklejeniem: flaga umożliwiająca pominięcie pytań o uprawnienia jest tak dosłowna, jak brzmi, i agent będzie wykonywał polecenia bez pytania. Odpowiednim miejscem jest tymczasowy worktree lub kontener git, znajdujący się na gałęzi, której utrata nie ma znaczenia, a nie główna gałąź projektu.
Genialność tkwi w nawyku, a nie w kodzie. Zamiast pozwalać, by jedna długa rozmowa stawała się przestarzała, każda iteracja rozpoczyna się od ustalonej grupy plików bazowych. Plik instrukcji za każdym razem wymienia te same kilka dokumentów – zazwyczaj specyfikację i listę kontrolną, które agent odznacza i zapisuje w miarę postępów. Dzięki temu każda nowa próba rozpoczyna się z jasnym kierunkiem, a zapisywanie postępów zapobiega odchylaniu się od planu lub ponownemu wykonywaniu już zakończonych zadań.
Czy tak prosta sztuczka przynosi efekty? Zespół na hackathonie Y Combinator stworzył sześć repozytoriów w ciągu jednej nocy, używając pętli Ralph i wydając około 297 dolarów na usługi API, co według nich odpowiadało wartości około pięćdziesięciu tysięcy dolarów w postaci pracy kontraktantów. Huntley w ten sam sposób stworzył cały mały język programowania. Jako narzędzie edukacyjne taka prosta metoda szybko staje się niewystarczająca, ale potrafi pokazać podstawy w ciągu pół minuty.
Problem polega na tym, dlaczego osoby najbliżej tematu traktują to jako coś oczywistego. Pętla Ralph zakłada, że terminal pozostaje otwarty, i nigdy nie sprawdza, czy zadanie zostało zakończone. Po prostu działa w nieskończoność, a dwa następne rozdziały zajmują się tym problemem.
Jeden polecenie: /goal i /loop
Nie jest konieczne ręczne pisanie skryptu bash. Claude Code zawiera dwa polecenia, które w sposób bezpieczniejszy pakują tę samą pętlę.
Polecenie /goal sprawia, że agent nadal pracuje, dopóki określony warunek nie stanie się prawdziwy, a to właśnie w tym warunku tkwi sedno rozwiązania.
/goal all tests in test/auth pass and the lint step is clean,
or stop after 20 turns
To, co odróżnia to rozwiązanie od zwykłego pętla while true, to kolejny krok. Po zakończeniu każdej rundy Claude Code przekazuje warunek oraz rozmowę osobnemu, małemu i szybkiemu modelowi – domyślnie Haiku – który odpowiada „tak” lub „nie” i podaje powód. Odpowiedź „nie” jest następnie używana jako wskazówka dla kolejnej rundy. Model wykonawczy nigdy nie może sam ogłosić zakończenia pracy.
Najważniejszym ograniczeniem jest to, że sędzia ani nie przeprowadza testów, ani nie sprawdza repozytorium. Widzi tylko transkrypcję, więc warunek musi być udowodniony na podstawie własnego wyniku agenta. Pomyślne przejście testów w folderze auth kwalifikuje agenta, ponieważ agent je przeprowadził, a wynik znajduje się w rozmowie. Twierdzenie, że mechanizm autoryzacji jest niezawodny, nie wystarcza, gdyż nic w transkrypcji nie może tego potwierdzić. Sędzia czyta potwierdzenia, ale nie sprawdza kodu, więc prawdziwą weryfikacją pozostaje rzeczywiste wykonanie polecenia przez agenta, przy czym sędzia decyduje, czy potwierdzenie wskazuje na pomyślne wyniki.
Warunek dotyczący jakości dźwięku określa jeden mierzalny stan końcowy i wskazuje, w jaki sposób agent go wykaże w wyniku. Poprawa autentyczności nie jest warunkiem. Warunkiem jest natomiast pomyślne przejście testów autentyczności, zerowy wynik po wykonaniu polecenia testowego oraz stan plików w git, który pokazuje zmiany tylko w plikach autentycznościowych, ponieważ każdy z tych elementów pojawia się w transkrypcji jako polecenie wykonywane przez agenta. Należy dodać ograniczenie, np. zatrzymanie się po 20 rundach, wraz z flagą maksymalnej liczby rund jako ostatecznym zabezpieczeniem, aby proces bez nadzoru nie trwał w nieskończoność.
Bezobsługowy, jednorazowy proces wykorzystuje tryb bez terminala wraz z tą flagą oraz cel podanym w cudzysłowach. Proces musi pozostać aktywny podczas pracy, dlatego potrzebuje otwartego terminala lub serwera, a nie zamkniętego laptopa. Aby zamknąć obudowę, rozwiązaniem jest Claude Code w chmurze. Ctrl+C przedwcześnie zakończa lokalny proces.
Krótki proces w praktyce, składający się z dwóch rund i trwający około czterdziestu sekund, wygląda w ten sposób.
> /goal all tests in test/auth pass, npm test exits 0, or stop after 15 turns
◎ /goal active · turn 1
ran: npm test
✗ 2 failing in test/auth/login.test.ts
judge: not done, expired-token case still throws◎ /goal active · turn 2
edited src/auth/token.ts
ran: npm test
✓ 41 passing, exit 0
judge: done, npm test exits 0 and only auth files changed✓ goal achieved · 2 turns · ~$0.40
Wszystko jest tam widoczne: agent przeprowadza sprawdzenie, wynik trafia do transkrypcji, a sędzia ją czyta i decyduje, czy kontynuować, czy zakończyć.
Polecenie /loop to rodzaj zadań zaplanowanych, które pełnią rolę nadzoru. Własny przykład startowy Cherny’ego warto skopiować, zmieniając tylko rzeczowniki.
/loop babysit all my PRs. Auto-fix build issues, and when
comments come in, use a worktree agent to fix them.
Powtarza się w określonych odstępach czasu, obsługuje wszystko, co nowe od poprzedniej iteracji, i kontynuuje działanie, dopóki ktoś go nie zatrzyma lub nie stwierdzi, że praca jest zakończona. To jest metoda polling, a nie obsługa zdarzeń, co wystarcza do monitorowania pull requestów i naprawiania błędów. Zapisuje się tu intencję i zachowanie przy zatrzymaniu, pomijając poszczególne kroki.
Samoweryfikacja zapewnia jego wiarygodność
Pętla, która pisze kod i nigdy go nie sprawdza, powoduje błędy w coraz szybszym tempie. Musi testować swój wynik w odniesieniu do czegoś zewnętrznego i obiektywnego, a nie według własnej oceny.
Ludzie, którzy je używają, kierują się jedną zasadą: to zewnętrzna weryfikacja, a nie własna ocena modelu, decyduje o ukończeniu procesu. Pętla trwa, dopóki operacja docker build nie zakończy się pomyślnie, kontener się nie uruchomi i sprawdzenie stanu nie przejdzie, przy czym informacja od agenta o dobrym wyniku nie ma żadnego znaczenia. Obiektywne kryteria zastępują subiektywne wrażenia. W pseudokodzie solidna treść pętli wygląda w ten sposób.
loop:
agent: make progress on the task
run: npm test (or the build, or the linter)
if check passes: done, exit
if check fails: feed the failure back, try again
if no progress in N tries, or budget hit: stop and ping me
Użytkownicy produkcyjni wprowadzają dwa ulepszenia. Pierwsze polega na tym, aby kod przeglądał inny model niż ten, który go napisał, ponieważ każdy model ma swoje słabe strony, a nowy recenzent może dostrzec to, co umknęło autorowi. Dan Kornas stworzył roborev właśnie w tym celu: przegląda on każdą zmianę w tle i wysyła wyniki do agenta, gdy kontekst jest jeszcze świeży. Drugie ulepszenie to przeprowadzenie co najmniej dwóch rund recenzji, nawet jeśli pierwsza była bezbłędna, oraz ograniczenie liczby rund do pięciu lub sześciu, aby cykl nie mógł niekończąco się powtarzać.
Ciąg pętli nie jest tym, co tworzy „magię” – to informacje zwrotne w jego obrębie są kluczowe. Przy rzeczywistej weryfikacji działa on jak silnik, a bez niej generuje jedynie rachunek.
Zasady chroniące budżet
Gdy generowanie kodu jest niemal bezpłatne, koszty przenoszą się na pętlę, która go uruchamia, a pętla bez ograniczeń stanowi prawdziwe ryzyko finansowe. Uber ograniczył każdego inżyniera do 1 500 dolarów miesięcznie na narzędzie Claude Code i Cursor po tym, jak w ciągu czterech miesięcy wydał cały swój roczny budżet na AI. Zespoły produkcyjne boją się pętli, która nigdy się nie kończy – zapomniany terminal może do rana stać się fakturą o kwocie czterocyfrowej.
Każda poważna pętla wymaga trzech koniecznych zabezpieczeń, a wszystkie one muszą być wdrożone, zanim pętla zostanie uruchomiona bez nadzoru.
max_iterations: stop after N turns (the runaway cap)
no_progress: stop if M turns change nothing (the stuck cap)
budget_ceiling: stop at $X or T tokens (the wallet cap)
on_stop: ping me with the state and the reason
Polecenie /goal niemal bezkosztowo daje możliwość niekontrolowanego rozwoju, dodając warunek zatrzymania po 20 rundach oraz przekazując flagę rundy. Pozostałe dwa elementy trzeba dodać ręcznie. Brak wykrywania braku postępu nie jest wbudowany, a najprostszym rozwiązaniem jest hook Stop lub mały wrapper, który porównuje wyniki git diff --stat pomiędzy rundami i zatrzymuje się po kilku niezmienionych turach. Górna granica budżetu powinna znajdować się w kontrolach wydatków dostawcy, jako sztywny limit w walucie dolarowej skonfigurowany raz w konsoli przed uruchomieniem jakiegokolwiek pętla. Brzmi to jak pisanie pętli, podczas gdy tysiąc agentów buduje firmę przez noc, ale w praktyce większość wysiłków inżynieryjnych ma na celu zapewnienie ich zatrzymania.
Zasób w środku to umiejętność
Pętla to element techniczny, a wartościową częścią jest to, co ona obsługuje.
Steinberger powtarza drugą radę, która ma dłuższy wpływ. To, co robi się dwa razy, staje się umiejętnością, którą można wykorzystywać ponownie, a to, co jest trudne, po rozwiązaniu staje się umiejętnością, dzięki czemu kolejna próba przebiega bez problemów. Pętla, która za każdym razem na nowo odkrywa, jak przeprowadzać testy, znajdować konfigurację i formatować wyniki, zmusza model do nieustannego ponownego uczenia się projektu. Pętla, która korzysta z małej bazy przetestowanych, nazwanych umiejętności, takich jak uruchamianie zestawu testów, tworzenie wniosków o połączenie kodu w stylu zespołu lub wdrażanie zmian na środowisku testowym, rozwija się sama, ponieważ każda iteracja rozpoczyna się od już posiadanych umiejętności. Kosztuje mniej i mniej ulega dewiacjom. To umiejętności stanowią wartość, a pętla jedynie wywołuje je w kolejności.
Pętle, które nadzorują inne pętle
Na granicy, a także w tym, co faktycznie mają na myśli Steinberger i Cherny, pętle nadzorują inne pętle. Pętla nadzorcza przydziela zadania wielu agentom jednocześnie, monitoruje je i wybiera kolejny krok, utrzymując trwały stan zapisany w Git, dzięki czemu awaria nie kończy wszystkiego. Przykładem jest otwarte oprogramowanie Gas Town Steve’a Yegge’a, w którym od dwudziestu do trzydziestu instancji Claude Code jest zarządzanych przez agenta-mera, podczas gdy agenci-patrolanci nieprzerwanie wykonują swoje zadania w ramach pętli. Dynamiczne procesy pracy w Claude Code stanowią zapakowaną formę tego rozwiązania, w której agent pisze skrypt orkiestracji i kieruje flotą podagentów.
Nikt nie zaczyna od tego. Kolejność jest taka: najpierw /goal, potem samokontrola, następnie trzy ograniczenia, a orkiestracja następuje dopiero wtedy, gdy pojedyncza pętla nie jest w stanie sprostać obciążeniu, co dzieje się później, niż sugeruje hype.
Pierwsza pętla w tym tygodniu
- Przetestuj kontrolę ręcznie na gałęzi tymczasowej. Stwórz gałąź o nazwie np. loop-test i uruchom sam komendę testową, sprawdzając, czy po wystąpieniu błędu program zakończy się z kodem niezerowym. Tam, gdzie agent nie potrafi odróżnić sukcesu od porażki, sędzia również nie będzie w stanie tego zrobić.
- Wybierz jeden zadanie o określonych granicach i konkretnym terminie zakończenia. Odpowiednie będą niestabilne testy, małe migracje lub czyszczenie plików. Pomiń wszystko, co zależy od subiektywnych preferencji co do ukończenia.
- Sformułuj to jako /goal z ograniczeniem. Użyj rzeczywistej komendy, a nie ogólnikowego opisu – na przykład bezobsługowego wywołania z maksymalną liczbą 15 iteracji, warunkiem określającym testy autoryzacji, wymogiem zakończenia komendy testowej z kodem zero oraz zatrzymaniem po 15 iteracjach.
Pod koniec tygodnia powstaje rzeczywista praca, której nikt nie wpisał ręcznie, pętla, która sprawdza i koryguje samą siebie, oraz ograniczenie zapobiegające jej wyjściu poza granice. To całe ćwiczenie w miniaturze.
Odpowiedź na pytanie, czym jest pętla, nie ma nic wspólnego ze śmiercią inżynierii promptów. Polega ona na opuszczeniu wnętrza cyklu: napisz pętlę raz, dodaj rzeczywistą kontrolę i umiejętności wielokrotnego użycia, ustaw ograniczenie, aby się zatrzymała, a uwolnioną uwagę poświęć na decydowanie, co budować. Steinberger i Cherny opisują to samo zjawisko z dwóch perspektyw, a dziś bramą wejściową jest jeden polecenie slash.
Literatura pokrewna
- Praktyczne notatki: 21 wzorów projektowania agencyjnego wyjaśnionych prosto — Szczegółowy przewodnik po Praktycznych notatkach: 21 wzorów projektowania agencyjnego wyjaśnionych prosto: umowy, sprawdzania oraz gotowe miejsca na kod dla zespołów wdrażających te wzory.
- Sandbox dla Claude Code: izolowane środowiska agentów na laptopie — Jak lokalny sandbox Kubernetes zapewnia agentom programistycznym własną maszynę, uprawnienia dostosowane do ich potrzeb, listę dopuszczalnych połączeń wyjściowych oraz widok całej floty, wraz z analizą zalet i wad rozwiązań typu „stworz własnie” kontra „kup gotowe”.