Claude Code i Codex Pracują, Kiedy Śpisz (Poradnik Agent Loops)

O czym jest ten film

Skąd wzięła się fala zainteresowania „pętlami agentowymi” — wypowiedź Borisa Cherny’ego z czerwca 2026 i termin loop engineering.
Metafora zmywarki: pętla to ustawienie programu i odejście, a nie dyktowanie każdego ruchu.
Pięć składników dobrej pętli: zapłon, cel, sprawdzian, pamięć, hamulec.
Kluczowa mechanika: o zakończeniu zadania decyduje osobny, mały model — walidator, który widzi wyłącznie to, co agent wydrukował na ekranie.
Komenda /loop — trzy tryby (stały interwał, interwał dobierany przez agenta, tryb z pliku loop.md) i jej realne ograniczenia.
Komenda /goal — warunek końca, limit 4000 znaków, dostępna pod tą samą nazwą w Claude Code i w Codeksie.
Anatomia dobrego kontraktu według dokumentacji OpenAI: wynik, ograniczenia, weryfikacja.
Autorski układ nocny: „brygadzista” (Claude Code, Fable 5) zleca, „fachowiec” (Codex, GPT-5.6) wykonuje, umowa leży w plikach Markdown.
Uczciwy raport z nocy 18/19 lipca 2026: 4,5 godziny pracy, 20 zapisanych zmian, ale też awaria brygadzisty i dwa poważne błędy wyłapane rano.
Odczarowanie mitu: pętle chodzą u autora godzinę do czterech, nie trzy doby, i pracują na gotowym backlogu, a nie na zadaniach wymyślonych przez agenta.

Redakcyjne tłumaczenie

Dlaczego ten materiał w ogóle powstał

W sieci zrobiło się głośno o pętlach agentowych, ale nikt nie wytłumaczył tego w sposób prosty i zrozumiały dla zwykłego śmiertelnika — przynajmniej nie dla mnie. Postanowiłem więc wziąć sprawy w swoje ręce i ogarnąć temat samodzielnie. Z góry zaznaczam: nie jestem inżynierem ani programistą, a mimo to pętle agentowe sprawdzają mi się i oszczędzają masę czasu, bo moje agenty pracują, gdy śpię. I to naprawdę nie jest clickbait.

O pętlach wspominałem przy okazji kilku poprzednich materiałów, ale nigdy nie pokazałem tego od zera. Dziś więc opowiem, czym moim zdaniem są te pętle, jak działają, jak tworzyć dobre pętle i jak możesz wykorzystać tę wiedzę u siebie w Claude Code czy Codeksie. Na końcu pokażę układ, w którym jeden agent zleca, a drugi robi przez całą noc.

Jedno zastrzeżenie na wstępie: jeśli jesteś zaawansowanym użytkownikiem i od miesięcy odpalasz własne pętle, ten materiał może być dla ciebie odrobinę za wolny. Będę tłumaczył wszystko na metaforach, z myślą o osobach kompletnie zielonych, początkujących i średnio zaawansowanych. Widłami rzucać nie trzeba — po prostu skorzystaj z rozdziałów pod filmem i przewiń do interesującej cię sekcji.

Skąd wzięła się cała ta fala

W czerwcu 2026 roku Boris Cherny, czyli człowiek stojący za Claude Code w Anthropicu, powiedział coś, co obiegło internet: że on sam już nie promptuje. Ma pętle, które promptują za niego, a jego robota polega na pisaniu tych pętli. Chwilę później odezwali się ludzie z OpenAI, czyli od Codeksa, a inżynier z Google’a spiął to w termin loop engineering — po ludzku: inżynieria pętli. Stąd cała ta fala.

I tu mam z nią problem: wszyscy twórcy powtarzają to samo zdanie, ale mało kto pokazał, jak złożyć to u siebie i jak realnie wykorzystuje to w praktyce. Dlatego jestem tu dzisiaj z tobą.

Zmywarka zamiast stania nad kucharzem

Zacznijmy od tego, jak być może wygląda twoja współpraca z AI w tej chwili. Jesteś jak ktoś, kto stoi nad kucharzem i dyktuje mu każdy ruch: posól, teraz zamieszaj, dodaj tego, dodaj tamtego, teraz spróbuj. Co pięć minut piszesz „kontynuuj” albo akceptujesz kolejne rzeczy, które pojawiają się w aplikacji, terminalu czy IDE.

Pętla działa odwrotnie. Pomyśl o zmywarce. Nie stoisz nad nią i nie tłumaczysz jej, jak umyć każdy talerz. Ustawiasz program, zamykasz drzwiczki i idziesz spać albo wychodzisz. Rano masz czyste naczynia. Pętla działa dokładnie tak samo — tylko rano zamiast naczyń masz zrobiony kawałek projektu. Też fajnie.

Trzy klocki, z których zbudowana jest każda pętla

Każda pętla, bez wyjątku, składa się z trzech głównych klocków.

Klocek pierwszy: zapłon. Kto odpala pętlę? Robisz to ręcznie? Uruchamia się automatycznie co jakiś czas? A może odpala ją jakieś zdarzenie?

Klocek drugi: cel. Co konkretnie ma zostać zrobione.

Klocek trzeci: sprawdzian. Skąd wiadomo, że to koniec zadania — i, co kluczowe, kto to ocenia.

