Projektowanie pętli agentów, które działają, gdy śpisz

7 czerwca 2026 Peter Steinberger — twórca OpenClaw, repozytorium z największą liczbą gwiazdek w historii GitHuba — opublikował kilka słów, które w dzień zebrały miliony wyświetleń: „Nie powinieneś już promptować agentów kodujących. Powinieneś projektować pętle, które promptują Twoje agenty.” Odpowiedzi zamieniły się w bójkę. Mniej więcej czterech na dziesięciu nazwało to kolejną warstwą abstrakcji; reszta nazwała to cronem w kapeluszu.

Oba obozy przegapiły sedno, które jest mniejsze i bardziej użyteczne niż jedno i drugie. Zmiana, którą opisał Steinberger, to nie nowa technologia. To zmiana tego, gdzie kładziesz ręce. Zamiast siedzieć na krześle i wpisywać następną instrukcję, piszesz program, który decyduje, jaka ma być następna instrukcja — a potem idziesz spać, gdy on działa. Boris Cherny, który kieruje Claude Code w Anthropic, ujął to wprost: „Już nie promptuję Claude’a. Mam działające pętle. To one promptują Claude’a.”

Kilka tygodni później Addy Osmani z Google nadał temu instynktowi nazwę — loop engineering — i ta nazwa się przyjmuje. Ten post jest o tym, jak właściwie zbudować jedną z takich pętli i jak nie dopuścić, by po cichu podpaliła Twój budżet tokenów o trzeciej nad ranem.

Cykl w centrum

Zdejmij narzędzia, a każda autonomiczna pętla to te same cztery uderzenia, obracające się raz za razem, aż cel zostanie osiągnięty:

Perceive → Reason → Act → Observe (Postrzegaj → Rozumuj → Działaj → Obserwuj).

Agent postrzega swój bieżący stan (zadanie, pliki, ostatni wynik), rozumuje, co zrobić dalej względem celu, działa, uruchamiając narzędzie — polecenie powłoki, edycję pliku, wywołanie API — a potem obserwuje, co wróciło. Ta obserwacja staje się następnym postrzeżeniem i pętla obraca się znowu. Osmani nazywa to „metodą naukową zastosowaną do programowania”: postaw hipotezę, przeprowadź eksperyment, odczytaj wynik, popraw. Inteligencja jest w modelu; autonomia jest w cyklu.

To ta sama pętla, którą rozłożyliśmy w Wnętrzu pętli agenta. Nowością w ujęciu loop engineering jest wysokość. Prompt engineering dostraja pojedynczą turę. Harness engineering dostraja środowisko, w którym działa jeden agent. Loop engineering siedzi piętro nad harness: projektuje program, który prowadzi agenta przez setki tur bez Ciebie na krześle.

Co obraca pętlę, gdy śpisz

Pętla działająca bez nadzoru potrzebuje trzech rzeczy, których nie potrzebuje sesja czatu.

• Wyzwalacz (trigger). Coś musi uruchomić pętlę bez naciskania przez Ciebie entera — harmonogram cron, nowa etykieta zgłoszenia, nieudany przebieg CI, webhook. Wyzwalacz jest tym, co odłącza pracę od Twojej klawiatury. To dosłowna różnica między agentem, którego nadzorujesz, a takim, który działa przez całą noc.
• Weryfikowalny cel. „Zrób to lepiej” nie jest celem, na którym pętla może działać; „wszystkie testy przechodzą, a linter jest czysty” — jest. Pętla potrzebuje warunku, który może sprawdzić sama, mechanicznie, w każdej turze — bo Ty śpisz i nie możesz być tym, kto sprawdza. Niedoprecyzowane cele to przyczyna numer jeden pętli, które się kręcą bez zbieżności.
• Podział maker/checker. Najbardziej niezawodne pętle oddzielają agenta, który pisze, od agenta — albo zestawu testów, albo bramki CI — który weryfikuje. Jeden proponuje, inny zatwierdza. Model oceniający własną pracę domową to sposób, w jaki pewny siebie nonsens trafia na produkcję.

Daj pętli te trzy rzeczy, a naprawdę będzie mogła działać, gdy śpisz. Pytanie nie brzmi już, czy może działać bez nadzoru — brzmi, czy zaufasz temu, co znajdziesz rano.

Guardrails to jest ta inżynieria

