Inżynieria pętli: pętle, procedury i przepływy pracy w Claude Code

W skrócie: Loop engineering to dyscyplina polegająca na tym, by agenci powtarzali cykle pracy aż do spełnienia warunku zatrzymania — zamiast otrzymywać polecenia po jednej turze naraz. Boris Cherny z Anthropic, twórca Claude Code, opisuje własny sposób pracy bez ogródek: „Nie wydaję już poleceń Claude. Uruchamiam pętle. To one wydają polecenia Claude i ustalają, co należy zrobić. Moim zadaniem jest pisanie pętli”.¹ Claude Code oferuje obecnie pełną hierarchię mechanizmów pętli — /goal (powtarzanie, dopóki osobny model nie potwierdzi spełnienia warunku), /loop (cykliczne uruchomienia lokalne), oficjalną wtyczkę Ralph (iterowanie aż do dotrzymania obietnicy), routines (cron w chmurze) oraz dynamiczne przepływy pracy (Claude tworzy graf orkiestracji JavaScript i uruchamia w nim nawet 1 000 subagents). Fundamentem tego podejścia nie jest jednak żadna z tych funkcji, lecz weryfikacja. Pętla osiąga zbieżność tylko wtedy, gdy coś spoza generatora — test, model oceniający, porównanie pikseli lub kontrola maszynowa — stwierdza: „gotowe”. Właściwa weryfikacja sprawia, że korzyści z pętli się kumulują; błędna zamienia je w niezwykle kosztowny błąd losowy. W tym przewodniku omówiono wszystkie mechanizmy pętli wraz z odniesieniami do wersji, wzorzec Ralph i jego tryby awarii, sytuacje, w których pętle muszą przekształcić się w grafy, hierarchię weryfikacji, dyscyplinę kosztową i zasady bezpieczeństwa oraz sposób prowadzenia stale działającej floty. Stan na wersję Claude Code v2.1.234 (sierpień 2026).

Czym jest loop engineering?

Dwa lata temu inżynierowie pisali kod źródłowy ręcznie. Potem kod zaczęły pisać agenty na podstawie promptów tworzonych przez ludzi. Trwająca obecnie zmiana zachodzi poziom wyżej: agenty tworzą prompty dla innych agentów, a człowiek buduje system decydujący o tym, jakie prompty zostaną użyte. Cherny bezpośrednio ocenia skalę tej zmiany: „Przejście od kodu źródłowego do agentów było ogromnym krokiem, a loops są równie ważne i stanowią równie wielki przełom”.²

Jego definicja jest odświeżająco przyziemna: „Loop to w zasadzie zadanie cron uruchamiane lokalnie dla Claude. Routine jest tym samym, ale działa w chmurze”.³ Ta egzotycznie brzmiąca praktyka — „setki, czasem tysiące agentów działających przez 5, 10 czy 20 godzin” w nocy,⁴ Claude Code „w 100% napisany przez Claude Code przez ponad sześć miesięcy”⁴ — sprowadza się do niewielkiego zestawu podstawowych elementów: promptu uruchamianego ponownie zgodnie z harmonogramem lub po spełnieniu warunku, stanu zachowywanego między iteracjami oraz kontroli kończącej wykonanie.

Anthropic nadało tej dyscyplinie nazwę w czerwcu 2026 roku: loops to „agenty powtarzające cykle pracy do momentu spełnienia warunku zatrzymania”, a „jakość wyników loop zależy od otaczającego go systemu”.⁵ Tematem tego przewodnika jest właśnie ów otaczający system.

Warto wyjaśnić pochodzenie terminów, ponieważ w połowie 2026 roku dyskusja rozwijała się bardzo szybko: określenie „graph engineering” — często przypisywane Cherny’emu w wiralowych postach — zostało ukute przez społeczność (wpis Petera Steinbergera z 18 lipca: „czy nadal rozmawiamy o loops, czy przeszliśmy już do graphs?”, spopularyzowany przez Hamela Husaina), a nie przez Anthropic ani Cherny’ego.⁶ Powszechnie udostępniany cytat „85% naszych inżynierów… sposobem na to jest graph engineering” pojawia się wyłącznie we wpisach osób trzecich. Podczas przygotowywania tego przewodnika nie udało się go odnaleźć w żadnym pierwotnym zapisie jego wystąpień (rozmowie w YC Startup School, podcaście Bloomberg Odd Lots ani relacji TechCrunch z Meta @Scale), dlatego należy traktować to przypisanie jako niezweryfikowane. Jego faktyczna praktyka ma strukturę grafu (orkiestratory uruchamiające subagents implementujące, weryfikujące i naprawiające, zagnieżdżone do głębokości 5), lecz potwierdzone nazewnictwo obejmuje loops, routines i workflows — i właśnie tych terminów używa niniejszy przewodnik.

Pięciominutowa najprostsza ścieżka

Trzy polecenia wystarczą, aby przejść od promptów do loops:

# 1. A goal loop: Claude keeps working until a SEPARATE model confirms the condition
/goal all tests pass and coverage is above 80%

# 2. A recurring local loop: re-runs on a schedule while your session is open
/loop 30m check CI on my open PRs and fix any failures