Zatrzymajmy się przy zapłonie, bo ma dwa rodzaje, i od razu nazwijmy oba narzędzia. Pierwsze to zegar — coś w stylu budzika, który wraca co ileś minut. Drugie to warunek, czyli cel: pętla chodzi, dopóki ten cel nie zostanie spełniony. W Claude Code są to dwie osobne komendy: pierwsza to /loop, druga to /goal.

I tu ważna, uczciwa uwaga: dokumentacja Anthropica traktuje je jako alternatywy. Nie ma jednej składni, która je łączy. To, co pokażę ci na końcu materiału, to mój własny, autorski układ złożony z tych dwóch klocków, a nie jakaś ukryta funkcjonalność.

Cel mierzalny kontra cel uznaniowy

Kolejna ważna rzecz: cel też ma dwa rodzaje. Może być mierzalny — na przykład „wszystkie testy po wdrożeniu zmian w projekcie X muszą świecić się na zielono”. Albo uznaniowy — „rób do momentu, aż będzie ładnie”. Czujesz tę różnicę? Cel uznaniowy to prawie zawsze pętla bez końca, bo skąd model — czy ktokolwiek — ma wiedzieć, co dla ciebie znaczy „ładnie”.

Walidator, czyli egzaminator, który czyta tylko kartkę

A teraz zdanie, które moim zdaniem jest jedną z ważniejszych rzeczy do zrozumienia. Dlatego nieco zwolnię.

Tego, czy cel został osiągnięty, nie ocenia agent, który robi robotę. Ocenia to osobny, mały i szybki model zwany walidatorem. I uwaga: walidator nie odpala żadnych komend i nie zagląda do plików. Widzi wyłącznie to, co agent sam wydrukował na ekranie.

Walidator przypomina egzaminatora, który ocenia tylko to, co jest na kartce podczas kartkówki. Nie zajrzy ci do zeszytu, nie dopyta na korytarzu, nie interesuje go to, co robiłeś w domu. Jeśli twój agent nie wydrukował dowodu, to dla walidatora ten dowód po prostu nie istnieje. Zachowaj tę analogię w głowie — wróci jeszcze kilka razy.

Po co w ogóle ten osobny sędzia? Bo nikt nie powinien sam sobie sprawdzać własnej klasówki. To byłoby bez sensu. Na koniec tej części zapamiętaj: pętla jest tak dobra, jak jej sprawdzian.

Powoli budujemy listę składników dobrej pętli. Pierwszy już znasz: zapłon, czyli to, co odpala pętlę — ty, zegar albo zdarzenie. Reszta listy na razie jest pusta, ale widzisz, że elementów będzie pięć.

Pętla musi móc chodzić długo

Skoro wiesz już, z jakich elementów składa się każda pętla i kto naprawdę orzeka o ukończeniu zadania, musisz też wiedzieć, że pętla ma sens dopiero wtedy, gdy może chodzić długo — godzinami, w nocy. Dokumentacja Anthropica mówi to wprost: taka pętla w sesji żyje tylko dopóki twój komputer jest aktywny i dopóki okno jest otwarte. Czyli albo laptop stoi otwarty do rana, albo…

(Informacja dodatkowa: w tym miejscu w oryginale znajduje się blok sponsorski poświęcony ofercie serwerów VPS partnera kanału. Pomijamy go jako materiał reklamowy niezwiązany z merytoryką odcinka. Sens dla czytelnika: alternatywą dla trzymania otwartego laptopa jest uruchomienie Claude Code czy Codeksa na własnym serwerze VPS, który działa 24/7.)

`/loop` — najprostszy budzik i jego trzy tryby

Zacznijmy od najprostszej pętli, jaka istnieje w Claude Code. To coś, co działa dosłownie jak budzik — i właśnie dlatego, że jest tak głupio proste, większość ludzi używa tego do rzeczy, do których w ogóle się nie nadaje. Komenda nazywa się /loop i ma trzy tryby.

Tryb pierwszy: stały odstęp czasu. Wpisujesz /loop, podajesz czas — na przykład pięć minut, minimum to chyba minuta — i wpisujesz polecenie, czyli prompt. Agent budzi się co pięć minut i wykonuje to polecenie.

Tryb drugi: samo polecenie, bez interwału. Wtedy agent sam dobiera odstęp — od jednej minuty do godziny — i wypisuje go na ekranie wraz z uzasadnieniem, dlaczego wybrał akurat taki. To żadna magia, tylko decyzja z uzasadnieniem, którą możesz przeczytać.

Tryb trzeci: gołe /loop. Po wpisaniu samej komendy agent bierze polecenie z pliku loop.md w katalogu projektu albo w katalogu domowym Claude. Czyli raz spisujesz sobie taki loop.md, opisujesz w nim, co agent ma robić przy każdym zaglądnięciu, i już nigdy tego nie powtarzasz.

Jak to wygląda na żywo

Koniec teorii — jesteśmy w aplikacji desktopowej Claude’a.

Odpalamy pierwszy tryb: wpisuję /loop, pojawia się pole na interwał i prompt. Ustawiam jedną minutę i piszę: „Sprawdź, czy zostały wprowadzone jakieś zmiany w projekcie. Jeśli nie, daj mi znać. Jeśli tak, opisz mi, jakie to zmiany”. Klikam enter — w tym momencie Claude powinien utworzyć crona, czyli zdarzenie, które będzie się odpalać co minutę.