Oto część, którą obóz „to tylko cron” rozumie źle. Każdy potrafi owinąć model w pętlę while. Różnica między loop engineering a uruchamianiem pętli leży w całości w guardrails — kodzie, który decyduje, kiedy przestać. Bez nich pętla nie zawodzi z gracją; zawodzi kosztownie. Uber nauczył się tego boleśnie i ograniczył inżynierów do 1500 USD na narzędzie miesięcznie po spaleniu rocznego budżetu AI w cztery miesiące.

Każda pętla, którą puszczasz bez nadzoru, potrzebuje wszystkich z tych, nie tylko niektórych:

• Twardy limit iteracji. Maksymalna liczba cykli, koniec. Pętle krążące między dwiema poprawkami — z których każda psuje to, co naprawiła poprzednia — będą to robić w nieskończoność, jeśli im pozwolisz.
• Budżet tokenów i kosztu. Twardy pułap na przebieg. Gdy zostanie osiągnięty, pętla się zatrzymuje, nawet w połowie zadania. To guardrail, który chroni Cię przed obudzeniem się z czterocyfrowym rachunkiem.
• Wykrywanie braku postępu. Jeśli wynik nie zmienił się znacząco przez N tur, pętla utknęła. Wyjdź i eskaluj, zamiast spalić kolejne sto tur, dreptając w miejscu.
• Bezpieczniki na narzędziach. Limit ponowień na każde wywołanie narzędzia, żeby jedno niestabilne API nie stało się nieskończoną burzą ponowień.
• Punkt kontrolny człowieka dla działań nieodwracalnych. Usuwanie danych, wypychanie na produkcję, wysyłanie maila — to czeka na człowieka, nawet w skądinąd autonomicznej pętli. Resztę umieść w sandboxie, żeby rozbiegany agent nie zniszczył systemu plików.

Zauważ, że żadne z tych nie czyni agenta mądrzejszym. Czynią go bezpiecznym do zostawienia samego — a to jest cała propozycja. Pętla, którą musisz niańczyć, nie jest pętlą; to sesja czatu z dodatkowymi krokami.

Dlaczego to ma większe znaczenie w Azji Południowo-Wschodniej

Kusi, by czytać to wszystko jako zmartwienie frontierowych laboratoriów. Jest odwrotnie. Loop engineering to najbardziej dostępna umiejętność o wysokiej dźwigni we współczesnym AI, a ta asymetria sprzyja dokładnie tym programistom, których wciąż się spisuje na straty.

Dobrze zaprojektowana pętla to mnożnik siły na czasie i nie obchodzi jej, w której strefie czasowej jesteś. Dwuosobowy zespół w Phnom Penh czy Da Nang, który projektuje dobre pętle, może wypchnąć pracę znacznie większego zespołu — bo pętle działają przez noc, w weekend, w święta, gdy zespół śpi. Eksperyment AutoResearch Andreja Karpathy’ego przeprowadził 700 eksperymentów w dwa dni na pojedynczym GPU; nie dostajesz tego z dobrego promptu, dostajesz z dobrej pętli. Ta dźwignia jest dostępna dla każdego, kto rozumie cykl i guardrails, i nie kosztuje nic poza inżynierią.

A loop engineering to inżynieria — weryfikowalne cele, obsługa błędów, projektowanie testów, dyscyplina kosztowa, staranne myślenie systemowe. Nic z tego nie wymaga trenowania frontierowego modelu. Wymaga dobrych programistów, którzy rozumieją problem na tyle głęboko, by zakodować „co znaczy gotowe?” w sprawdzeniu, które wykona maszyna. Azja Południowo-Wschodnia ma takich programistów w rosnącej liczbie, wychodzących z instytucji takich jak RUPP i ITC w Kambodży oraz w całym regionie. Model jest wynajmowany z Kalifornii po stałej stawce; pętla, która go owija — dostrojona do Twojej domeny, Twojego repozytorium, Twojej definicji gotowości — jest Twoja i to w niej siedzi trwała wartość.

Od czego zacząć

Wybierz jedno zadanie, które robisz cyklicznie i którego nie znosisz — triaż nowych zgłoszeń, aktualizacja zależności, utrzymywanie changeloga. Zapisz, jak wygląda „gotowe”, jako sprawdzenie, które wykona maszyna. Podłącz do tego wyzwalacz. Dodaj guardrails zanim dodasz ambicję: limit iteracji, pułap kosztu, wyjście przy braku postępu. Potem pozwól mu raz zadziałać, gdy patrzysz, i raz, gdy nie patrzysz.

Kilka słów Steinbergera tak naprawdę nie było o agentach kodujących. Były o tym, gdzie przeniosła się dźwignia. Przeniosła się z promptu do pętli — a pętla działa, gdy śpisz. Zbuduj pętlę.