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 albo nie uzna go za niemożliwy do spełnienia), /loop (cykliczne uruchomienia lokalne), oficjalną wtyczkę Ralph (iterowanie aż do dotrzymania obietnicy), zaplanowane zadania w chmurze (dawniej 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.312 (październik 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 scheduled task (formerly a 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.¹¹)

Między poziomami 3 i 5 mieści się jeszcze jedna opcja lokalna: zaplanowane zadania w aplikacji Desktop działają na komputerze użytkownika bez otwartej sesji, z interwałem nawet 1 minuty, gdy ustawia je Claude (1 godziny w formularzach), a dokumentacja wskazuje je, „gdy potrzebny jest dostęp do lokalnych plików i narzędzi”.¹²

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ę zaplanowanym zadaniem w chmurze.

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 model sprawdza, czy warunek został spełniony. Jeśli model uzna, że nie został jeszcze spełniony, Claude rozpoczyna kolejną turę, zamiast zwracać kontrolę użytkownikowi”.⁹ Od strony technicznej „/goal jest nakładką na oparty na prompcie Stop hook o zasięgu sesji”, dlatego nie jest dostępny wszędzie tam, gdzie hooks są wyłączone (disableAllHooks albo allowManagedHooksOnly w ustawieniach zarządzanych). Model oceniający to skonfigurowany mały, szybki model, który zwraca jeden z trzech werdyktów, każdy z krótkim uzasadnieniem:⁹

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.¹¹ Dokumentacja wprost określa to ograniczenie: model oceniający „nie uruchamia poleceń ani nie odczytuje plików samodzielnie, dlatego warunek należy sformułować jako coś, co mogą wykazać własne dane wyjściowe Claude”.⁹ Regułę zatrzymania również warto umieścić w samym warunku: klauzula taka jak or stop after 20 turns jest oceniana tak samo jak reszta warunku, a warunek może liczyć do 4 000 znaków. Jeśli Claude przez kilka kolejnych tur odpowiada modelowi oceniającemu bez użycia narzędzi, Claude Code zatrzymuje loop i zwraca kontrolę użytkownikowi, pozostawiając goal ustawiony.⁹

Obsługa awarii, po raz pierwszy wzmocniona w v2.1.234,³⁴ obejmuje teraz każdy sposób, w jaki tura może się nie powieść:

Gdy poświadczeniami zarządza host, np. aplikacja desktopowa lub sesja chmurowa, niepowodzenie uwierzytelniania pozostawia goal aktywny, ponieważ host sam przywraca dostęp. Z kolei gdy praca w tle utrzymuje goal w oczekiwaniu, Claude sprawdza jej stan po 30 minutach, ponownie godzinę później, a następnie co 2 godziny, wykonując najwyżej trzy takie sprawdzenia bezczynności między promptami użytkownika (CLAUDE_CODE_GOAL_CHECKIN_MINUTES ustawia pierwszy interwał; 0 wyłącza sprawdzenia i automatyczne ponowienia).⁹

/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, od jednej minuty do jednej godziny, 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”.¹³ Aby zastąpić wbudowany prompt konserwacyjny, należy utworzyć plik loop.md (.claude/loop.md w projekcie, który ma pierwszeństwo, albo ~/.claude/loop.md); „Zmiany w loop.md obowiązują od następnej iteracji”, a treść przekraczająca 25 000 bajtów jest obcinana.¹²

Najważniejsze ograniczenie: /loop istnieje w działającym procesie Claude Code. „Zadania uruchamiają się tylko wtedy, gdy Claude Code działa i jest bezczynny”. Po wyjściu z programu przestają się uruchamiać; sesja przeniesiona do tła podtrzymuje loop bez terminala; po wznowieniu przez --resume lub --continue zadania zaplanowane za pomocą CronCreate wracają, ale /loop z tempem dostosowywanym automatycznie nie wraca, więc należy uruchomić go ponownie.¹² W przypadku pracy, która musi przetrwać sesję, dokumentacja porównuje trzy powierzchnie:¹²

Do pracy, która musi działać przy wyłączonym komputerze, służą zaplanowane zadania w chmurze.

Plugin Ralph — iterowanie aż do dotrzymania obietnicy

Oficjalny plugin ralph-loop firmy Anthropic przekształca ulubiony brutalnie prosty wzorzec społeczności w gotowy produkt. W repozytorium anthropics/claude-plugins-official nosi nazwę ralph-loop od 6 stycznia 2026, kiedy Anthropic zmieniło jego nazwę z ralph-wiggum „zgodnie z zaleceniami prawnymi”. 26 października 2026 repozytorium claude-code usunęło własną nieaktualną kopię ralph-wiggum, a jego marketplace instaluje teraz ralph-loop z oficjalnego repozytorium, dzięki czemu „istniejące identyfikatory pluginów nadal działają”.¹⁴ Mechanizm: 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ć.¹⁴ Pod każdym loop opartym na Stop hook działa jeden limit harness: „Jeśli hook zablokuje osiem zatrzymań z rzędu bez wywołania narzędzia między nimi, Claude Code unieważnia następną blokadę i kończy turę” (CLAUDE_CODE_STOP_HOOK_BLOCK_CAP podnosi ten limit).²⁹ Kończy to loop, który przestał robić postępy; nie kończy natomiast loop Ralph, który wciąż wywołuje narzędzia, dlatego limit iteracji nadal ma znaczenie.

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, powiedzieć „use a workflow” albo użyć słowa kluczowego ultracode; Claude napisze skrypt orkiestracyjny JavaScript, w którym agent() uruchamia subagent z opcjonalnymi danymi wyjściowymi zgodnymi ze schematem JSON, pipeline() uruchamia jeden na każdy element listy, parallel() uruchamia cały zestaw naraz, a zwykłe konstrukcje await/loops/warunkowe sterują przepływem; środowisko uruchomieniowe wykona go w tle. /effort ultracode idzie dalej: Claude „planuje workflow dla każdego istotnego zadania w sesji”, a taka sesja „szybciej osiąga limit sesji lub limit tygodniowy niż ta sama praca przy wyłączonej opcji”.¹⁶ „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 według dokumentacji:¹⁶

Skrypty zapisane w .claude/workflows/ stają się poleceniami slash wielokrotnego użytku. Wykonanie jest wznawiane z zapisanych wyników agentów, gdy Claude uruchamia je ponownie, ale agent, który zawiódł, „uruchamia się ponownie, podobnie jak każdy agent, którego skrypt uruchamia po nim, nawet te, które się zakończyły”, a wykonanie przeniesione do tła lub przerwane wyjściem w trakcie działania „nie jest kontynuowane samodzielnie”.¹⁶

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ę. Anthropic udostępnia teraz gotową realizację tej topologii: wbudowany workflow /deep-research „rozsyła wyszukiwania w sieci dotyczące pytania pod kilkoma kątami, pobiera i krzyżowo sprawdza znalezione źródła, głosuje nad każdym twierdzeniem i zwraca raport z przypisami, z którego odfiltrowano twierdzenia, które nie przetrwały krzyżowej weryfikacji”, a gdy jego weryfikatory nie mogą sprawdzić twierdzenia, „raport wymienia to twierdzenie jako niezweryfikowane, zamiast liczyć je jako obalone”.¹⁶ 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 (dodane jako wersja badawcza w v2.1.32, luty 2026; dokumentacja podaje teraz: „Agent teams są eksperymentalne i domyślnie wyłączone”): 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ą”. Tworzy to graf równorzędnych uczestników, a nie drzewo subagents, koordynowany za pomocą wspólnej listy zadań z zależnościami, blokad zgłaszania plików oraz osobnych skrzynek pocztowych agentów. Wymuszane przez hooks quality gates umieszczają kontrole maszynowe między członkiem zespołu a stanem „ukończone”: TaskCompleted z kodem wyjścia 2 blokuje ukończenie, a TeammateIdle z kodem wyjścia 2 utrzymuje członka zespołu przy pracy.¹⁷ Przed włączeniem tej funkcji warto znać dwa zachowania: gdy agent teams są włączone, „subagent, któremu Claude nada nazwę, uruchamia się jako członek zespołu, więc zespoły mogą powstawać nawet wtedy, gdy użytkownik o to nie prosił”, a „członek zespołu nie może zatwierdzić prompt o uprawnienia ani udzielić zgody w imieniu użytkownika”.¹⁷

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

Zaplanowane zadanie w chmurze (dawniej routine) to „zapisana konfiguracja Claude Code: prompt, co najmniej jedno repozytorium oraz zestaw konektorów, skonfigurowane raz i uruchamiane automatycznie”, wykonywana w infrastrukturze chmurowej zarządzanej przez Anthropic lub w samodzielnie hostowanym środowisku organizacji.¹⁸ Stara nazwa przetrwała tam, gdzie jej zmiana by coś zepsuła: w adresie internetowym (claude.ai/code/routines), w aliasie /routines dla /schedule oraz w ścieżce API /fire. Dostępne są trzy typy wyzwalaczy, które można łączyć: harmonogram (minimalny interwał 1 godziny dla cyklicznego rytmu albo jednorazowe wykonanie o ustalonej porze), uruchomienie przez API (POST .../routines/{id}/fire) oraz zdarzenia GitHub. Tworzenie odbywa się za pomocą /schedule, aplikacji Desktop lub claude.ai/code/routines. Sesja wykonania uruchamia się w trybie automatycznym, chyba że tryb automatyczny jest niedostępny; klasyfikator zezwala na każdą akcję albo ją blokuje, a wykonanie zatrzymuje się w oczekiwaniu m.in. przy akcji, która wymaga potwierdzenia nawet w trybie automatycznym (reguła ask), lub po powtarzających się blokadach. Właśnie dlatego zastrzeżenie w dokumentacji ma fundamentalne znaczenie: wynik wykonania mówi, „jak zakończyła się sesja, a nie czy Claude wykonało pracę opisaną w prompcie, dlatego należy otworzyć wykonanie i przeczytać zapis przebiegu, aby zobaczyć, co się stało”.¹⁸ Dwie poprawki wprowadzone od września pokazują, że ta luka jest realna: do v2.1.286 wykonania, których sesja chmurowa nigdy się nie rozpoczęła, były wyświetlane jako Succeeded, a do v2.1.302 wykonania były pokazywane „jako Completed po nieoczekiwanym zatrzymaniu ich sesji chmurowej”.³⁶ To samo wydanie sprawiło, że wykonanie, które zawiodło w połowie, nie jest już uruchamiane ponownie od początku, „co mogło powtarzać pracę, np. dwukrotne publikowanie tego samego raportu”; to powód, by uruchamiana praca była idempotentna.³⁶

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”.¹⁹ Z sesji połączonej z Remote Control dociera też do sesji użytkownika na innych komputerach (v2.1.225+) i w chmurze. Na potrzeby oczekiwania między loops parametr notify_when_idle (v2.1.236+)³⁶ prosi sesję na tym samym komputerze o jedno powiadomienie, gdy następnym razem stanie się bezczynna lub zakończy działanie, a Claude Code subskrybuje je „bez rozpoczynania tury i bez zużywania tokenów w obserwowanej sesji”.¹⁹ Self-hosted runners (v2.1.224, Team/Enterprise) wykonują sesje chmurowe i zaplanowane zadania w chmurze (dawniej routines) na własnych maszynach użytkownika, stanowiąc warstwę bazową dla flot działających w skali organizacji.²⁰

Wzorzec Ralph

Społeczność była tu pierwsza. W lipcu 2025 roku Geoffrey Huntley opublikował esej, w którym nazwał tę technikę na cześć postaci z The Simpsons: Ralph to dosłownie

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

— jego jednolinijkowe polecenie dokładnie w opublikowanej postaci — jedno repozytorium, jedno zadanie na iterację, świeży kontekst przy każdym przebiegu, ze specyfikacjami i plikami postępu w systemie plików, które przenoszą stan między iteracjami, oraz testami i linterami pełniącymi funkcję „przeciwciśnienia”.²¹ Współczesna wersja tego schematu bez interfejsu to claude -p "$(cat PROMPT.md)" w pętli powłoki — zasadniczo tak właśnie działał własny harness Anthropic do budowy kompilatora C.²³ Deklarowanym przez niego wynikom (MVP w ramach kontraktu o wartości 50 tys. dolarów za 297 dolarów w tokenach; sześć repozytoriów przez noc podczas hackathonu) towarzyszyły równie jasno określone ograniczenia: wyłącznie projekty tworzone od zera, powracające problemy z implementacjami zastępczymi i duplikatami oraz stwierdzenie, że „LLM odzwierciedlają umiejętności operatora”.

Anthropic nigdy nie używa tej nazwy w swoich materiałach inżynierskich, ale wzorzec ten stał się już oficjalną doktryną w dwóch odsłonach: esej z listopada 2025 roku o długo działających agentach zaleca dokładnie taki schemat — agent inicjalizujący tworzy listy funkcji i pliki postępu, a następnie dla każdego okna kontekstowego uruchamiane są nowe agenty programujące, które „zaczynają sesję od przeczytania pliku z notatkami o postępach i historii commitów git”²² — z kolei w projekcie kompilatora C z lutego 2026 roku działało równolegle szesnaście 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 gitem jako warstwą synchronizacji. Powstało około 100 tys. wierszy kodu w Rust w 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 zadania był niemal doskonały”.

Dlaczego świeży kontekst sprawdza się lepiej niż jedna długa sesja: skuteczność spada w miarę zapełniania kontekstu sesji — według zgodnej opinii praktyków próg, po którym pojawiają się odchylenia, wynosi około 100 tys. tokenów — a podsumowania powstające podczas kompakcji są stratnymi parafrazami, które nadają błędom postać pewnie brzmiących stwierdzeń.²⁴ Konstrukcja wzorca Ralph, łącząca uruchamianie nowych agentów z plikami, omija oba problemy. (Pętle wewnątrz sesji w oficjalnej wtyczce poświęcają część tych korzyści na rzecz wygody; przy długich przebiegach mocniejszym wzorcem pozostaje wersja bez interfejsu, ze stanem przechowywanym na zewnątrz.)

Pouczająca jest też historia ostrzegawcza związana z tym wzorcem: jeden z praktyków uruchomił wtyczkę z nieprecyzyjnym promptem i max_iterations: 0 — co oznacza nieskończoność, a nie wyłączenie — a Claude zadał sobie to samo pytanie doprecyzowujące 1 966 razy, podczas gdy hook Stop przechwytywał każdą kolejną wiadomość.²⁵ Limity iteracji są konieczne.

Kiedy pętle stają się grafami

Pojedyncza pętla zakłada, że jej iteracje są niezależne albo ściśle sekwencyjne. Gdy tylko w pracy równoległej pojawiają się zależności — zadanie B potrzebuje wyniku zadania A, dwa agenty miałyby edytować 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, zdyscyplinowane scalanie zmian. To rzeczywista istota sporu o pętle i grafy: pętle dla jednego repozytorium i jednego celu; grafy, gdy praca równoległa wymaga ustalonej kolejności.²⁶

Możliwości oparte na grafach, według rosnących wymagań infrastrukturalnych:

1. Dynamiczne przepływy pracy — zależności wyrażone w przepływie sterowania JavaScript; bariery tylko tam, gdzie dany etap rzeczywiście potrzebuje wszystkich wcześniejszych wyników. Topologie wymieniane przez Anthropic: rozdzielanie pracy i synteza wyników, weryfikacja przez podważanie wyników, generowanie i filtrowanie, turniej („Uruchomić N agentów, z których każdy podejmuje próbę wykonania tego samego zadania innym sposobem”, a następnie oceniać wyniki parami) oraz pętla aż do ukończenia.¹⁵
2. Zespoły agentów — wspólna lista zadań ze śledzeniem zależności; członek zespołu uruchomiony, gdy agent kierujący jest w trybie planowania, wysyła swój plan do zatwierdzenia, a Claude Code zatwierdza go automatycznie; agent kierujący sprawdza plan tylko wtedy, gdy działający członek zespołu w procesie (in-process) zostanie przełączony w tryb planowania (Shift+Tab); graf ma postać danych, a nie kodu.¹⁷ W tym wzorcu zmieniło się jedno ustawienie domyślne, po raz pierwszy w v2.1.233:³⁴ narzędzia śledzenia zadań (TaskCreate, TaskGet, TaskUpdate, TaskList, TodoWrite) są teraz „domyślnie dostępne tylko w modelach Opus 4.7, Sonnet 4.6, Haiku 4.5 i wcześniejszych”, a ten domyślny zestaw obowiązuje od v2.1.268.³⁸ Agenty bez nich „koordynują pracę za pomocą wiadomości zamiast wspólnej listy zadań”,¹⁷ więc przy bieżącym modelu w zwykłej sesji lokalnej lista zadań nie jest dostępna, dopóki użytkownik jej nie włączy; sesje w tle i sesje chmurowe otrzymują te narzędzia w każdym modelu.³⁸ Można je włączyć przez CLAUDE_CODE_ENABLE_TODO_TOOLS=1, --allowedTools TaskCreate lub listę --tools, która je wymienia. Wyeksportowana zmienna nie dociera do członka zespołu w podzielonym panelu, dlatego aby mu je udostępnić, należy uruchomić agenta kierującego poleceniem claude --settings '{"env":{"CLAUDE_CODE_ENABLE_TODO_TOOLS":"1"}}'.³⁸
3. Zewnętrzne orkiestratory — sposób społeczności na skalowanie poziome: Gas Town Steve’a Yegge’a uruchamia 20–30 instancji Claude Code pracujących na grafach DAG złożonych z „beads” przechowywanych w git (75 tys. wierszy kodu w Go w 17 dni; według samego autora 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 robotników; silniki w stylu LangGraph dodają na wierzchu maszynę stanów z określonymi typami, z Claude Code wewnątrz węzłów.

Cherny ujął tę ścieżkę rozwoju w drabinę Etapów wdrażania AI, opublikowaną za pośrednictwem Anthropic w lipcu 2026 roku: Kontrola na każdym etapie (0 agentów) → Praca wspomagana (około 1) → Praca równoległa (około 10) → Nadzorowana autonomia (około 100, gdzie „większość agentów uruchamia Claude, a nie ludzie”) → Organizacja oparta na AI (1 000+). Towarzysząca jej rada brzmi: „na każdym etapie… trzeba znajdować i usuwać kolejne wąskie gardła oraz budować kolejne zabezpieczenia”.²⁸

Inżynieria weryfikacji

Wszystko powyżej to infrastruktura. Ta sekcja to produkt.

Drabina eskalacji Anthropic, z aktualnego dokumentu dobrych praktyk, zaczyna się od jednej wskazówki: „Należy dać Claude coś, co może uruchomić i co zwraca wynik pozytywny albo negatywny. Gdy Claude to ma, może samodzielnie kontynuować pracę i nie trzeba go pilnować”. Kolejne szczeble prowadzą od decyzji Claude do egzekwowania przez harness: linijka w prompcie (run the auth tests after, and keep going until they pass) → warunek /goal, który „osobny model sprawdza względem konwersacji po każdej turze”, co „ma znaczenie przy długich wykonaniach w tle, w których Claude czasem kończy turę podsumowaniem postępów, choć niektóre pozycje są wciąż otwarte” → hook Stop, „egzekwowany przez Claude Code (harness), więc tura nie kończy się, dopóki sprawdzanie typów nie przejdzie albo nie zostanie osiągnięty limit blokad” → przegląd „przez kogoś, kto nie pisał kodu”, w którym /code-review „przegląda diff w nowym subagencie, który nigdy nie widział konwersacji. Nie ulega rozumowaniu, które doprowadziło do powstania kodu”.²⁹ Towarzyszy temu zasada dotycząca dowodów: należy „poprosić Claude o dowody: uruchomione polecenie i jego wynik albo zrzut ekranu”, ponieważ „w przypadku sesji, której nikt nie obserwował, to także jedyne dostępne dowody”.²⁹ Kontradyktoryjne obalanie wyników, szczebel, na którym ta drabina kiedyś się kończyła, znajduje się teraz w dokumentacji przepływów pracy, której przykładowy prompt prosi przepływ pracy, by „kontradyktoryjnie zweryfikował każde ustalenie przed jego zgłoszeniem”.¹⁶

Ten sam dokument dzieli każdą instrukcję na to, o czym decyduje Claude, i to, co egzekwuje Claude Code. Trzy jego wiersze to reguły zatrzymania, budżetu i scalania pętli:²⁹

Pętla działająca bez nadzoru potrzebuje wpisu z prawej kolumny w każdym wierszu; lewa kolumna to wszystko, czym dysponuje pętla, gdy nikt takiego wpisu nie przygotował. Dokument rezygnuje też z pewnego nawyku w promptach: linijki w rodzaju „keep going, loop until done, don’t be lazy” „częściej powodują nadmiarową pracę, niż usuwają zastój”, a „w wykonaniach, których nikt nie obserwuje, egzekwuje to /goal lub hook Stop”.²⁹

Trzy klasy informacji zwrotnej, z eseju Agent SDK: informacja zwrotna oparta na regułach („jasno określone reguły dla wyniku, a następnie wyjaśnienie, których reguł nie spełniono i dlaczego” — najlepsza forma), informacja zwrotna oparta na obrazie (zrzuty ekranu, różnice na poziomie pikseli) oraz LLM w roli sędziego (nieprecyzyjne kryteria oceny — według Anthropic „na ogół niezbyt solidna metoda”).⁷ Warto preferować je w tej kolejności; istniejąca kontrola deterministyczna jest lepsza od sędziego, który wyraża opinię.

Warunki zbieżności. Najbardziej wnikliwa krytyczna analiza pętli — autorstwa Yoko Li z sierpnia 2026 roku — sprowadza zbieżność do czterech wymagań: zdefiniowanego stanu docelowego, obserwowalnego stanu bieżącego, precyzyjnych lokalnych zmian oraz reguł zatrzymania poza generatorem. Z jej eksperymentu z pomiarami warto zapamiętać jedną liczbę: 67% wydatków pętli na tokeny nie przyniosło żadnej poprawy, ponieważ nic nie sygnalizowało pętli, że przyrost korzyści stał się logarytmiczny.³⁰ Limity budżetu to nie tylko kontrola kosztów; to reguła zatrzymania stosowana w ostateczności.

Integralność testów. Z doktryny Anthropic dotyczącej długo działających agentów: „Niedopuszczalne jest usuwanie lub edytowanie testów, ponieważ może to prowadzić do brakujących lub błędnie działających funkcji”.²² Pętle obchodzą specyfikacje — przechodzą widoczne testy, nie spełniając niewyrażonej w nich intencji — dlatego sam weryfikator wymaga ochrony przed agentem, którego ocenia.

Oceniać wyniki, nie ścieżki dojścia. Z eseju o ewaluacjach: „Należy oceniać to, co agent wytworzył, a nie drogę, którą do tego doszedł”, stosować mechanizmy oceny oparte na kodzie tam, gdzie kryteria są obiektywne, a oparte na modelach — przy ocenie według rubryk, oraz je kalibrować: „Nie da się stwierdzić, czy mechanizmy oceny działają dobrze, bez przeczytania zapisów przebiegu i ocen z wielu prób”.³¹

Jeszcze jedno rozróżnienie, pomijane w większości dyskusji: gdy każda kontrola w pętli jest deterministyczna, model w ogóle nie jest w niej potrzebny. Monitor odchyleń porównujący znaczniki czasu, narzędzie sprawdzające linki, strażnik kompilacji — to skrypty powłoki uruchamiane według harmonogramu: zero tokenów, kilka sekund na przebieg, pełna powtarzalność. Pętle sterowane modelem należy zarezerwować dla iteracji wymagających osądu. Najtańsza pętla to ta, 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, a analizy incydentów go potwierdzają: błąd przy uruchamianiu subagents pochłaniający 4 mln tokenów w pięć minut; nocne pętle zużywające tysiące dolarów; limity wykorzystania osiągane „znacznie szybciej, niż oczekiwano”.³² Jedna z tych granic od tego czasu się przesunęła: od wersji v2.1.234 sesja jest automatycznie kontynuowana po zresetowaniu limitu wykorzystania claude.ai (ustawienie autoContinueAtUsageLimit; można je wyłączyć w /config → „Continue automatically at usage limit”).³⁴³⁷ Zakres jest wąski. „Automatyczna kontynuacja jest domyślnie włączona w sesjach interaktywnych zalogowanych za pomocą subskrypcji claude.ai”; Claude Code nie rozpoczyna samodzielnie oczekiwania w przypadku „resetu za ponad 24 godziny”, takiego jak limit tygodniowy; wyjście z Claude Code kończy oczekiwanie; a w „sesjach w tle i uruchomieniach -p” Claude Code „w ogóle nie oferuje oczekiwania”, co obejmuje bezinterfejsowy Ralph i claude -p "/goal ...".³⁷ W kwalifikującej się sesji pętle się do tego dostosowują: wstrzymany /goal wznawia działanie po resecie,⁹ a od v2.1.271 uruchomienie przepływu pracy przeczekuje limit, zamiast kończyć niepowodzeniem pracę swoich agentów, najwyżej dwa razy na uruchomienie.¹⁶ Nocna pętla pozostająca w otwartej sesji interaktywnej może teraz przetrwać limit; pętla działająca bez interfejsu lub w sesji w tle nadal się na nim zatrzymuje. To sprawia, że poniższe mechanizmy kontroli budżetu stają się jeszcze ważniejsze. Wypracowano następujące zasady, a każdej z nich odpowiada już dostępny mechanizm kontroli:

Ostatni wiersz zasługuje na osobny akapit, ponieważ to właśnie w ten sposób bezpieczeństwo zachowują praktycy najdalej posuwający się w automatyzacji: należy ograniczyć zasięg skutków do pull requestu. Stale działający w tle agenci Cherny’ego — jeden nieustannie ulepszający architekturę, drugi wyszukujący powielone abstrakcje — zgłaszają PR-y bez inicjowania ich przez człowieka;² żaden nie jest scalany bez przeglądu. Stale działająca pętla, której najgorszym możliwym skutkiem jest „niescalona gałąź”, może pracować intensywnie; pętla zapisująca zmiany bezpośrednio w main nie może. Zaplanowane zadania w chmurze mają to wbudowane jako ustawienie domyślne: „Claude wypycha swoją pracę do gałęzi z prefiksem claude/, chyba że prompt nakazuje wypchnięcie do innej gałęzi”, a ochrona gałęzi lub rulesets w GitHub decydują, dokąd wykonanie może wypychać zmiany.¹⁸ Zakres uprawnień pętli należy zwiększać stopniowo: zacząć od samej obserwacji (raporty, bez zapisu), zbudować zaufanie podczas rutynowych uruchomień, a następnie przejść do proponowania zmian — przy czym dowód zachowania kolejności („czyszczenie uruchamia się dopiero po zwróceniu nowego znacznika przez weryfikację”) i wyczerpujący opis zasięgu skutków muszą zostać zapisane przed skonfigurowaniem harmonogramu. Ekonomię tej ścieżki awansu omawia artykuł Pętle sprawdzają się tam, gdzie weryfikacja jest tania: o tym, co może działać bez nadzoru, decyduje koszt weryfikacji, a nie budowy pętli.

Żadne dane wejściowe pętli nie są zgodą. Cztery udokumentowane reguły są ze sobą spójne: wiadomość z innej sesji „nigdy nie jest uznawana za zgodę użytkownika”;¹⁹ członek zespołu „nie może zatwierdzić prompt o uprawnienia ani udzielić zgody w imieniu użytkownika”;¹⁷ uruchomiony prompt zaplanowanego zadania w chmurze „nie może pełnić funkcji zatwierdzenia ani zgody na działania w trakcie wykonania”, a tekst wysłany z wywołaniem API „trafia opakowany w blok <routine-fire-payload>, który oznacza go jako niezaufane dane”;¹⁸ w trybie automatycznym zaś prompt, który skrypt przepływu pracy przekazuje do agent(), „nie jest traktowany jako prośba użytkownika”, ponieważ „Claude Code oznacza go jako tekst obliczony przez skrypt”.¹⁶ Tę regułę warto przenieść do własnych pętli: tekst wytworzony przez maszynę to dane, a zatwierdzenie pochodzi od człowieka.

Najpoważniejszy zarzut nie dotyczy kosztów, lecz możliwości przeprowadzania przeglądów — pętle produkują kod szybciej, niż ludzie są w stanie rzetelnie go sprawdzać.³³ Nie ma na to sprytnej odpowiedzi; pozostaje uczciwe określenie zakresu: pętle bez nadzoru mają zastosowanie wyłącznie tam, gdzie weryfikację można przeprowadzić maszynowo. Jeśli nie da się tego zweryfikować, nie należy tego wdrażać.

Co kontrolowane badanie mówi o komponentach harness

Większość porad dotyczących harness, także tych zawartych w tym przewodniku, pochodzi od praktyków zmieniających po jednym elemencie w środowisku produkcyjnym. W badaniu z września 2026 roku, przeprowadzonym przez UMass Amherst, Emory, UNC Charlotte i Zoom, zrobiono to w warunkach kontrolowanych: wykorzystano specjalnie zbudowany harness, „którego pętla wykonawcza pozostaje stała, podczas gdy zmieniane są trzy komponenty: planowanie, przestrzeń działań i zarządzanie kontekstem”. Badanie objęło „176 dopasowanych konfiguracji obejmujących pięć strategii zarządzania kontekstem, cztery budżety okna kontekstowego oraz ukierunkowane eksperymenty z wyłączaniem elementów planowania i przestrzeni działań” na SWE-Bench Verified i Terminal-Bench 2.1, z użyciem czterech modeli o otwartych wagach: trzech wariantów wielkości Nemotron-3 i Mistral-Medium-3.5-128B.³⁵ Cztery wnioski, słowami autorów:

• „Zarządzanie kontekstem staje się coraz cenniejsze wraz ze zmniejszaniem budżetu okna kontekstowego, a większość korzyści wynika z zapobiegania awariom spowodowanym przepełnieniem kontekstu”.
• „Usuwanie treści według reguł przed podsumowywaniem opartym na LLM zapewnia najwyższą ogólną efektywność spośród strategii zarządzania kontekstem, natomiast umożliwienie odzyskiwania usuniętych treści wprowadza mechanizmy, z których modele rzadko korzystają i które nie poprawiają trafności”.
• „Rola planowania zmienia się: słabszym modelom pomaga zwiększać trafność, a silniejszym — obniżać koszty przy niewielkiej zmianie trafności”.
• „Predefiniowane narzędzia poprawiają wyniki modeli słabiej posługujących się bash, natomiast modele sprawnie korzystające z bash mogą skutecznie działać z interfejsem udostępniającym wyłącznie bash i osiągać znacznie niższe koszty, zwłaszcza w zadaniach skupionych na wierszu poleceń”.

W mojej ocenie trzy z tych wniosków odnoszą się bezpośrednio do inżynierii pętli. Zarządzanie kontekstem chroni przed jego przepełnieniem: długo działająca pętla powinna kontrolować budżet swojego okna i usuwać obszerne wyniki narzędzi, zanim zacznie cokolwiek podsumowywać. Można przy tym pominąć budowę mechanizmów odzyskiwania treści, z których model nie skorzysta. W przypadku sprawnego modelu planowanie służy raczej regulowaniu kosztów niż poprawie trafności — warto o tym wiedzieć przed dodaniem fazy planowania do pętli wykorzystującej silny model. Z kolei wynik dla samego bash to podział na wykonanie skryptowe i modelowe, przeniesiony o poziom wyżej: gdy wykonawca jest sprawny, mniejsza liczba działań o większym zakresie kosztuje mniej. Zastrzeżenia pochodzą z samego badania. Cztery modele, dwa benchmarki i harness zbudowany na potrzeby eksperymentu, a nie dla któregokolwiek z dostępnych agentów — wyniki wyznaczają więc kierunki, nie gotowe ustawienia.³⁵

Zarządzanie flotą

Docelowym rezultatem inżynierii pętli nie jest jedna pętla, lecz stale działająca flota. Tak wygląda ta praktyka, gdy osiąga dojrzałość:

• Specyfikacje jako pliki. Każda pętla to wersjonowana specyfikacja — nazwa, poziom, harmonogram, cel, weryfikator, dozwolone narzędzia, budżet, limit czasu — przechowywana w repozytorium, któremu służy. Jeśli tę samą ręczną kontrolę wykonano trzy razy, staje się ona specyfikacją. Anthropic udostępnia niewielką wersję tego pomysłu: plik loop.md zastępuje wbudowany prompt samego /loop, a zmiany w nim obowiązują od następnej iteracji.¹²
• Dwa poziomy, awans wymagający zaufania. Pętle obserwujące mogą odczytywać wszystko, zapisują wyłącznie we własnym katalogu raportów i od razu otrzymują harmonogram. Pętle działające zmieniają stan otoczenia i wymagają dowodu zachowania kolejności, opisu zasięgu skutków oraz weryfikatora niezależnego od twórcy — zapisanych jeszcze przed utworzeniem harmonogramu. Pętle zaczynają od obserwacji i muszą zasłużyć na awans.
• Podział na wykonanie skryptowe i modelowe. Deterministyczne kontrole działają jako skrypty (zero tokenów, 1–2 sekundy); pętle modelowe są zarezerwowane dla zadań wymagających osądu. Codzienny cykl kontrolny floty może nic nie kosztować.
• Kontrakty raportowania. Jeden wiersz na kontrolę, PASS|FAIL <check>: <reason>, dopisywany do pliku raportu opatrzonego datą. Jeśli nie da się zdefiniować wiersza PASS zrozumiałego na pierwszy rzut oka, pętla nie jest gotowa. Pętla podsumowująca odczytuje raporty floty, aby człowiek czytał jedną stronę zamiast trzydziestu.
• Samoczynnie aktualizowane punkty odniesienia. Najlepsze mechanizmy monitorowania rozbieżności wyprowadzają oczekiwania z artefaktu, którego pilnują — ze znaczników czasu zapisanych w samym przewodniku czy skrótów zapisanych w pliku blokady zależności. Dzięki temu aktualizacja artefaktu aktualizuje też mechanizm monitorujący i nie ma drugiego źródła prawdy, o którym można zapomnieć.
• Trwałe planowanie uruchomień. Lokalne floty korzystają z harmonogramu systemu operacyjnego (launchd, cron, timery systemd), który wywołuje skrypt uruchamiający, albo z zaplanowanych zadań w aplikacji Desktop, gdy komputer pozostaje włączony; floty chmurowe korzystają z zaplanowanych zadań w chmurze (dawniej procedur). Pętle związane z sesją (/loop) służą do pracy wykonywanej w obecności użytkownika albo do sesji przeniesionej do tła.¹²

To konkretna realizacja słów Cherny’ego „moim zadaniem jest pisanie pętli”: praca człowieka przesuwa się ku definiowaniu kontroli, weryfikatorów i budżetów — oraz czytaniu raportów.

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

Przy budowie floty od zera dwie pętle zwracają się natychmiast — obie sprawdzone w harness tej witryny:

Pętla kontrolna — układ twórca–kontroler dla wszystkiego, co jest publikowane. Nowy oceniający (bez pamięci poprzednich rund) ocenia artefakt według jawnego progu jakości; następnie wdrażane są poprawki odpowiadające wszystkim wskazanym uwagom; kolejny oceniający ponawia ocenę; pętla zatrzymuje się po osiągnięciu progu lub bezwzględnego limitu rund. Dwie obserwacje z jej stosowania podczas sprintu obejmującego piętnaście wpisów: poprawki mogą wprowadzać nowe błędy (poprawka z jednej rundy błędnie przypisała wartość liczbową, co wykrył oceniający w następnej rundzie), a oceniający mylą się w obie strony — jeden z przekonaniem „poprawił” prawdziwe twierdzenie, dlatego konkretne korekty są weryfikowane u źródła przed ich zastosowaniem. Autorytetem nie jest kontroler, lecz źródło.

Pętla porządkowa — punkt wejścia na poziom działania. Jedna niewielka, obiektywnie weryfikowalna poprawka na uruchomienie, na osobnej gałęzi, testy zaliczone przed otwarciem PR-a, a sama pętla nigdy nie scala zmian. Bezpieczeństwo zapewniają dwie zasady: wszystko, co niejednoznaczne, jest oznaczane do sprawdzenia, a nie poprawiane (pierwsze nadzorowane uruchomienie słusznie odmówiło działania po fałszywym alarmie detektora), a błąd istniejący już w main jest zgłaszany jako taki i nigdy nie trafia do zestawu zmian pętli.

Jeden szczegół zarządzania flotą warto przejąć: pętlom modelowym działającym bez nadzoru należy przydzielić dzierżawę sesji — odraczać każde uruchomienie, gdy w tym samym repozytorium trwa sesja interaktywna. Dwa podmioty zapisujące zmiany w jednej kopii roboczej prędzej czy później zaczną przeplatać commity; dzierżawa z założenia sprawia, że pętla ustępuje człowiekowi.

FAQ

Czym jest inżynieria pętli?

To praktyka polegająca na tym, by agenci AI powtarzali cykle pracy aż do spełnienia warunku zatrzymania, zamiast otrzymywać osobny prompt w każdej turze. Zadanie inżyniera przesuwa się z pisania promptów na projektowanie pętli: reguły jej ponownego uruchomienia (warunek, harmonogram, zdarzenie), stanu między iteracjami, weryfikatora i budżetu. Anthropic nadało tej dyscyplinie nazwę w czerwcu 2026 roku; w Claude Code jest ona dostępna poprzez /goal, /loop, wtyczkę Ralph, zaplanowane zadania w chmurze (dawniej procedury) i dynamiczne przepływy pracy.

Czym jest pętla Ralph?

To wzorzec autonomii oparty na metodzie siłowej, nazwany przez Geoffreya Huntleya w lipcu 2025 roku: Claude Code działa w pętli powłoki while, otrzymując w każdej iteracji ten sam prompt z nowym kontekstem. Pliki postępu i git przenoszą stan między przebiegami, a testy pełnią funkcję hamulca. Anthropic udostępnia oficjalną wtyczkę ralph-loop (w styczniu 2026 przemianowaną z ralph-wiggum), która realizuje pętlę wewnątrz sesji za pomocą mechanizmu Stop hook, z --max-iterations jako podstawowym zabezpieczeniem.

Jak uruchomić Claude Code w pętli?

Należy wybrać najniższy poziom, który spełnia wymagania: /goal <condition> do iteracji aż do potwierdzenia warunku przez osobnego oceniającego; /loop <interval> <prompt> do cyklicznych uruchomień, dopóki działa sesja Claude Code; /ralph-loop do iterowania nad jednym zadaniem aż do spełnienia deklaracji ukończenia; /schedule do utworzenia zaplanowanego zadania w chmurze uruchamianego przez cron bez udziału lokalnego komputera. W trybie bez interfejsu klasyczną postacią jest claude -p wewnątrz pętli powłoki z zewnętrzną kontrolą.

Czy pętle zastępują pisanie promptów?

Prompt nie znika — zmienia miejsce. Zapisuje się go raz w specyfikacji pętli, a pętla wywołuje go ponownie; coraz częściej (dynamiczne przepływy pracy, słowa Cherny’ego „to właściwie inny Claude pisze prompty”) prompty do poszczególnych zadań tworzy agent orkiestrujący. Umiejętnością, która zastępuje człowiekowi kunszt tworzenia promptów, jest projektowanie weryfikacji: określanie warunków, które może sprawdzić maszyna lub model z nowym kontekstem.

Czym różnią się pętla, procedura i przepływ pracy w Claude Code?

Pętla (/loop) ponownie uruchamia prompt według harmonogramu wewnątrz lokalnej sesji Claude Code i przestaje się uruchamiać, gdy ten proces kończy działanie; sesja przeniesiona do tła podtrzymuje jej działanie. Zaplanowane zadanie w chmurze (dawniej procedura) to ten sam pomysł przygotowany do działania w infrastrukturze chmurowej: wyzwalany przez cron, API lub zdarzenie GitHub, bez konieczności używania laptopa. Przepływ pracy to graf orkiestracji pojedynczego uruchomienia: skrypt JavaScript tworzony przez Claude, który uruchamia i koordynuje do 1 000 subagents, z pętlami i rozgałęzieniami zapisanymi w kodzie zamiast w kontekście.

Ile kosztują pętle agentów?

Uczciwy zakres to „od zera do ruiny”, a decyduje projekt. Deterministyczne mechanizmy monitorujące nic nie kosztują — to skrypty uruchamiane według harmonogramu. Pętle modelowe są rozliczane za iteracje: należy narzucać im limity (--max-iterations, --max-budget-usd), zapewnić obserwowalność korzyści, aby pętla mogła się zatrzymać, gdy zaczynają maleć, i traktować każdy limit jako regułę zatrzymania, a nie niedogodność. Analizy awarii — tysiące dolarów w jedną noc, 4 mln tokenów w kilka minut — wskazują tę samą przyczynę źródłową: 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 innego albo dwaj agenci modyfikowaliby te same pliki. Pętle obsługują jedno repozytorium i jeden cel; grafy (dynamiczne przepływy pracy, zespoły agentów, zewnętrzne orkiestratory) dodają kolejność wynikającą z zależności, rezerwowanie plików i dyscyplinę scalania. Na grafy należy przechodzić dopiero wtedy, gdy rzeczywiście pojawią się kolizje — dodatkowa struktura wymaga nakładów na obserwowalność i konfigurację.

Historia zmian