Widzimy: cron create. Mamy prompt, powtarzanie ustawione na true, interwał every minute. Sprawdzam repozytorium. Widać, że cron wygasa po siedmiu dniach; możemy go usunąć przez cron delete. Pojawił się jeden uruchomiony task — po kliknięciu widać, że następne uruchomienie nastąpi za pięć sekund, a całość skończy się za trzy dni. Za chwilę Claude odpala pętlę: stan bazowy zapisany, komunikat „brak zmian”. Za trzydzieści sekund pętla odpaliłaby się znowu, ale ją anulujemy — jedno kliknięcie i Claude ją usuwa.

Teraz drugi tryb. Wpisuję /loop bez podawania czasu i mówię: „Sprawdź aktualny stan projektu, jeśli chodzi o commity na GitHubie. Jeśli są jakieś zaległe rzeczy, zasugeruj push. Jeśli nie — nic nie rób”. Jak widzisz, nie ma tym razem interwału, jest tylko krótki opis. Agent sprawdza, co dzieje się w repozytorium.

(Informacja dodatkowa: o tym, czym jest GitHub i jak robić tam backup projektu, autor mówił w innych materiałach — tu temat jest pominięty.)

Odpowiedź: „Zero niewypchniętych commitów, nic do pusha. Sam ustawię tempo, bez monitora, bo commit to zdarzenie, które i tak zobaczę przy następnym tiku. Kolejne sprawdzenie za około 20 minut”. Znów tworzy się opóźnienie i prompt. Piszę: „Usuń proszę ten loop, jednak go nie chcę” — i tak właśnie możesz zarządzać takimi zdarzeniami, w tym je kasować.

Smaczek: pętlą można odpalać własne skille

Dla tych, którzy mają już własne skille w Claude: /loop potrafi uruchamiać twoje skille.

(Informacja dodatkowa: autor nagrał osobny materiał o tym, czym są skille i jak je budować — link znajduje się w opisie filmu.)

Wpisuję /loop, dwadzieścia minut, i podaję skilla x-radar — to mój skill do przeszukiwania różnych profili na X. Odpalam: pierwszy „skill” to sama komenda loop, drugi to x-radar. Widać, że Claude tworzy crona co dwadzieścia minut z promptem x-radar. Zaplanowane, informacja się pojawia, wszystko działa. Następnie proszę o usunięcie — skasowany, więc mechanika działa tak, jak powinna.

Uczciwie o ograniczeniach `/loop`

Ograniczenia istnieją i warto je znać. Pętla wygasa po siedmiu dniach. Odpala się tylko wtedy, gdy agent jest bezczynny, czyli nie wykonuje innego zadania. Ma rozrzut startu sięgający trzydziestu minut, więc może wystartować różnie. Ma twardy limit zadań, a klawisz Escape przerywa wszystko.

Najważniejsze ograniczenie jest jednak takie, że loop żyje dopóki sesja jest otwarta — dopóki twój komputer jest włączony. Zamkniesz terminal, budzik znika. Właśnie dlatego warto postawić coś takiego na własnym serwerze VPS.

Jeśli jednak chcesz korzystać z tego na komputerze i nie chcesz, by ten się wyłączał, gdy Claude ma coś do zrobienia, jest na to sposób. W aplikacji desktopowej wchodzisz w ustawienia, zakładka Desktop App, a dokładniej General, i tam znajdziesz opcję Keep computer awake — „zapobiegaj usypianiu komputera, gdy Claude jest otwarty, żeby zaplanowane zadania mogły działać; ekran nadal może się wyłączyć, ale zamknięcie klapy laptopa nadal go uśpi”. Czyli: klapa zamknięta — koniec; klapa otwarta, choćby z wygaszonym ekranem — Claude pracuje. Wystarczy zaznaczyć checkbox. Polecam to zrobić, jeśli chcesz pracować z pętlami, bo to niezbędny element, żeby agent mógł działać całą noc.

Do czego budzik nadaje się naprawdę

Konkretna lista, żebyś miał czym się zainspirować:

Pilnowanie, czy coś się zmieniło — na przykład w repozytorium czy w projekcie.
Codzienne przejrzenie zgłoszeń i poukładanie ich według ważności — na przykład sprawdzenie, co masz w kalendarzu, i ułożenie, co kiedy powinno być zrobione.
Sprawdzenie, czy opis projektu nie rozjechał się z tym, co w nim realnie jest — raz dziennie Claude może to zweryfikować.
Przegląd błędów z poprzedniego dnia wraz z propozycją poprawek. To chyba nawet kiedyś polecał Boris Cherny.
Jakiś raport, na przykład co godzinę — tak jak z tym x-radarem, którego przed chwilą tworzyliśmy.

Niezależnie od zadania wspólny mianownik jest jeden: loopem chcemy potraktować wszystkie rzeczy nudne, powtarzalne i takie, których po prostu nie chce się robić ręcznie. Tu pętla zarabia na siebie najszybciej.

Czego natomiast /loop nie wie? Nie wie, kiedy robota jest skończona. On po prostu się budzi, budzi i budzi. Dlatego sam budzik to za mało — i tu wchodzi druga komenda.

`/goal` — pętla, która wie, kiedy skończyć