# 3. A cloud routine: runs on Anthropic's infrastructure whether your laptop is open or not
/schedule every morning at 7am: triage new issues, reproduce what you can, draft fixes as PRs

Różnica między nimi a promptem ma charakter strukturalny, a nie kosmetyczny: każde z nich ma regułę ponownego uruchomienia (warunek, zegar lub cron) i każde potrzebuje reguły zatrzymania. Cała pozostała część tego przewodnika dotyczy sposobów zapewnienia wiarygodności obu reguł.

Podstawowy loop i jedna reguła

Każdy system agentowy wykonuje ten sam wewnętrzny cykl, utrwalony w dokumentacji Agent SDK firmy Anthropic jako zbieranie kontekstu → działanie → weryfikacja pracy → powtórzenie.⁷ Proces stosowany przez samo Claude Code również jest loop: ocena promptu, wywołanie narzędzi, odczytanie wyników i powtarzanie tych czynności, dopóki odpowiedź nie zawiera żadnych wywołań narzędzi.⁸

Loop engineering otacza ten wewnętrzny cykl zewnętrznymi loops — i przejmuje jego jedną nienegocjowalną regułę, obecną we wszystkich poważnych źródłach z tej dziedziny:

Agent wykonujący pracę nigdy jej nie ocenia.

• Dokumentacja /goal firmy Anthropic: „o ukończeniu decyduje świeży model, a nie ten, który wykonuje pracę”.⁹
• Esej Anthropic o projektowaniu harness: „Oddzielenie agenta wykonującego pracę od agenta, który ją ocenia, okazuje się skutecznym sposobem rozwiązania tego problemu”.¹⁰
• Cherny o tym, co praktycy najczęściej pomijają: „Weryfikacja jest prawdopodobnie najważniejszą rzeczą, której ludzie nie realizują prawidłowo”.³ W jego praktycznym przykładzie, dotyczącym dwutygodniowego przepisania aplikacji z Electron na Swift, instrukcja brzmi: „uruchom aplikację Electron na maszynie wirtualnej Mac, wykonaj zrzut ekranu, a następnie przeanalizuj go piksel po pikselu. Porównaj go z wersją w Swift. Nie zatrzymuj się, dopóki nie skończysz”.³

Przyczyna jest mechaniczna, a nie moralna: model zapytany „czy praca jest skończona?” wykazuje pozytywną tendencyjność w samoocenie, zaś pewnie brzmiący zapis przebiegu może przekonać oceniany przez model warunek wyjścia do przedwczesnego uznania zadania za „ukończone”.¹¹ Zewnętrzna weryfikacja — zestaw testów, kompilator, porównanie pikseli lub świeży model, który nie jest zaangażowany w wynik — stanowi jedyny odporny na to sygnał.

Drabina autonomii

Powierzchnie loops w Claude Code tworzą drabinę prowadzącą od „ponownie naciśnij Enter” do „działa bez udziału użytkownika”. Każdy poziom wymienia większą autonomię na większe wymagania dotyczące weryfikacji:

(Ujęcie w formie poziomów oparto na taksonomii pardel.dev z lipca 2026 roku, będącej najbardziej przejrzystą niezależną mapą tej przestrzeni.¹¹)

Zasada korzystania z tej drabiny brzmi: należy zacząć od najniższego poziomu rozwiązującego dany problem i przechodzić wyżej dopiero po potwierdzeniu skuteczności weryfikacji na obecnym poziomie. /goal, którego warunku nie można sformułować w sposób umożliwiający sprawdzenie, nie jest gotowy, aby stać się routine.

Szczegółowy opis powierzchni loops

(Ten przewodnik omawia same powierzchnie loops. Przewodnik po Claude Code stanowi pełną dokumentację CLI — konfiguracji, uprawnień, hooks i MCP — natomiast przewodnik po architekturze agentów wyjaśnia, jak łączą się komponenty harness; loops uruchamia się na obu tych warstwach).

/goal — loop typu evaluator-optimizer

/goal <condition> utrzymuje Claude w działaniu do chwili spełnienia warunku: „Po każdej turze mały, szybki model sprawdza, czy warunek został spełniony. Jeśli nie, Claude rozpoczyna kolejną turę, zamiast zwracać kontrolę użytkownikowi”.⁹ Model oceniający (domyślnie Haiku) zwraca odpowiedź tak/nie wraz z uzasadnieniem, które Claude wykorzystuje jako wskazówkę w następnej turze. Funkcja działa również bez interfejsu: claude -p "/goal ..." wykonuje loop aż do ukończenia.

Wskazówki dotyczące tworzenia: warunek powinien być obserwowalny („testy przechodzą”, „endpoint zwraca 200”, „zero błędów TypeScript”), a nie aspiracyjny („kod jest czysty”). Nieprecyzyjny verifier nie wyznacza loop żadnego kierunku — a pewny siebie zapis przebiegu może przekonać warunek oceniany przez model do uznania zadania za ukończone, dlatego wszędzie tam, gdzie to możliwe, warto połączyć /goal z kontrolą wykonywaną maszynowo.¹¹

