O czym jest ten film
- W środowisku agentów AI pojawiło się nowe modne słówko: „loop engineering”, czyli inżynieria pętli — zamiast ręcznie promptować agentów, projektuje się pętle, które robią to za nas. Modę rozkręcają Peter Steinberger (OpenClaw) i Boris Cherney (Claude Code).
- Hasło Borisa: „Nie promptuję już Claude. Piszę pętle, a pętle robią robotę. Moją pracą jest pisanie pętli”.
- Podstawy są proste i sprowadzają się do trzech mechanizmów Claude Code i Codexa:
/loop(cykliczne wybudzanie agenta),/goal(praca do spełnienia kryteriów zakończenia) i/routines(zaplanowane zadania). - W praktyce wystarczy wręczyć agentowi dokument ze specyfikacją i poprosić o użycie wbudowanej umiejętności loop — orkiestrator sam układa pętlę, sam pisze prompty i odhacza zadania po kolei.
- Problem pierwszy: autor nie wierzy, że pętle dają najlepsze możliwe wyniki; sceptycznie odnosi się do zapewnienia, że asystentka Borisa nadzoruje dziesiątki tysięcy agentów naraz.
- Problem drugi: koszty — jedno uruchomienie, które zbudowało stosunkowo prostą aplikację, kosztowało ponad milion tokenów, bo orkiestrator raz po raz rozumuje nad specyfikacją i nad wynikami „pracowników”.
- Problem trzeci: pętla ciągnąca się w jednej sesji przepełnia kontekst modelu; potrzebne jest rozproszenie pracy na osobne sesje, które wiedzą, gdzie są w większym celu.
- Rozwiązanie autora — jego narzędzie Arkon: proces zapisany deterministycznie w pliku workflow, osobny dobór modelu do każdego kroku (z możliwością mieszania dostawców), trwałość w Postgresie na Neonie i punkty zatwierdzane przez człowieka.
- Demonstracje: cztery issue z GitHuba naprawiane równolegle w izolowanych work trees, z osobnymi sesjami do review; potem autorski dashboard dla „czystej” inżynierii pętli, napędzany tańszym modelem Kimi K2.7.
- Dashboard można wystawić w chmurze przez Retool (grupy uprawrawnień, ścieżka audytowa). Wniosek autora: loop engineering należy wchłonąć w szerszy „harness engineering”, a nie tworzyć z niego osobnej dyscypliny.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Pętla to narzędzie do wąskich zastosowań, a nie religia
Na czym polega: Największe nazwiska branży sugerują, że przyszłością jest nadzorowanie dziesiątków tysięcy agentów jednocześnie. Autor po własnych testach uważa, że pętle świetnie sprawdzają się w ściśle kontrolowanych systemach, do prototypów i sprawdzania pomysłów — ale nie jako napęd całego kodowania.
Jak stosować: Automatyzuj powtarzalne, dobrze zdefiniowane czynności: obsługę issue, walidacje, przeglądy kodu. Pracę wymagającą przemyślanego kierunku zostaw sobie.
Na co uważać: Skala rodzi chaos — przy setkach równoległych agentów trudno o jakość, a rachunek za tokeny przychodzi zawsze.
2. Zacznij od trzech klocków: /loop, /goal i /routines
Na czym polega: Pętla w podstawowej wersji to: cykliczne wybudzanie agenta (/loop — np. co pięć minut sprawdzanie GitHuba), wymuszenie pracy do skutku (/goal) oraz zaplanowane zadania (/routines).
Jak stosować: Dopasuj mechanizm do rodzaju pracy — /loop do zdarzeń z systemów zewnętrznych, /goal do zadań typu „rób, aż będzie gotowe”, /routines do stałych obowiązków w harmonogramie.
Na co uważać: Terminal z Claude Code musi cały czas działać; a przy /goal źle napisane kryteria zakończenia sprawią, że agent będzie kręcił się w kółko.
3.Dawaj specyfikację, nie pojedyncze prompty
Na czym polega: Zamiast pisać prompty ręcznie, wręcz agentowi dokument z listą drobnych zadań i poproś o użycie wbudowanej umiejętności loop — orkiestrator sam ułoży pętlę i sam napisze prompty dla kolejnych cykli.
Jak stosować: Rozbij pracę na jednoelementowe zadania z warunkami walidacji; każda iteracja ma odhaczyć dokładnie jedno zadanie, a główna sesja ma wrócić z raportem po zakończeniu całości.
Na co uważać: Demonstrowany przykład to nie produkcja — systemy klasy Borisa wymagają dopracowania opisów tego, kiedy agent ma się budzić i jak ma przemiatać kontekst.
4.Każdy krok w osobnej sesji — kontekst nie wytrzyma pętli
Na czym polega: Zapętlenie w jednej sesji agenta po dłuższym czasie przepełnia kontekst i model tonie we własnej historii.
Jak stosować: Planowanie, implementację i walidację rozmieść w osobnych sesjach, a wiedzę przekazuj między nimi dokumentami, np. w markdownie.
Na co uważać: Osobne sesje muszą się rozumieć — bez wspólnego stanu nikt nie wie, w którym miejscu większego celu właśnie jest.
5.Odbierz agentowi decydowanie, zostaw mu pisanie kodu
Na czym polega: Rozumowanie modelu stosuj tylko tam, gdzie jest naprawdę potrzebne; resztę procesu (kolejność kroków, dobór testów) wymuszaj deterministycznie w pliku workflow.
Jak stosować: Zapisz proces w pliku, część kroków zrób czysto proceduralnie. Agent pisze kod, ale to ty ustalasz, jak wygląda stan, w którym testy przechodzą.
Na co uważać: Pełna autonomia orkiestratora — gdy sam wybiera liczbę „pracowników” i fale zadań — to głównie wyższy rachunek i mniejsza przewidywalność.
6.Mieszaj modele i dostawców krok po kroku
Na czym polega: W rozbudowanym systemie każdy krok może mieć inny model: tani do klasyfikacji i zbierania kontekstu (Haiku, Kimi K2.7), mocniejszy do implementacji (Claude Code), inny do review (Codex). Dobrze zbudowany harness wynosi tańszy model na wyższy poziom.
Jak stosować: Przejrzyj workflow i wszędzie tam, gdzie zadanie polega na wyborze kategorii albo zebraniu materiału, podstaw model mały — duży zostaw do pisania kodu.
Na co uważać: Jeden model do wszystkiego (klasyczna pułapka /goal, /routines i /loop) to najczęstszy powód astronomicznych rachunków.
7.Mierz tokeny w każdym uruchomieniu
Na czym polega: Autor wbudował śledzenie kosztów i przy jednym uruchomieniu — do zbudowania stosunkowo prostej aplikacji — pętla zużyła ponad milion tokenów, głównie na rozumowanie orkiestratora nad specyfikacją, promptowanie fal pracowników i ponowne rozumowanie nad wynikami.
Jak stosować: Loguj każdy przebieg z podziałem na role (orkiestrator, wykonawcy) i rundy; dopiero z tych danych szukaj, gdzie leje się budżet.
Na co uważać: Narzut na przekazywanie kontekstu w systemach rozproszonych da się ograniczyć, ale nie da się go usunąć do zera.
8.Stan trzymaj poza sesją
Na czym polega: Logi, zdarzenia i przebiegi pętli powinny mieszkać w zewnętrznej bazie (u autora: Postgres na Neonie), a nie w kontekście agenta — dzięki temu po awarii pracę wznowisz dokładnie od przerwanego kroku.
Jak stosować: Orkiestrator czyta stan z bazy i decyduje, co dalej; wykonawcy po każdej rundzie stan aktualizują. Baza jest jedynym źródłem prawdy.
Na co uważać: Sesje agentów są ulotne — przy zadaniach wielogodzinnych liczenie na nie to proszenie się o utratę pracy.
9.Wbuduj człowieka w punktach kontrolnych
Na czym polega: W dowolnym węźle workflow da się wpiąć pauzę na zatwierdzenie — na przykład przegląd wyników pierwszej rundy, zanim pętla ruszy dalej, albo walidacja pull requestów przed review.
Jak stosować: Punkty o dużej stawce (merge, wdrożenie, decyzja architektoniczna) oznacz jako wymagające decyzji człowieka; w narzędziach typu Retool można je dodatkowo obwarować uprawnieniami.
Na co uważać: Tryb „jedź bez hamulców” przez cały dzień zwykle kończy się workiem nieprzydatnego kodu zamiast gotowej pracy.
10.Równoległość wymaga izolacji
Na czym polega: Wiele agentów naraz wejdzie sobie w drogę — w kodzie, w schemacie bazy i na portach. Dlatego kluczowe są git work trees (odseparowane kopie repozytorium), rozgałęzienia bazy danych i zarządzanie portami.
Jak stosować: Każdemu zadaniu przydziel osobny work tree i osobną gałąź bazy; pull requesty twórz i waliduj niezależnie, review rób w osobnych sesjach.
Na co uważać: To najtrudniejsza inżynieria w całym układzie — bez niej równoległość rozsypuje się na konfliktach.
Redakcyjne tłumaczenie
Kolejne modne słówko: pętle zamiast promptów
Podobno ręczne promptowanie asystentów do kodowania mamy już za sobą. Prawdziwa umiejętność miałaby polegać na projektowaniu pętli, które same wystawiają agentom prompty i pracują za nas całą dobę. I powiem szczerze: na razie mnie to nie przekonuje. Wrażenie jest takie, że największe nazwiska branży — Peter Steinberger, twórca OpenClaw (Informacja dodatkowa: OpenClaw — otwartoźródłowy projekt samodzielnego asystenta agentowego, rozwijany przez niezależnego dewelopera Petera Steinbergera), oraz Boris Cherney, stojący na czele Claude Code — chcąc czy nie chcąc, rozkręcają nową modę na „loop engineering”, inżynierię pętli. To słówko właśnie robi karierę i obiecuję, że nie zamierzam go tu z zapartym tchem reklamować. W tym, co wypływa na powierzchnię, widać kilka sensownych lekcji, ale same pętle — pewnie zauważyliście to choćby przy dynamicznych workflow w Claude Code — bywają zawodne i pożerają ogromne ilości tokenów. Chyba że ktoś ma, jak Peter, budżet praktycznie bez dna, z takimi systemami trzeba obchodzić się bardzo ostrożnie. W praktyce nie zawsze się bronią.
I właśnie o tym chcę porozmawiać — szczerze i na konkretach. Plan jest prosty: najpierw pętle w najbardziej podstawowej postaci, bo to naprawdę nic skomplikowanego, i pokażę, jak je uruchamiać. Potem wady, a na końcu sposoby na te wady: system, w którym pętle, orkiestratora i agentów wykonawczych widać na wylot, oraz cięcie kosztów przez dobieranie dostawców, na przykład pi (Informacja dodatkowa: pi — minimalistyczny, otwartoźródłowy agent kodujący, do którego można podpiąć dowolny model i hostować go samodzielnie). Kierunek therefore taki: oto jak uruchamiać pętle, oto co jest z nimi nie tak i oto jak to naprawić, żeby budować stabilne „harnessy” — czyli szkielety sterujące wokół modelu, z narzuconym procesem, walidacjami i punktami kontroli człowieka — dla zadań długotrwałych. To podejście bywa naprawdę potężne, ale ma swoją cenę i nie zamierzam jej ukrywać.
„Piszę pętle, a pętle robią robotę”
Widzieliśmy już, co mówi Peter. Boris, twórca Claude Code, mówi coś niemal identycznego: „Nie promptuję już Claude. Piszę pętle, a pętle robią robotę. Moją pracą jest pisanie pętli”. No dobrze, Borisie — chyba wszyscy załapali. Powtarzam: „loop engineering” to w dużej mierze modne słówko, ale gdy się w to zagłębić, wyłania się kilka naprawdę wartościowych spostrzeżeń. Boris w wielu wywiadach i podcastach opowiada o swoim warsztacie, więc możemy zajrzeć mu przez ramię.
Trzy klocki: /loop, /goal i /routines
Sporo jego przepływu opiera się na nowszych funkcjach Claude Code. Najprostszy przykład to /loop — i jak obiecałem, upraszczamy. Ustawiamy interwał dla promptu: na przykład „co pięć minut sprawdzaj nowe issue w tym repozytorium i zajmij się tymi, które wpadły”. Całkiem zgrabne — Claude budzi się co pięć minut (oczywiście można to regulować) i szuka wejścia w systemie zewnętrznym, np. na GitHubie. Dopóki nasz terminal z Claude Code działa, ogarnia to samodzielnie.
Jest też /goal, dostępny w Claude Code i w Codexie: definiujemy kryteria — „po tym poznasz, że skończyłeś” — i zmuszamy agenta do pracy do skutku. Trochę jak pętle Ralph, które kilka miesięcy temu zrobiły furorę (Informacja dodatkowa: „pętle Ralph” — głośny schemat, w którym agent iteracyjnie poprawia własną pracę, aż spełni warunki zakończenia zadania).
Na końcu /routines, czyli zaplanowane zadania: „co godzinę obudź się, zajrzyj do większego dokumentu ze specyfikacją i wykonaj kolejne zadanie”.
Inżynieria pętli to w gruncie rzeczy składanie tego wszystkiego w jeden system — tak, żeby większy kawał pracy wszedł do asystenta kodującego jako wejście, a ten przerabiał go kawałek po kawałku. Nigdy nie chcemy, by agent brał na raz za dużo, bo po prostu się pogubi. Główna idea jest taka: mamy jednego nadrzędnego agenta, z którym rozmawiamy — orkiestratora. Promptujemy minimalnie, mówimy, czego chcemy, na wysokim poziomie, a on sam wymyśla, jak poukładać pętlę i cały system.
Umiejętność „loop” w akcji
W Claude Code to banalnie proste. Wystarczy kazać agentowi użyć umiejętności loop — narzędzie ma wbudowaną wiedzę, jak stawiać takie systemy, na podstawie tego, o co poprosimy. Przekazałem mu prosty dokument ze specyfikacją: listę zadań do przerabiania po kolei. Mój prompt mówi, żeby wczytał umiejętność, żeby wiedział, jak ustawić pętlę. W każdym cyklu wykonuje pierwsze nieodhaczone zadanie, je waliduje — i to tyle w tej iteracji. W następnej bierze kolejne. W końcu wszystkie zadania są zamknięte i główna sesja Claude Code, która wszystko ustawiła, wraca do mnie z raportem. Claude Code jest tu więc i orkiestratorem, i wykonawcą, bo pętlę stawia samodzielnie. Fajnie się na to patrzy — wysyłam zadanie, odczekam trochę i wrócę.
Pierwszą rzeczą, którą robi, jest wczytanie umiejętności loop: wie, jak orkiestrować, i sam odpala /loop, który przed chwilą pokazywałem w wersji ręcznej. Po paru minutach dwa pierwsze zadania są już zrobione — czyli za nami dwie iteracje. Na górze widać komunikat, że to sekwencyjna lista zadań: wykona pierwsze i zaplanuje szybkie wybudzenie. Sam konfiguruje /loop. Niżej, po zwalidowaniu pierwszego zadania, widać wznowienie przez „loop wake up”. I zauważcie: tego prompta napisał on, nie ja. „/loop: przerabiaj plan.md po jednym zadaniu naraz”. Wiem, że przykład jest banalny — celowo, dla prostoty — ale dokładnie tyle wystarczy w wersji podstawowej. Systemy, które buduje Boris, są oczywiście znacznie bardziej rozbudowane: ma doprecyzowane, jak mają biegać pętle i rutyny oraz jak agent ma pracować na kontekście. Ale sama zasada to nic więcej. Teraz po prostu będzie kolejno odhaczał kolejne punkty.
Problem pierwszy: czy to w ogóle daje najlepsze wyniki
Nikt mnie nie przekona, że inżynieria pętli to droga do najlepszych możliwych rezultatów pracy z asystentami kodującymi. To musi być przesada. Boris twierdzi, że jego AI o imieniu Daisy nadzoruje naraz dziesiątki tysięcy agentów. Serio? Czy to jest praktyczne? Czy to się skaluje? Naprawdę buduje się Claude Code z dziesiątkami tysięcy agentów dziennie? Może właśnie to tłumaczy parę uporczywych bugów, które nieustannie siedzą w Claude Code.
Tak pół żartem, pół serio. Ogólnie: lubię budować takie pętle, o ile tworzą bardzo ściśle kontrolowany system — o tym za chwilę — i uważam, że do prototypów oraz sprawdzania pomysłów są naprawdę dobre. Ale nie chciałbym nimi napędzać całego swojego kodowania.
Problem drugi: koszty
Przy inżynierii pętli polegamy na orkiestratorze, który stawia system i decyduje, jak dojść do celu: ilu wykonawców odpalić, ile pętli zrobić. A to robi się bardzo drogie. W dashboardzie, który pokażę na końcu, wbudowałem śledzenie kosztów — i przy jednym uruchomieniu, obejmującym wszystkie pętle przez które przeszedł orkiestrator, zapłaciłem ponad milion tokenów za zbudowanie stosunkowo prostej aplikacji. Pewnie da się to zoptymalizować, ale sam widok logów tłumaczy cenę — zresztą po części dlatego ten dashboard zbudowałem. Wysyłamy wstępną specyfikację; orkiestrator musi ją przemyśleć i zdecydować, ilu wykonawców odpalić; promptuje ich wszystkich, każdy spala tokeny; wyniki wracają — i orkiestrator znowu musi nad nimi rozumować, żeby wysłać następną falę. Niezależnie od projektu zawsze jest mnóstwo przekazywania kontekstu i rozumowania, żeby całość działała rozproszona. System jest potężny i imponuje, jak daleko można go pchnąć dzięki samowalidacji — ale jakże drogo się to robi.
Problem trzeci: jedna sesja, jeden rozdęty kontekst
W wielu konfiguracjach praca w ogóle nie rozkłada się między sesje agentów. Gdy używamy samego /loop w Claude Code, o którym Boris mówi najczęściej, pętla po prostu ciągnie się w tej samej sesji. Po dłuższym zapętleniu kontekst modelu robi się przeładowany i agent tonie. Potrzebujemy systemu, który naprawdę rozdziela pracę między osobne sesje, pozwala im się komunikować i każdej daje świadomość, gdzie jest w większym celu. I tym zajmiemy się do końca.
Jak pracuję na co dzień: Arkon i deterministyczne przepływy
Pokażę, jak pracuję codziennie, bo to załatwia większość opisanych problemów. Korzystam z własnego narzędzia Arkon — nie żeby je tu nikomu wciskać; chodzi o to, jak go używam wobec kosztów, niezawodności i orkiestracji wielu sesji agentów.
Arkon to budowniczy harnessów: pozwala składać workflow, które orkiestrują wiele sesji agentów kodujących nad większymi zadaniami. Klasyczny przepływ — planowanie, implementacja, review albo testy — dają się ułożyć jako jeden workflow Arkona. O Arkonie mam na kanale mnóstwo materiałów; zainteresowanych odsyłam do filmu. Dziś skupiam się na codziennym użyciu do rzeczy w duchu pętli: w Arkonie da się uprawiać loop engineering, da się zbudować pętlę w stylu Ralph.
Przykład weźmiemy z gotowych workflow, które dochodzą razem z Arkonem: „napraw issue z GitHuba”. Nie będę wchodził w szczegóły — pokażę tylko z grubsza, jak to działa. Różnica fundamentalna: u nas agent nie prowadzi całego procesu. Jest bardziej deterministycznie, bo proces zapisujemy w pliku workflow, a niektóre kroki są po prostu gwarantowane — niezależne od tego, co modelowi strzeli do głowy. Budując pętle i większe zadania, chcemy odebrać agentowi jak najwięcej decydowania, a rozumowanie modelu stosować tylko tam, gdzie jest naprawdę potrzebne — na przykład do napisania kodu. Chcemy może, żeby agent pisał kod, ale żeby to my decydowali, jakie testy uruchomić, bo to my wiemy, jak wygląda stan, w którym testy przechodzą.
W tym workflow najpierw wyciągamy numer issue (wejściem jest issue do naprawy albo obsłużenia), pobieramy jego kontekst, a potem klasyfikujemy: model decyduje, czy mamy do czynienia z błędem, czy z nową funkcjonalnością — i dalszy bieg zależy od tej decyzji. To dokładnie ten rodzaj wyboru, który zwykle zostawia się orkiestratorowi; u nas wymuszamy go procesem. Chcę właśnie tak nakładać własną warstwę na inżynierię pętli: chcę być w środku i sam wyznaczać, jak praca może dalej biec. Potem: research nad issue, dochodzenie do sedna, implementacja, walidacja i pull request. Krok po kroku — między krokami podajemy kontekst dokumentami markdown, a każdy krok działa we własnej sesji agenta. Dzięki temu przy dużym issue nie mamy jednej sesji Claude Code, która sama się zapętla na planowaniu, implementacji i walidacji naraz.
Dobierz model do kroku, nie do wszystkiego
Kosztem zarządzam tak, że dla każdego węzła workflow osobno wybieram model. Klasyfikacja issue na starcie — coś w rodzaju decyzji orkiestratora — spokojnie wystarczy mały model: Haiku, MiniMax M3 czy Kimi K2.7. W Arkonie można wręcz mieszać dostawców: Claude Code do implementacji, Codex do review, a do wstępnego ładowania i przemiatania kontekstu tańszy model. To zresztą kolejna bolączka /goal, routines i /loop w Claude Code: jeden model do praktycznie wszystkiego — i to jest część odpowiedzi, czemu tak drogo wychodzi. Przy większej robocie tokenów zawsze będzie dużo, ale nie każdy krok musi płacić najwyższą stawkę za token.
I jeszcze — już wiem, że powtarzam jak mantrę — trwałość. Wszystkie logi i uruchomienia trzymam w Postgresie na Neonie, więc mogę wznowić workflow nawet po awarii maszyny albo po własnym przerwaniu: zawsze wracam dokładnie do tego kroku większej pętli, w którym stanąłem. Rozmowy, repozytoria, na których pracuję — wszystko przeżywa restart, a wznowienie jest banalne.
Cztery issue naraz: pętla w codziennej praktyce
Teraz pokażę, jak używam Arkona naprawdę. Wiele z tego łączy się z inżynierią pętli — i wiele z tych problemów tu właśnie rozwiązałem. Najbardziej klasyczny scenariusz: naprawianie issue z GitHuba, bo większość wejścia w mojej codziennej pracy to właśnie issue — moje albo cudze. Arkon rozsyła workflow równolegle, tak że kilka issue jest obsługiwanych w tej samej chwili. I bardzo to przypomina loop engineering: główna sesja Claude Code jest orkiestratorem — na podstawie mojego życzenia sformułowanego ogólnie tworzy prompty i rozdziela zadania.
Drugim filarem są work trees, o których mówi też Boris. Gdy wielu agentów pracuje w pętli, muszą działać w izolacji, żeby nie wchodzić sobie w drogę. Właśnie tak podnosi się wydajność pracy z asystentami AI.
W praktyce: Claude Code odpala cztery workflow do czterech issue, potem sprawdza, czy pull requesty rzeczywiście powstały — tu może wejść człowiek — a na końcu puszczamy jeszcze cztery workflow z review kodu. Kompletnie: napraw, zweryfikuj, zrób przegląd. Pętla w dobrym sensie tego słowa.
W workflow Arkona można też w każdym pojedynczym węźle wpiąć człowieka: system się zatrzyma i poczeka na naszą decyzję. Bo jedna z największych chorób dzisiejszej inżynierii pętli jest taka, że ludzie ustawiają systemy, żeby te jechały bez hamulców. Puszczą coś na dzień, a gdy wracają, zastają śmietnik. Sam to przerobiłem, testując routines i /loop w Claude Code.
Wysyłam więc zadanie i wracam, gdy się skończy, żeby przejrzeć wyniki. Cztery uruchomienia naprawiają issue, a Claude Code czuwa nad całością: gdy kolejne zadania się kończą, podchodzi i je sprawdza. Gdy wszystkie cztery PR-y są gotowe do przeglądu — potwierdzone — odpala cztery review. W trakcie można poprosić o status: logi widać w interfejsie webowym Arkona, ale można też po prostu zapytać orkiestratora, bo to on naprawdę trzyma całość w garści. Na końcu dostajemy listę rzeczy wymagających naszej uwagi i przejmujemy stery. Harness prowadzi, a człowiek może wejść tam, gdzie zechce.
Całość robi dziewięć sesji agentów: po jednej na każdą naprawę, po jednej na każdy review, plus główny orkiestrator. Dużo pracy — a każda pojedyncza sesja pozostaje lekka. Zresztą muszę się poprawić: sesji jest więcej niż dziewięć, bo wewnątrz każdego workflow Arkona też działają osobne sesje, z osobnymi modelami i optymalizacją kosztów. Pod maską siedzi sporo inżynierii.
Skuteczna orkiestracja równoległych agentów to osobna sztuka, o której mam na kanale osobne materiały. Trzeba na przykład rozgałęziać bazę danych: gdy agenty pracują równolegle, nie mogą sobie deptać ani po kodzie, ani po schemacie bazy — work trees w Neonie są tu bardzo mocnym narzędziem. Do tego konflikty portów i inne pułapki. Gdy to wszystko ogarniecie, Arkona można puścić na pełnych obrotach na dowolnie wiele issue równolegle. Zaskakujące, jak daleko da się tym podnieść wydajność.
Czysta pętla pod nadzorem: autorski dashboard
Omówiliśmy podstawy, wady i sposób, w jaki wyciągam z tej idei to, co najlepsze, do bardziej deterministycznych workflow. Na koniec — system, który zbudowałem dla inżynierii pętli w jej najczystszej postaci. Bo choć nakreśliłem te problemy, widzę w tym kierunku spory potencjał i chciałem spróbować coś, co je rozwiąże. Zrobiłem dashboard, który zaraz pokażę; jest otwarty na GitHubie (link w opisie filmu).
Po pierwsze: trwałość. Jak w Arkonie, wszystkie uruchomione pętle, zdarzenia i logi trzymam w bazie, więc każdy workflow da się później wznowić. Cały stan mieszka w zewnętrznej bazie — nie w żadnej sesji agenta. Główny orkiestrator czyta ten stan i wnioskuje: „dobra, co jest następne?”. Potem woła wykonawców: zbuduj funkcję, przeprowadź walidację — co trzeba. Wykonawcy wracają i aktualizują stan w bazie (znów Postgres na Neonie). I to jest właśnie nasza pętla: przy następnym przebiegu orkiestrator bierze zaktualizowany stan i wybiera kolejnych wykonawców do odpalenia.
Zastrzegam: to bardziej eksperyment — pokazuję coś, nad czym pracuję i co wbudowuję w swojego „drugiego mózga”. Po pierwsze, całość napędzam przez pi — teraz modelem Kimi K2.7 (Informacja dodatkowa: Kimi to rodzina otwartych modeli firmy Moonshot AI, znacznie tańszych w eksploatacji niż Claude Opus). Tak, tokenów idzie dużo, ale nie płacę za Opusa do wszystkiego, a wyniki są bardzo dobre — bo zbudowany harness wynosi model na wyższy poziom. Po drugie, w dashboardzie siedzi obserwowalność. Już sama forma panelu załatwia spory kawał problemu niezawodności (nad którym wciąż pracuję): widzę dokładnie każde podejmowane rozstrzygnięcie, więc mogę obejrzeć je sam, a nawet kazać agentowi analizować uruchomienia zapisane w bazie i proponować ulepszenia pętli i całego harnessu.
Testuję na przykładach prostych, ale nie trywialnych — takich, które wymagają kilku rund, zanim dobiegną końca. Na przykład jednostronicowa tablica Kanban jako statyczna aplikacja webowa. Wysyłam prompt i pętla rusza — na żywo widać, jak orkiestrator dzieli robotę, a obok pełna historia przebiegu. Repo na GitHubie pozwala postawić to u siebie błyskawicznie. Po chwili orkiestrator tworzy pierwszą falę i widać odpalonych wykonawców: na wstępne planowanie i spromptowanie trzech pierwszych z nich w rundzie numer jeden orkiestrator wydał sześć tysięcy tokenów. Nie będziemy siedzieć i czekać do końca — idea jest jasna: runda po rundzie, za każdym razem z walidacją, a człowiek może zajrzeć po pierwszej rundzie, nim puszczą drugą. Właśnie takiej niezawodności — moim zdaniem — trzeba dziś, żeby budować cokolwiek więcej niż proste dema.
Z laptopa do chmury: Retool
Zachęcam do zabawy tym pomysłem. Dashboard do zarządzania bardziej autonomicznymi zadaniami w czymś w rodzaju drugiego mózgu to teraz mój duży kierunek. Taki panel można wystawić w chmurze, mieć do niego dostęp z każdego miejsca, a nawet podzielić się konfiguracją pętli z zespołem. Dziś przeniesienie lokalnej aplikacji sterowniczej na produkcję to drobiazg. Ja ostatnio mocno opieram się na Retool: tworzę aplikację i importuję kod React — właściwie kazałem Claude Code zbudować cały dashboard w Reakcie z myślą o takim wdrożeniu. Biorę zip z frontendem, wgrywam, a tamtejszy agent spina wszystko: łączy front z moim API, za którym działa pi, i wystawia całość pod prawdziwym adresem. Łączenie z Neonem, w którym trzymam przebiegi, to kwestia utworzenia zasobu: wybieram Postgres (bo Neon pod spodem to właśnie Postgres), podaję dane połączenia i gotowe. Chwila — a frontend w chmurze wygląda i działa dokładnie jak lokalnie. Mamy adres, którym można się dzielić.
Retool daje też grupy uprawnień: wybrane akcje można objąć endpointem wymagającym zatwierdzenia i odpowiednich praw. Przykład: pauza i wznowienie workflow. Klikam „zatwierdź i wznów”, system pokazuje moją tożsamość i to, że mam pozwolenie. Edycja aplikacji w chmurze jest równie prosta — dopisuję kolejne funkcje frontendu, gdy dashboard się rozrasta.
Krótkie podziękowanie dla zespołu Retool: odkąd korzystam z ich platformy, z nią współpracuję i stąd też integracja w dzisiejszym odcinku. Platforma jest naprawdę wygodna: aplikacje buduje się wprost w Retoolu albo importuje jak wyżej, a zespół i tak ma jedną, zarządzaną ścieżkę do produkcji ze ścieżką audytową. Zmiany robi się na czacie, a system review z człowiekiem w pętli załatwia resztę — wszystko, czego trzeba, żeby wypuścić aplikację na produkcję. Link w opisie; do 1 lipca import aplikacji jest darmowy, a na planach płatnych dochodzą dodatkowe kredyty AI.
Puenta: pętla to element harnessu, nie osobna dyscyplina
To tyle o inżynierii pętli: podstawy, problemy i moje próby ich rozwiązania. Koncept jest mi na tyle bliski, że naprawdę chcę wpleść loop engineering w swoją pracę — podoba mi się idea i chcę zwiększać autonomię agentów kodujących. Ale bez odpowiedniego systemu wszystko runie, o czym już było mowa. Mam nadzieję, że dałem wam pomysły — choćby jak użyć Arkona albo jak zacząć budować taki harness u siebie. Moim zdaniem loop engineering należałoby po prostu wchłonąć w harness engineering: nie do końca zasługuje na własne słówko. Choć pomysły w nim są dobre. Mam nadzieję, że się przydało — jeśli tak, będę wdzięczny za łapkę i subskrypcję. Do zobaczenia w następnym odcinku.