Czas na pętlę, która doskonale wie, kiedy zakończyć pracę. Całość wygląda niewinnie: jedna komenda w terminalu i jedno zdanie albo kilka zdań. Ale to zdanie decyduje o wszystkim. Pokażę ci dokładnie, czym różni się zdanie, które działa, od zdania, które zapętli twojego agenta na długie godziny i przepali kredyty, limity i tokeny.

Jesteśmy w IDE, z którego korzystam, czyli w Herderze.

(Informacja dodatkowa: Herder to narzędzie pozwalające uruchamiać obok siebie modele różnych dostawców i sprawić, by mogły się ze sobą komunikować. Autor omawiał je w osobnym odcinku.)

Najpierw zmieniam model na Opusa. Potem Shift+Tab i przełączam się na auto mode. To ważne, bo jeśli musiałbyś ręcznie akceptować każdy krok, nie ma sensu puszczać agenta, który ma działać autonomicznie.

Przechodzę do pliku demonstracyjnego. Mamy przykładowy opis filmu, a w nim długie myślniki, tak zwane m dashe, których bardzo nie lubię i które AI notorycznie wstawia w różne miejsca — mam nawet ustawione, żeby tego nie robiło.

Teraz korzystam z /goal. Cel: plik demo ma zawierać zero m dashy. Sprawdzian: komenda grep na tym pliku drukuje dokładnie zero — a więc mamy skrypt, który realnie weryfikuje, czy tych znaków jest zero. To jest mierzalne. Dalej: po każdej turze pokaż na ekranie pełny wynik tej komendy oraz listę zmienionych linii. Zakładam, że tura będzie jedna. Ograniczenia: każdy m dash zamień na zwykły łącznik, niczego innego w pliku nie zmieniaj i nie ruszaj żadnych innych plików. I rzecz ważna — hamulec: maksymalnie pięć tur; jeśli po trzech turach wynik grepa nie spada, zatrzymaj się i napisz raport z powodem.

Klikam enter — cel jest aktywny od sekundy. Jeśli wpiszesz ponownie /goal, zobaczysz status celu, a /goal clear go czyści. My tego nie robimy — zobaczmy, co się stanie.

Cel osiągnięty w pierwszej turze. Wynik grepa, zmienione linie: trzy podmiany. W tekście widać, że tam, gdzie były długie pauzy, są teraz krótkie łączniki. Żaden inny plik nie został zmodyfikowany. Cel osiągnięty, jedna tura, podana liczba tokenów i czas: dwadzieścia dziewięć sekund pracy.

To bardzo prosty przykład, ale mam nadzieję, że rozumiesz już, o co chodzi. Podsumowując: wpisaliśmy /goal i w jednym zdaniu podaliśmy wszystko — komendę do sprawdzenia, dokładny oczekiwany wynik (zero m dashy), polecenie „pokaż wynik po każdej turze”, żeby egzaminator, czyli walidator, miał co czytać z kartki, opis tego, czego nie wolno ruszać, oraz hamulec w postaci maksymalnie pięciu tur. Walidator zobaczył zero m dashy, uznał, że się zgadza, i powiedział: koniec.

Mechanika `/goal` w pigułce

Wpisujesz /goal i warunek. Jeden cel na sesję — chociaż to da się nieco obejść dzięki pętlom agentowym, o czym zaraz. Całość od razu ustawia pierwszą turę, a na pasku widzisz, że pętla jest aktywna. Sam warunek może mieć do 4000 znaków, zarówno w Claude, jak i w Codeksie, więc spokojnie zmieścisz w nim całą listę. Samo /goal pokazuje status, a /goal clear wyłącza cel. Jeśli potrzebujesz upchnąć więcej treści, możesz odwoływać się do plików Markdown na dysku — Claude czy Codex je przeczytają, a odwołanie zmieści się w limicie. To dobra praktyka.

I teraz rzecz, która jest sednem tego materiału, a nie ciekawostką: ta sama komenda /goal jest dostępna pod tą samą nazwą zarówno w Claude, jak i w Codeksie — zarówno w aplikacji na komputerze, jak i w wersji terminalowej. W aplikacji desktopowej Claude’a wpisujesz /goal i masz swój cel. W Codeksie również wpisujesz /goal — cel się włącza; możesz też kliknąć plusik i wybrać go stamtąd. W obu przypadkach obowiązuje limit 4000 znaków. Wniosek jest taki, że nie uczysz się funkcji jednego narzędzia, tylko wzorca, który obie firmy opisują tak samo.

Ciekawostka druga: /goal pojawiło się najpierw w Codeksie.

Kontrakt spisany przed robotą

Obie dokumentacje — Anthropica i OpenAI — mówią jedno: najważniejszy jest kontrakt spisany, zanim agent zabierze się do roboty. Przepis podawany przez OpenAI jest trzyczęściowy:

Wynik — co ma być zrobione, co ma być efektem pracy agenta.
Ograniczenia — czego nie wolno robić: dotykać innych plików, wywoływać płatnych wywołań API i tak dalej.
Weryfikacja — jak walidator sprawdzi, że to faktycznie zostało zrobione.

Po ludzku: co ma być, czego nie wolno i jak to sprawdzimy. Pomyśl o tym trochę jak o protokole odbioru mieszkania spisanym przed remontem. Lista punktów, każdy z konkretnym sprawdzianem. Ekipa remontowa nie może w połowie stwierdzić, że umawialiście się inaczej.

Zły kontrakt kontra dobry kontrakt