Dwie zmiany w v2.1.234 wzmacniają sam loop. Goal usuwa się teraz i wyświetla powiadomienie, gdy tura kończy się błędem uniemożliwiającym odzyskanie działania — cofniętym uwierzytelnieniem, wyczerpanym saldem środków lub przepełnieniem kontekstu — zamiast pozostawać aktywny w sesji, która nie może już działać. Ponadto, gdy zadania w tle utrzymują goal w oczekiwaniu przez co najmniej 30 minut, Claude sprawdza ich stan, zamiast czekać bez końca (CLAUDE_CODE_GOAL_CHECKIN_MINUTES pozwala dostosować ten próg; 0 przywraca wcześniejsze oczekiwanie bez limitu).³³

/loop — cykliczne wykonania lokalne

/loop [interval] <prompt> ponownie uruchamia prompt zgodnie z harmonogramem: stałym (/loop 5m check the deploy), dostosowywanym automatycznie (Claude wybiera czas do następnego uruchomienia na podstawie zaobserwowanych wyników) albo, w przypadku samego /loop, uruchamiającym wbudowaną procedurę konserwacyjną. Mechanizm opiera się na CronCreate/CronList/CronDelete (5-polowy cron, 50 zadań na sesję, wygaśnięcie po 7 dniach) oraz narzędziu Monitor, które przesyła strumieniowo dane wyjściowe skryptu działającego w tle, zamiast cyklicznie odpytywać o jego stan.¹² Przykład uruchomieniowy Cherny’ego: „/loop pilnuj wszystkich moich PR-ów. Automatycznie naprawiaj problemy z kompilacją, a gdy pojawią się komentarze, użyj agenta worktree, aby wprowadzić poprawki”.¹³

Najważniejsze ograniczenie: /loop istnieje w obrębie sesji. Po zamknięciu terminala loop przestaje działać — właśnie do takich zastosowań służą routines.

Plugin Ralph — iterowanie aż do dotrzymania obietnicy

Oficjalny plugin ralph-wiggum firmy Anthropic przekształca ulubiony brutalnie prosty wzorzec społeczności w gotowy produkt: Stop hook przechwytuje próbę zakończenia sesji przez Claude i ponownie wprowadza prompt, dzięki czemu model stale iteruje w ramach jednej sesji. /ralph-loop "<prompt>" --max-iterations <n> --completion-promise "<string>" uruchamia proces, a /cancel-ralph go przerywa. README wyraźnie określa --max-iterations jako „podstawowy mechanizm bezpieczeństwa” — dopasowywanie dokładnego ciągu znaków oznaczającego ukończenie może nigdy nie zadziałać.¹⁴

Dynamic workflows — Claude pisze graf

Dynamic workflows, wprowadzone w Claude Code v2.1.154 (maj 2026) i szczegółowo opisane w poście premierowym Anthropic z 2 czerwca 2026, stanowią największy skok koncepcyjny: „Claude może teraz na bieżąco pisać własny harness, zbudowany specjalnie z myślą o wykonywanym zadaniu”.¹⁵ Wystarczy opisać zadanie (albo powiedzieć „use a workflow”); Claude napisze skrypt orkiestracyjny JavaScript — agent() uruchamia subagent z opcjonalnymi danymi wyjściowymi zgodnymi ze schematem JSON, pipeline() przeprowadza elementy przez kolejne etapy, a zwykłe konstrukcje await/loops/warunkowe sterują przepływem — po czym środowisko uruchomieniowe wykona go w tle. „Workflow przenosi plan do kodu… Skrypt workflow sam przechowuje loop, rozgałęzienia i wyniki pośrednie, dzięki czemu kontekst Claude zawiera wyłącznie końcową odpowiedź”.¹⁶

Ograniczenia i struktura: 16 agentów działających równolegle, 1 000 na jedno wykonanie („zapobiega niekontrolowanym loops”), brak możliwości przekazywania danych przez użytkownika w trakcie działania; skrypty zapisane w .claude/workflows/ stają się poleceniami slash wielokrotnego użytku; wykonania można wznawiać dzięki wynikom agentów zapisanym w pamięci podręcznej.¹⁶ Charakterystyczną topologią jest fan-out / refute / converge: niezależne agenty wyszukujące, następnie antagonistyczne agenty weryfikujące, których zadaniem jest podważenie każdego ustalenia, oraz kolejne iteracje aż do uzyskania odpowiedzi odpornych na krytykę. Najważniejszy rezultat przedstawiony przy premierze: przeniesienie przez Bun kodu w Zig, liczącego 535 496 wierszy, do Rust — czego efektem była baza kodu w Rust przekraczająca milion wierszy — w ciągu jedenastu dni (3–14 maja 2026) przy użyciu 64 równoległych agentów, zgodnie z relacją Jarreda Sumnera.¹⁵

Agent teams — graf równorzędnych uczestników