Zły warunek brzmi tak, jak mówiliśmy na początku: „popraw, aż będzie dobrze”, „zrób tak, żeby było ładnie”. Nikt nie wie, co znaczy „dobrze”, nikt nie wie, co znaczy „ładnie”, więc pętla nie ma jak się zakończyć.

Dobry warunek ma konkretną komendę do odpalenia — na przykład „uruchom wszystkie testy” — plus dokładny wynik: „zadanie jest spełnione, kiedy 3100 z 3100 testów przechodzi na zielono”. Plus polecenie: „pokaż wynik na ekranie po każdej turze”, żebyś mógł zobaczyć, co się zadziało.

I tu wraca nasz egzaminator z pierwszej części. Walidator czyta tylko kartkę, czyli to, co dzieje się w oknie rozmowy. Dlatego warunek musi być czymś, co agent sam może wydrukować na ekranie. Jeśli dowód siedzi wyłącznie w pliku albo w głowie agenta, sędzia go nie zobaczy i pętla będzie kręcić się dalej.

Do tego samego zdania wpisujesz dwa bezpieczniki: twardy limit („zatrzymaj się po X turach”) i wyjście awaryjne („jeśli ten sam błąd wystąpi trzy razy pod rząd, zatrzymaj się i zdaj raport”). Bez tego pętla potrafi tłuc głową w mur do rana, a ty przepalisz mnóstwo limitów i tokenów.

I fakt praktyczny, o którym mało kto mówi: /goal nie zmienia uprawnień agenta. Jeśli nie masz włączonego trybu automatycznego albo bypass permissions, pętla stanie na pierwszym pytaniu o zgodę i będzie grzecznie czekać, aż wrócisz. Jest na to sposób, ale nie w samym /goal — zaraz do niego przejdziemy. Chodzi o to, żebyś zrozumiał: sam cel to jeszcze nie pozwolenie na działanie.

Skill, który pisze zlecenie za ciebie

Żebyś nie myślał, że jestem takim mózgiem, który za każdym razem ręcznie wymyśla, jak sformułować prompta do /goal — nie piszę go z głowy. Mam swój autorski skill goloop: warunek końca składa mi w zasadzie Claude Code z gotowego szablonu. Dzięki temu nie zapominam ani o sprawdzianie, ani o hamulcu. Nie muszę się nad tym zastanawiać, po prostu wiem, że będzie zrobione.

Opis tego skilla brzmi tak: goloop nie pracuje — on pisze zlecenie pracy. Wyobraź sobie, że chcesz zlecić robotę wykonawcy na noc, kiedy ciebie nie ma. Nie wystarczy powiedzieć „ogarnij to”. Trzeba napisać zlecenie: co ma być zrobione, po czym poznamy, że jest gotowe, czego absolutnie nie wolno ruszać i kiedy przerwać, jeśli coś nie idzie. Czyli nasz kontrakt. Goloop to skill, który pisze takie zlecenia za ciebie i daje ci je do zatwierdzenia. Sam nic nie odpala — zatrzymuje się i czeka na twoje „OK”.

Dlaczego to w ogóle jest potrzebne? Mechanizm /goal w Claude Code wygląda tak: podajesz warunek końca, Claude startuje kolejne tury, dopóki go nie spełni, a po każdej turze mały, szybki model — walidator — czyta rozmowę i orzeka: gotowe albo nie. Haczyk, który psuje wszystko: ten sędzia nie umie niczego sprawdzić samodzielnie. Nie uruchamia komend, nie zagląda do plików, widzi tylko to, co Claude sam wypisał na ekranie. Dlatego warunek „aż nie będzie bugów” nigdy się nie skończy — sędzia nie ma jak tego odczytać. Ale warunek „testy wypisują zero failów” da się odczytać, bo Claude tę linijkę pokazuje. Cała wartość skilla to zapisana wiedza o tym, jak formułować warunki, które da się odczytać, żeby nie wymyślać tego od zera przy każdym zadaniu.

Skilla stworzyłem na podstawie dokumentacji Anthropica, dokumentacji Codeksa, kilku materiałów na YouTubie i własnych przemyśleń.

(Informacja dodatkowa: autor udostępnia ten skill członkom swojej płatnej społeczności; link znajduje się w opisie filmu.)

Wracamy do naszej listy. Składnik drugi to cel — mierzalny, nie „ładnie”. I od razu składnik trzeci: sprawdzian — kto ocenia i po czym poznasz, że zadanie jest ukończone. W tym momencie masz już budzik (/loop), masz warunek i masz sprawdzian, który umieszczasz w komendzie /goal. Tylko że to wszystko jest jednym agentem w jednym oknie.

Nocna zmiana: brygadzista i fachowiec

A teraz pokażę ci, co się dzieje, kiedy te dwa proste klocki złożysz w jedną nocną zmianę, w której jeden agent zleca, a drugi robi. Przechodzimy do właściwych pętli agentowych.

Uwaga: nie będę cię przeprowadzał przez całą architekturę, bo sam się w niej na początku mocno gubiłem. Pokażę tylko, jak to z grubsza działa i jak wygląda naprawdę — bo to nie jest teoria. To chodzi u mnie w tle, dosłownie chodziło przed chwilą, żeby ci to pokazać. Korzystam z tego przy budowie swojej aplikacji do generowania miniaturek na YouTube, mimo że nie jestem programistą i nie potrafię kodować. Często puszczam to w nocy.