Dostępne po ustawieniu CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 (wersja badawcza od v2.1.32, luty 2026): lider zespołu oraz członkowie, którzy „pracują niezależnie, każdy we własnym oknie kontekstu, i komunikują się bezpośrednio ze sobą” — jest to graf równorzędnych uczestników, a nie drzewo subagents. Koordynację zapewniają wspólna lista zadań z zależnościami, blokady zgłaszania plików oraz osobne skrzynki pocztowe agentów. Wymuszane przez hooks quality gates (TaskCompleted z kodem wyjścia 2 blokuje ukończenie) umieszczają kontrole maszynowe między członkiem zespołu a stanem „ukończone”.¹⁷

Routines — loops działające dłużej niż laptop użytkownika

Routine to „zapisana konfiguracja Claude Code: prompt, co najmniej jedno repozytorium oraz zestaw konektorów, skonfigurowane raz i uruchamiane automatycznie” w chmurze zarządzanej przez Anthropic lub na własnych self-hosted runners.¹⁸ Dostępne są trzy typy wyzwalaczy, które można łączyć: harmonogram cron (minimalny interwał 1 godziny), uruchomienie przez API (POST .../routines/{id}/fire) oraz zdarzenia GitHub. Tworzenie odbywa się za pomocą /schedule lub claude.ai/code/routines. Wykonania przebiegają autonomicznie — bez promptów o zatwierdzenie — dlatego zastrzeżenie w dokumentacji ma fundamentalne znaczenie: zielony status wykonania „nie oznacza, że zadanie zawarte w prompcie zakończyło się powodzeniem. Należy otworzyć wykonanie, przeczytać zapis przebiegu i potwierdzić, co faktycznie zrobiło Claude”.¹⁸

Anthropic uruchamia „codziennie około 20 lub 30 takich routines” we własnych bazach kodu — usuwanie martwego kodu, zwiększanie pokrycia testami i wdrażanie eksperymentów.³

Narzędzia wspierające

Background subagents (domyślne od v2.1.198) utrzymują delegowaną pracę poza kontekstem użytkownika; panel /agents umożliwia ich monitorowanie. Cross-session messaging (v2.1.224) przekształca niezależne sesje w graf przekazujący wiadomości za pośrednictwem SendMessage, stosując zasadę bezpieczeństwa wartą naśladowania: wiadomość z innej sesji „nigdy nie jest uznawana za zgodę użytkownika”.¹⁹ Self-hosted runners (v2.1.224, Team/Enterprise) wykonują sesje chmurowe i routines na własnych maszynach użytkownika — stanowiąc warstwę bazową dla flot działających w skali organizacji.²⁰

Wzorzec Ralph

Społeczność odkryła to jako pierwsza. W lipcu 2025 roku Geoffrey Huntley opublikował esej, w którym nazwał tę technikę imieniem postaci z serialu „The Simpsons”: Ralph to dosłownie

while :; do cat PROMPT.md | claude-code ; done

— jego jednowierszowe rozwiązanie dokładnie w opublikowanej postaci — jedno repozytorium, jedno zadanie na iterację, świeży kontekst przy każdym przebiegu, specyfikacje i pliki postępu w systemie plików przenoszące stan między iteracjami oraz testy i lintery działające jako „backpressure”.²¹ Współczesna bezobsługowa forma tego samego schematu to claude -p "$(cat PROMPT.md)" w pętli powłoki — zasadniczo tak właśnie działał własny harness Anthropic do kompilatora języka C.²³ Deklarowane przez niego rezultaty (MVP kontraktu o wartości 50 tys. dolarów za 297 dolarów w tokenach; sześć repozytoriów podczas jednej nocy na hackathonie) miały równie jasno określone ograniczenia: wyłącznie projekty greenfield, zastępcze i zduplikowane implementacje jako powtarzające się tryby awarii oraz „LLMs są odzwierciedleniem umiejętności operatora”.

Anthropic nigdy nie używa tej nazwy w swoich materiałach inżynieryjnych, lecz wzorzec ten stał się już dwukrotnie oficjalną doktryną: esej o długotrwale działających agentach z listopada 2025 roku zaleca dokładnie taki schemat — agent inicjalizujący tworzy listy funkcji i pliki postępu, a następnie w każdym oknie kontekstu pracują świeżo uruchomieni agenci programistyczni, którzy „rozpoczynają sesję od przeczytania pliku z notatkami o postępie i dzienników commitów git”²² — z kolei w projekcie kompilatora języka C z lutego 2026 roku uruchomiono szesnaście równoległych agentów Claude — „Zbudowałem harness, który umieszcza Claude w prostej pętli”, jak opisuje to Nicholas Carlini — z blokadami zadań opartymi na plikach i git jako warstwą synchronizacji, co pozwoliło wygenerować około 100 tys. wierszy kodu w języku Rust podczas około 2 000 sesji za mniej więcej 20 tys. dolarów.²³ Zdanie z eseju dotyczące weryfikacji ujmuje całą teorię tego wzorca: „ważne jest, aby weryfikator zadań był niemal doskonały”.