U mnie w nocy pracuje zwykle dwóch agentów.

Pierwszy to brygadzista — Claude Code z modelem Fable 5, najczęściej na średnim poziomie wysiłku. Zleca robotę, odpowiada na ewentualne pytania i pilnuje, czy wszystko idzie zgodnie z planem.

Drugi to fachowiec — u mnie najczęściej Codex, konkretnie model GPT-5.6 na średnim albo wysokim wysiłku, który po prostu robi.

Brygadzista, czyli Claude Code, siedzi w pętli budzika (/loop), którą już doskonale znasz, i co pięć minut zagląda na budowę. Fachowiec dostaje cel (/goal), który też już znasz. Umowa między nimi — kontrakt — i lista zadań leżą w zwykłych plikach Markdown, po to, żeby nikt niczego nie musiał pamiętać i żebym ja rano przeczytał wszystko w dwie minuty.

Codex odpala się u mnie z odciętym dostępem do sieci, w tak zwanym sandboksie — płatne akcje i wysyłanie czegokolwiek na zewnątrz fizycznie nie mają którędy wyjść. Chodzi o bezpieczeństwo, skoro ma działać autonomicznie.

Tyle teorii — serio, tyle ci wystarczy. Takiego skilla możesz zbudować bezpośrednio z Claude’em: jeśli wiesz, jak to działa, i potrafisz to opisać, powinien sobie poradzić. Ja też go nie składałem sam — poprosiłem o to Claude’a. /loop znasz z sekcji o budziku, /goal z sekcji o warunku; u mnie skleja je jeden skill o nazwie goloop. Mówię mu po ludzku, co ma być zrobione w nocy, a on sam pisze cel ze sprawdzianem i hamulcem oraz ustawia pętlę nadzoru. Cała wiedza z tego materiału jest w tego skilla wbudowana.

Jak to wygląda w praktyce

Idealny przykład. Zmieniłem model na Fable. Po lewej stronie mam Claude’a, po prawej Codeksa. Napisałem mniej więcej tak: „Chciałbym, żebyś zobaczył backlog, czyli listę zadań, i powiedział mi, co jest do zrobienia — czy mamy do tego specyfikację i tickety. Jeśli tak, super; jeśli nie, stwórz. Następnie chciałbym, żebyś skorzystał ze skilla goloop, zaplanował pracę dla Codeksa, który jest otwarty w drugim oknie Herdera, i zlecił mu te zadania. Oczywiście przypilnuj go loopem co pięć minut, żebyś mógł zaakceptować, dać feedback albo sprawdzić, czy wszystko działa”.

Widać, że Claude odpalił Codeksa, a ten pracował w pętli. Kiedy coś było do zrobienia, Claude odpalał się co pięć minut, mógł zaakceptować albo dać feedback, jeśli był potrzebny. Całość się zakończyła: cztery na cztery tickety rozwiązane, bramki przeszły na zielono, zero płatnych wywołań. Trwało to dwadzieścia dwie minuty.

Najdłuższa pętla u mnie trwała cztery i pół godziny w nocy. Była podzielona na kilka etapów, kilka tur. Co najciekawsze, Claude na bazie backlogu miał ustawiony loop, sprawdzał, co jest do zrobienia, i tworzył po jednym goloopie do jednego zadania — potem drugi, trzeci, i tak cztery razy. Skill goloop działa właśnie tak: Claude nie tylko sprawdza, co robi Codex, ale też, gdy tamten skończy i my na to pozwolimy, może sam wejść do backlogu, wybrać zadanie, stworzyć specyfikację, napisać nowy cel dla Codeksa i go odpalić — i tak w kółko.

Zauważyłem, że najlepiej sprawdza się, gdy agenty pracują godzinę czy dwie, bo przy czterech pojawia się sporo błędów i ciężko mi to potem ogarnąć. Mogą chodzić długo, praktycznie bez limitu poza limitami samych narzędzi, ale ja preferuję krótsze pętle — godzinę, dwie — gdy idę spać albo wychodzę z domu.

Składnik czwarty: pamięć

Na podstawie tego wszystkiego dochodzimy do składnika numer cztery: pamięć. Czyli plik, który leży na moim dysku, a nie w głowie agenta, i ma opisane wszystko, co zostało zrobione i co jest do zrobienia. Dzięki temu nawet jeśli coś padnie w nocy, robota idzie dalej.

Uczciwy raport z jednej nocy

Odpowiedzmy sobie teraz uczciwie, co z takiej nocy naprawdę wychodzi. Przykład z nocy z 18 na 19 lipca 2026, ta trwająca około czterech i pół godziny. Odpaliłem agenty około 22:07, poszedłem spać, a ostatni wpis od agentów widziałem o 2:31 w nocy. Wyszło mniej więcej cztery i pół godziny pracy, dwadzieścia zapisanych zmian, zero wydanych złotych — bo wszystko szło w ramach planów Claude Code i Codeksa — a na koniec komplet testów na zielono.

Muszę jednak powiedzieć o trzech rzeczach, bo bez nich te liczby to czysty marketing.

Po pierwsze: rano i tak robię przegląd tego, co zrobiły agenty. Z reguły każę drugiemu agentowi spojrzeć na robotę pierwszego i zaudytować ją krytycznym okiem — Fable 5 sprawdza zwykle Codeksa. Tamtego ranka wyłapał dwie poważne rzeczy. Nocna pętla nie zwalnia cię z myślenia rano. Trzeba to przejrzeć — samemu albo zlecając przegląd agentowi — i poprawić, bo wpadki się zdarzają. To normalne.

Po drugie: o 2:45 padł mi brygadzista, czyli Claude Code po prostu przestał działać. Dobra wiadomość jest taka, że Codex pracował dalej — bo nasz kontrakt nie mieszkał w pamięci sesji Claude’a, tylko w plikach. To jest właśnie ta pamięć, o której mówiłem, przetestowana na żywo.

Po trzecie — i to chyba moja ulubiona rzecz — dwa zadania z listy okazały się zrobione wcześniej i pętla tego nie ukryła. Dostałem komunikat, że nie ma czego robić, i jasne dowody, że tak faktycznie jest. Agenty nie udawały zajętych i nie robiły czegoś dla sztuki.

A rano czytam przy kawie raport. Dwie minuty czytania zamiast czterech godzin przewijania rozmowy między Claude’em a Codeksem. Mamy raport z nocy, łańcuch czterech epików, role: dyspozytor, walidator, audytor, wykonawca, a nawet Kimi K3 jako konsultant designu.

(Informacja dodatkowa: Kimi K3 to model innego dostawcy, uruchamiany obok Claude’a i Codeksa w Herderze.)

W raporcie jest też uwaga procesowa: koordynator był zablokowany awarią klasyfikatora komend, nie Codeksa; kod był gotowy o 2:31. Całość mam dokładnie opisaną — rano widzę, co się działo i jakie były problemy.

Odczarujmy pętle agentowe

U mnie takie pętle nie chodzą trzy dni ciągiem, jak na zagranicznych filmach na YouTubie. Chodzą od godziny do czterech, przy czym jedna–dwie sprawdzają się najlepiej.

Nie robię też tak, że puszczam agenta i mówię, żeby w ramach pętli sam wymyślał sobie zadania. Agenty robią robotę, którą i tak trzeba by zrobić, tylko bez klikania „enter” co pięć minut. Mam backlog z konkretnymi rzeczami i na jego podstawie pracujemy. Nie mówię: „Ej, wymyślcie sobie zadanie, róbcie”. To wygląda inaczej.

Jedno zdanie do zapamiętania z tej sekcji: pętla bez sprawdzianu to maszyna, która z pełnym przekonaniem produkuje błędy.

Składnik piąty: hamulec

Czas na ostatni składnik: hamulec, czyli to, co zatrzyma pętlę, gdy coś pójdzie źle. Limit tur, wyjście awaryjne po powtarzającym się błędzie, odcięta sieć zamiast obietnicy.

I te pięć elementów — zapłon, cel, sprawdzian, pamięć, hamulec — składa się na kompletną pętlę agentową. Zatrzymaj sobie ten kadr, możesz zrobić zrzut ekranu; prezentację też podlinkuję w opisie.

Zapamiętaj:

Zapłon — to, co odpala pętlę: ty, zegar albo zdarzenie.
Cel — to, co ma zostać zrobione. Musi być mierzalne. Nie „ładnie”, nie „dobrze”.
Sprawdzian — kto ocenia i po czym pozna, że zadanie jest zrealizowane. Walidator widzi tylko kartkę, czyli ekran rozmowy. Nie zagląda do plików ani do pamięci drugiego agenta.
Pamięć — gdzie zapisane jest to, co już zrobiono. W formie pliku na twoim komputerze, a nie w głowie agenta.
Hamulec — co zatrzyma pętlę, gdy coś pójdzie źle.

To nie jest żadna magia z filmów wielkich guru. To od jednej do czterech godzin roboty w nocy i raport przy kawie rano.

Polecam ci zacząć od jednego zadania, które da się zmierzyć, i napisać do niego warunek końca — tak, żeby agent musiał wydrukować dowód na ekranie. Nic więcej. Reszta to już tylko dokładanie klocków i łączenie mechanik ze sobą.

Daj mi znać w komentarzu, jakie zadanie puścisz w pętli jako pierwsze. Chętnie zobaczę, sprawdzę, może coś nawet podpowiem.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Pętla to zmywarka, a nie kucharz pod nadzorem

Na czym polega: Zamiast dyktować agentowi każdy ruch i co pięć minut pisać „kontynuuj”, definiujesz program: co ma być zrobione i po czym poznamy koniec — a potem odchodzisz.

Jak stosować: Wybierz zadanie, przy którym najczęściej klikasz „enter” bez wnoszenia treści. To pierwszy kandydat na pętlę.

Na co uważać: Metafora działa tylko wtedy, gdy program da się precyzyjnie ustawić. Zadania, których nie umiesz opisać jako warunku końca, nadal wymagają twojej obecności.

2.Każda pętla to pięć składników: zapłon, cel, sprawdzian, pamięć, hamulec

Na czym polega: To lista kontrolna kompletnej pętli. Brak któregokolwiek elementu psuje całość — najczęściej po cichu.

Jak stosować: Zanim odpalisz cokolwiek na noc, przejdź listę punkt po punkcie i dopisz brakujące elementy do promptu lub plików projektu.

Na co uważać: Najczęściej pomijane są pamięć i hamulec, bo przy krótkich testach nie widać ich braku. Ujawniają się dopiero przy pętli działającej godzinami.