Dlaczego świeży kontekst przewyższa jedną długą sesję: skuteczność spada w miarę wypełniania się kontekstu sesji — zgodnie z konsensusem praktyków próg dryfu wynosi około 100 tys. tokenów — a podsumowania powstałe w wyniku kompakcji są stratnymi parafrazami, które maskują błędy pewnie brzmiącą prozą.²⁴ Projekt Ralph, oparty na świeżych instancjach i plikach, omija oba problemy. (Pętla wewnątrz sesji stosowana przez oficjalną wtyczkę poświęca część tych korzyści na rzecz wygody; przy długich przebiegach bezobsługowa forma ze stanem zewnętrznym pozostaje solidniejszym wzorcem).

Pouczająca jest również przestroga związana z tym wzorcem: pewien praktyk uruchomił wtyczkę z nieprecyzyjnym promptem i ustawieniem max_iterations: 0 — które oznacza nieskończoność, a nie wyłączenie — po czym Claude zadał sobie to samo pytanie doprecyzowujące 1 966 razy, a Stop hook przechwytywał każdą kolejną wiadomość.²⁵ Limity iteracji nie są opcjonalne.

Kiedy pętle stają się grafami

Pojedyncza pętla zakłada, że jej iteracje są niezależne lub ściśle sekwencyjne. Gdy tylko w pracy równoległej pojawiają się zależności — zadanie B wymaga wyniku zadania A, dwóch agentów edytowałoby ten sam plik — swobodne pętle zaczynają ze sobą kolidować i potrzebna staje się jawna struktura: lista zadań z tablicami zależności, rezerwowanie plików oraz dyscyplina scalania. Na tym właśnie polega istota debaty o pętlach i grafach: pętle dla jednego repozytorium i jednego celu; grafy, gdy praca równoległa wymaga określonej kolejności.²⁶

Opcje grafów, od najmniej do najbardziej rozbudowanej infrastruktury:

1. Dynamic workflows — zależności wyrażone w przepływie sterowania JavaScript; bariery wyłącznie tam, gdzie dany etap rzeczywiście wymaga wszystkich wcześniejszych wyników. Topologie wymieniane przez Anthropic: rozdzielenie i synteza, weryfikacja kontradyktoryjna, generowanie i filtrowanie, turniej („Uruchom N agentów, z których każdy podejmie próbę wykonania tego samego zadania inną metodą”, a następnie oceniaj ich parami) oraz pętla aż do ukończenia.¹⁵
2. Agent teams — wspólna lista zadań ze śledzeniem zależności oraz lider zatwierdzający plany; graf jest danymi, a nie kodem.¹⁷ W ramach tego wzorca zmieniono jedno ustawienie domyślne: od wersji v2.1.233 narzędzia zadań (TaskCreate/Get/Update/List, TodoWrite) są domyślnie wyłączone w Opus 4.8, Sonnet 5, Fable 5 i nowszych — dokumentacja wyraźnie stwierdza, że agenci bez narzędzi Task „koordynują działania za pomocą wiadomości zamiast wspólnej listy zadań”, dlatego przy domyślnej konfiguracji bieżącej generacji lista zadań po cichu znika. Aby ją przywrócić, należy ustawić CLAUDE_CODE_ENABLE_TODO_TOOLS=1.³³
3. Zewnętrzne orkiestratory — rozwiązania społeczności służące do skalowania: Gas Town Steve’a Yegge’a uruchamia 20–30 instancji Claude Code na grafach DAG opartych na „beads” przechowywanych w git (75 tys. wierszy kodu w języku Go w 17 dni; według jego własnych słów także „pożeracz pieniędzy” wymagający wysokich umiejętności operatora);²⁷ claude-flow/Ruflo (około 31 tys. gwiazdek) organizuje roje w hierarchię królowej i pracowników; silniki w stylu LangGraph nakładają na całość typowaną maszynę stanów z Claude Code wewnątrz węzłów.

Własną formalizacją tej trajektorii autorstwa Cherny’ego jest drabina Steps of AI Adoption, opublikowana przez Anthropic w lipcu 2026 roku: Gated (0 agentów) → Assisted (~1) → Parallel (~10) → Supervised autonomy (~100, gdzie „większość agentów uruchamia Claude, a nie ludzie”) → AI-native (ponad 1 000). Towarzyszy jej następująca rada: „na każdym etapie… trzeba znaleźć i usunąć kolejny zestaw wąskich gardeł oraz zbudować następny zestaw zabezpieczeń”.²⁸

Inżynieria weryfikacji

Wszystko powyżej to instalacja techniczna. Ta sekcja jest produktem.

Drabina eskalacji Anthropic z aktualnego dokumentu o najlepszych praktykach: zapewnić Claude mechanizm zwracający wynik pozytywny lub negatywny, a „pętla zamknie się sama” → warunek /goal ponownie sprawdzany przez niezależnego ewaluatora → Stop hook jako „deterministyczna bramka” → „subagent weryfikujący lub dynamic workflow, który sprawdza własne ustalenia, zlecając świeżemu modelowi próbę podważenia wyniku, aby agent wykonujący pracę nie oceniał jej samodzielnie”.²⁹ Powiązana z tym norma dowodowa brzmi: „Należy polecić Claude przedstawienie dowodów zamiast deklarowania sukcesu”.

Trzy klasy informacji zwrotnej z eseju o Agent SDK: informacje zwrotne oparte na regułach („jasno zdefiniowane reguły dotyczące wyniku, a następnie wyjaśnienie, które reguły nie zostały spełnione i dlaczego” — najlepsza forma), informacje wizualne (zrzuty ekranu, porównania pikseli) oraz LLM-as-judge (nieostre kryteria — jak ujmuje to Anthropic, „na ogół nie jest to szczególnie solidna metoda”).⁷ Warto preferować je w tej kolejności; istniejąca kontrola deterministyczna jest lepsza od oceniającego modelu, który jedynie wyraża opinię.

Warunki konwergencji. Najbardziej przenikliwa krytyczna analiza pętli — opracowanie Yoko Li z sierpnia 2026 roku — sprowadza konwergencję do czterech wymagań: zdefiniowanego stanu docelowego, obserwowalnego stanu bieżącego, precyzyjnych lokalnych zmian oraz reguł zatrzymania znajdujących się poza generatorem. Z jej eksperymentu wyposażonego w instrumentację warto zapamiętać jedną liczbę: 67% tokenów zużytych przez pętlę nie przyniosło żadnej poprawy, ponieważ nic nie informowało pętli, że przyrosty stały się logarytmiczne.³⁰ Limity budżetowe nie służą wyłącznie kontroli kosztów; są regułą zatrzymania ostatniej szansy.

Integralność testów. Z doktryny Anthropic dotyczącej długotrwale działających agentów: „Usuwanie lub edytowanie testów jest niedopuszczalne, ponieważ może prowadzić do pominięcia funkcji lub pozostawienia błędów”.²² Pętle obchodzą specyfikacje — przechodzą widoczne testy, jednocześnie rozmijając się z ukrytą intencją — dlatego sam weryfikator wymaga ochrony przed agentem, którego ocenia.

Oceniać wyniki, nie ścieżki. Z eseju o evals: „Należy oceniać to, co agent wytworzył, a nie drogę, którą obrał”, stosować ewaluatory oparte na kodzie w przypadku celów obiektywnych i ewaluatory oparte na modelu w przypadku kryteriów opisowych, a także przeprowadzać kalibrację: „Nie można wiedzieć, czy ewaluatory działają prawidłowo, dopóki nie przeczyta się transkrypcji i ocen z wielu prób”.³¹

Jeszcze jedno rozróżnienie umyka większości dyskusji: jeśli wszystkie kontrole w pętli są deterministyczne, model w ogóle nie powinien się w niej znajdować. Monitor dryfu porównujący znaczniki czasu, narzędzie sprawdzające linki czy strażnik kompilacji — to skrypty powłoki uruchamiane według harmonogramu: zero tokenów, kilka sekund na przebieg i pełna powtarzalność. Pętle oparte na modelach należy zarezerwować dla iteracji wymagających osądu. Najtańsza pętla to taka, która nigdy nie wywołuje modelu.

Dyscyplina kosztów i bezpieczeństwa

Najgłośniejszy zarzut społeczności wobec inżynierii pętli dotyczy kosztów, co potwierdzają analizy incydentów: błąd uruchamiający subagents, który zużył 4 mln tokenów w pięć minut; nocne pętle pochłaniające tysiące dolarów; limity użycia osiągane „znacznie szybciej, niż oczekiwano”.³² Jedna z tych granic została od tego czasu przesunięta: od wersji v2.1.234 sesja jest automatycznie kontynuowana po zresetowaniu limitu użycia claude.ai (można to wyłączyć w /config → „Continue automatically at usage limit”) — nocna pętla, która wcześniej kończyła działanie po osiągnięciu limitu, obecnie wznawia je po otwarciu nowego okna, co zwiększa, a nie zmniejsza znaczenie opisanych poniżej mechanizmów kontroli budżetu.³³ Wypracowana dyscyplina, której każdy element odpowiada wdrożonemu mechanizmowi kontroli:

Ostatni wiersz zasługuje na osobny akapit, ponieważ właśnie dzięki temu najbardziej bezkompromisowi praktycy zachowują bezpieczeństwo: należy uczynić pull request granicą promienia rażenia. Stali agenci działający w tle Cherny’ego — jeden nieustannie usprawniający architekturę, drugi wyszukujący zduplikowane abstrakcje — przesyłają PR-y bez inicjowania ich przez człowieka;² nic nie jest scalane bez przeglądu. Zawsze aktywna pętla, której najgorszym możliwym skutkiem jest „niescalona gałąź”, może działać intensywnie; pętla zapisująca bezpośrednio do głównej gałęzi nie może. Pętle należy wdrażać stopniowo: zacząć od samej obserwacji (raporty bez zapisu), zdobyć zaufanie podczas serii rutynowych przebiegów, a następnie przejść do proponowania zmian — przy czym dowód kolejności („czyszczenie jest wykonywane dopiero wtedy, gdy weryfikacja zwróci nowy znacznik”) oraz wyczerpującą deklarację promienia rażenia trzeba zapisać przed zainstalowaniem harmonogramu. Ekonomika tej ścieżki wdrażania jest tematem artykułu Pętle wygrywają tam, gdzie weryfikacja jest tania: o tym, co może działać bez nadzoru, decyduje koszt weryfikacji, a nie koszt skonstruowania pętli.