3.Walidator widzi tylko to, co agent wydrukował na ekranie

Na czym polega: O ukończeniu celu decyduje osobny, mały model, który nie uruchamia komend i nie zagląda do plików. Czyta wyłącznie treść rozmowy.

Jak stosować: Do każdego warunku dopisz jawnie: „po każdej turze pokaż na ekranie pełny wynik komendy X”. Dowód musi trafić na kartkę.

Na co uważać: Warunki typu „aż nie będzie bugów” albo „aż plik będzie poprawny” nigdy się nie zakończą — walidator nie ma jak tego odczytać, a pętla kręci się i pali limity.

4.Cel musi być mierzalny komendą, nie odczuciem

Na czym polega: „Zero m dashy, potwierdzone wynikiem grepa” albo „3100 z 3100 testów na zielono” działa. „Aż będzie ładnie” to gwarantowana pętla bez końca.

Jak stosować: Do każdego celu dopisz konkretną komendę weryfikującą i dokładny oczekiwany wynik liczbowy lub tekstowy.

Na co uważać: Nawet mierzalny warunek bywa zwodniczy — testy mogą świecić się na zielono przy złej implementacji. Mierzalność to warunek konieczny, nie wystarczający.

5.`/loop` to budzik — dobry do nudy, bezużyteczny do zakończenia zadania

Na czym polega: Trzy tryby: stały interwał, interwał dobierany przez agenta z uzasadnieniem, oraz gołe /loop czytające prompt z pliku loop.md.

Jak stosować: Wrzucaj tam monitoring repozytorium, porządkowanie zgłoszeń, dzienny przegląd błędów, cykliczne raporty. Powtarzalne, nudne, tanie.

Na co uważać: Pętla wygasa po siedmiu dniach, odpala się tylko gdy agent jest bezczynny, ma rozrzut startu do trzydziestu minut i nie wie, kiedy robota jest skończona.

6.`/goal` to ten sam wzorzec w Claude Code i w Codeksie

Na czym polega: Komenda o tej samej nazwie, z tym samym limitem 4000 znaków, działa w obu narzędziach — w wersji desktopowej i terminalowej. Historycznie pojawiła się najpierw w Codeksie.

Jak stosować: Ucz się wzorca kontraktu, nie funkcji jednego produktu. Warunek napisany dla Claude’a przenosisz do Codeksa niemal bez zmian.

Na co uważać: Obowiązuje jeden cel na sesję, a limit 4000 znaków bywa ciasny — dłuższe specyfikacje wynieś do plików Markdown i odwołuj się do nich z warunku.

7.Kontrakt: wynik, ograniczenia, weryfikacja

Na czym polega: Trzyczęściowy przepis z dokumentacji OpenAI — co ma być, czego nie wolno, jak to sprawdzimy. Spisany zanim agent zacznie pracę.

Jak stosować: Traktuj to jak protokół odbioru mieszkania przed remontem. Sekcja „czego nie wolno” jest równie ważna jak cel: nie ruszaj innych plików, nie wywołuj płatnych API.

Na co uważać: Ograniczenia zapisane w kontrakcie to deklaracja, nie zabezpieczenie. Realną barierą jest sandbox z odciętą siecią, a nie zdanie w promptcie.

8.`/goal` nie nadaje uprawnień — bez trybu automatycznego pętla stanie na pierwszym pytaniu

Na czym polega: Cel steruje tym, kiedy skończyć, ale nie tym, co agent może zrobić bez pytania. Bez auto mode agent grzecznie czeka na twoją zgodę.

Jak stosować: Przed nocnym uruchomieniem przełącz się na tryb automatyczny (Shift+Tab w Claude Code) i osobno zabezpiecz zakres uprawnień.

Na co uważać: Autonomia bez sandboxa to realne ryzyko. Autor puszcza Codeksa z odciętym dostępem do sieci właśnie po to, by płatne akcje i wycieki danych nie miały którędy wyjść.

9.Układ dwóch agentów: brygadzista zleca, fachowiec robi, kontrakt leży w plikach

Na czym polega: Claude Code w pętli /loop co pięć minut nadzoruje Codeksa pracującego na /goal. Lista zadań i kontrakt są w plikach Markdown, nie w pamięci sesji.

Jak stosować: Trzymaj backlog i stan prac na dysku. Dzięki temu drugi agent kontynuuje pracę nawet gdy nadzorca padnie — u autora tak właśnie było o 2:45 w nocy.

Na co uważać: To autorski układ złożony z dwóch niezależnych komend, a nie oficjalna funkcja. Dokumentacja Anthropica traktuje /loop i /goal jako alternatywy.

10.Jedna–dwie godziny działają lepiej niż cztery, a rano i tak trzeba zrobić audyt

Na czym polega: Przy dłuższych sesjach narasta liczba błędów trudnych do rozplątania. Po nocnej pętli autor każe drugiemu agentowi krytycznie zaudytować pracę pierwszego.

Jak stosować: Puszczaj pętlę na czas snu lub wyjścia z domu, ale ogranicz zakres do backlogu, który i tak trzeba zrobić. Rano czytaj raport, nie transkrypt rozmowy.

Na co uważać: Nie pozwalaj agentowi wymyślać sobie zadań w pętli. I nie traktuj zielonych testów jako końca pracy — w opisywanej nocy audyt wyłapał dwie poważne rzeczy mimo kompletu testów na zielono.