Najpoważniejszym problemem nie jest koszt, lecz zdolność do przeglądu — pętle wytwarzają kod szybciej, niż ludzie są w stanie rzetelnie go przejrzeć.³⁴ Nie ma na to sprytnego rozwiązania; pozostaje jedynie uczciwe określenie zakresu: pętle bez nadzoru powinny działać wyłącznie tam, gdzie weryfikację można przeprowadzić maszynowo — i nigdzie indziej. „Jeśli nie można tego zweryfikować, nie należy tego wdrażać”.²⁹

Prowadzenie floty

Docelowym efektem loop engineering nie jest jedna pętla, lecz stała flota. Tak wygląda ta praktyka, gdy osiągnie dojrzałość:

• Specyfikacje jako pliki. Każda pętla jest wersjonowaną specyfikacją — nazwa, poziom, harmonogram, cel, weryfikator, dozwolone narzędzia, budżet, limit czasu — przechowywaną w obsługiwanym przez nią repozytorium. Jeśli tę samą ręczną kontrolę przeprowadzono trzy razy, należy przekształcić ją w specyfikację.
• Dwa poziomy i awans, na który trzeba zasłużyć. Pętle observe mogą wszystko odczytywać, zapisują dane wyłącznie we własnym folderze raportów i można je od razu dodać do harmonogramu. Pętle act ingerują w otoczenie, dlatego wymagają dowodu prawidłowej kolejności, deklaracji blast radius oraz weryfikatora, który nie jest wykonawcą — wszystko to musi powstać przed utworzeniem harmonogramu. Pętle zaczynają jako observe i muszą zasłużyć na awans.
• Rozdzielenie exec/model. Deterministyczne kontrole działają jako skrypty (zero tokenów, 1–2 sekundy); pętle modelowe pozostają zarezerwowane dla zadań wymagających oceny. Codzienny rytm pracy floty może nic nie kosztować.
• Kontrakty raportów. Jedna linia na kontrolę, PASS|FAIL <check>: <reason>, dopisywana do pliku raportu oznaczonego datą. Jeśli nie można zdefiniować zrozumiałej na pierwszy rzut oka linii PASS, pętla nie jest gotowa. Pętla podsumowująca odczytuje raporty floty, dzięki czemu człowiek czyta jedną stronę zamiast trzydziestu.
• Samodzielnie utrzymujące się wartości bazowe. Najlepsze mechanizmy wykrywania odchyleń wyprowadzają oczekiwania z chronionego artefaktu — znaczników czasu zapisanych w samym przewodniku czy skrótów zapisanych w samym pliku lockfile — dzięki czemu aktualizacja artefaktu aktualizuje również mechanizm nadzorujący i nie powstaje drugie źródło prawdy, o którym można zapomnieć.
• Harmonogram, który przetrwa. Lokalne floty korzystają z harmonogramu systemu operacyjnego (launchd, cron, timery systemd), który wywołuje skrypt uruchamiający; floty chmurowe korzystają z routines. Pętle zależne od sesji (/loop) służą do pracy wykonywanej w obecności użytkownika.

Tak konkretyzuje się stwierdzenie Cherny’ego „moim zadaniem jest pisanie pętli”: praca człowieka przesuwa się w stronę definiowania kontroli, weryfikatorów i budżetów — oraz czytania raportów.

Dwie pierwsze pętle, które warto zbudować

Przy budowaniu floty od zera dwie pętle niemal natychmiast zwracają poniesiony nakład — obie sprawdziły się w harness tej witryny:

Pętla gate — model maker-checker dla wszystkiego, co jest publikowane. Nowy ewaluator (bez pamięci poprzednich rund) ocenia artefakt względem jasno określonego progu; następnie wprowadza się każdą wskazaną poprawkę; kolejny nowy ewaluator ponawia ocenę; pętla zatrzymuje się po osiągnięciu progu lub sztywnego limitu rund. Dwie obserwacje z zastosowania tego procesu podczas sprintu obejmującego piętnaście wpisów: poprawki mogą wprowadzać nowe defekty (zmiana z jednej rundy błędnie przypisała wartość, co wykrył ewaluator w kolejnej rundzie), a ewaluatory mylą się w obie strony — jeden z przekonaniem „poprawił” prawdziwe stwierdzenie, dlatego przed zastosowaniem konkretnych korekt należy zweryfikować je u źródła. To nie checker jest autorytetem; jest nim źródło.

Groundskeeper — punkt wejścia poziomu act. W każdym uruchomieniu wprowadzana jest jedna niewielka, obiektywnie weryfikowalna poprawka, na osobnej gałęzi; przed otwarciem PR wszystkie testy muszą przechodzić, a pętla nigdy nie wykonuje scalenia. Bezpieczeństwo zapewniają dwie reguły: wszystko, co niejednoznaczne, zostaje oznaczone, a nie naprawione (pierwsze nadzorowane uruchomienie słusznie odmówiło poprawienia fałszywego alarmu detektora), natomiast błąd istniejący wcześniej na gałęzi main jest zgłaszany jako taki i nigdy nie zostaje włączony do diff pętli.

Warto przejąć jeden szczegół z obsługi floty: nienadzorowanym pętlom modelowym należy przydzielić dzierżawę sesji — każde uruchomienie powinno zostać odroczone, gdy w tym samym repozytorium aktywna jest sesja interaktywna. Dwóch zapisujących w jednym checkout prędzej czy później przeplecie swoje commity; dzierżawa sprawia, że pętla z założenia ustępuje człowiekowi.

Często zadawane pytania

Czym jest loop engineering?

To praktyka polegająca na zlecaniu agentom AI powtarzania cykli pracy aż do spełnienia warunku zatrzymania, zamiast wydawania im poleceń tura po turze. Zadanie inżyniera przesuwa się od pisania promptów do projektowania pętli: jej reguły ponownego uruchomienia (warunku, harmonogramu lub zdarzenia), stanu między iteracjami, weryfikatora i budżetu. Anthropic nadał tej dyscyplinie nazwę w czerwcu 2026 roku; jej mechanizmy w Claude Code to /goal, /loop, plugin Ralph, routines oraz dynamic workflows.

Czym jest pętla Ralph?

To wzorzec autonomii oparty na metodzie brute force, nazwany przez Geoffreya Huntleya w lipcu 2025 roku: uruchamia się Claude Code w pętli powłoki while, w każdej iteracji przekazując ten sam prompt ze świeżym kontekstem, przy czym pliki postępu i git przenoszą stan między przebiegami, a testy działają jako backpressure. Anthropic udostępnia oficjalny plugin ralph-wiggum, który realizuje pętlę w ramach sesji za pośrednictwem Stop hook, a jego podstawowym mechanizmem bezpieczeństwa jest --max-iterations.

Jak uruchomić Claude Code w pętli?

Należy wybrać najniższy odpowiedni krąg: /goal <condition>, aby wykonywać iteracje do chwili, gdy niezależny ewaluator potwierdzi spełnienie warunku; /loop <interval> <prompt> do cyklicznych uruchomień w czasie trwania sesji; /ralph-loop, aby iteracyjnie realizować jedno zadanie aż do złożenia deklaracji ukończenia; /schedule, aby utworzyć chmurową routine uruchamianą przez cron bez udziału lokalnego komputera. W trybie headless klasycznym rozwiązaniem jest claude -p wewnątrz pętli powłoki z kontrolą zewnętrzną.

Czy pętle zastępują prompting?

Prompt nie znika — zmienia miejsce. Zapisuje się go raz w specyfikacji pętli, która uruchamia go ponownie; coraz częściej (dynamic workflows, stwierdzenie Cherny’ego „tak naprawdę to inny Claude zajmuje się promptingiem”) agent orkiestrujący tworzy prompty dla poszczególnych zadań. W rzemiośle człowieka projektowanie weryfikacji zastępuje dopracowywanie promptów: należy określić warunki, które może sprawdzić maszyna lub nowa instancja modelu.

Czym różnią się loop, routine i workflow w Claude Code?

Loop (/loop) ponownie uruchamia prompt zgodnie z harmonogramem wewnątrz lokalnej sesji i kończy działanie wraz z nią. Routine to ten sam pomysł przygotowany do działania w infrastrukturze chmurowej — uruchamiany przez cron, API lub zdarzenie GitHub, bez potrzeby używania laptopa. Workflow jest grafem orkiestracji pojedynczego uruchomienia: skryptem JavaScript napisanym przez Claude, który uruchamia i koordynuje do 1 000 subagents, a pętle i rozgałęzienia przechowuje w kodzie zamiast w kontekście.

Ile kosztują pętle agentów?

Uczciwa odpowiedź brzmi: „od zera do katastrofalnie wysokich kwot”, a decydującym czynnikiem jest projekt. Deterministyczne mechanizmy nadzorujące nic nie kosztują — są to skrypty uruchamiane według harmonogramu. Pętle modelowe rozlicza się według liczby iteracji: należy nakładać na nie limity (--max-iterations, --max-budget-usd), zapewniać obserwowalność wyników, aby pętla mogła zatrzymać się przy malejących korzyściach, oraz traktować każdy limit jako regułę zatrzymania, a nie utrudnienie. Analizy incydentów — tysiące dolarów wydane przez noc, 4 mln tokenów w ciągu kilku minut — wskazują na jedną wspólną przyczynę: brak zewnętrznego warunku zatrzymania.

Kiedy pętla powinna stać się grafem?

Gdy między równoległymi zadaniami pojawiają się zależności: jedno zadanie potrzebuje wyniku drugiego albo dwóch agentów modyfikowałoby te same pliki. Pętle obsługują jedno repozytorium i jeden cel; grafy (dynamic workflows, zespoły agentów, zewnętrzne orkiestratory) wprowadzają kolejność zależności, rezerwowanie plików oraz dyscyplinę scalania. Po grafy warto sięgać dopiero wtedy, gdy faktycznie pojawiają się kolizje — dodatkowa struktura zwiększa koszt obserwowalności i konfiguracji.

Dziennik zmian