Inżynieria pętli: pętle wygrywają tam, gdzie weryfikacja jest tania

Boris Cherny, inżynier, który stworzył Claude Code, ma jednocześnie otwartych od pięciu do dziesięciu sesji; w ciągu dnia pracuje u niego kilkuset agentów, a każdej nocy — kilka tysięcy.² Kiedy w minionym tygodniu po X rozszedł się klip, w którym mówi: „Już nie promptuję Claude’a… moja praca polega na pisaniu pętli”, większość komentarzy potraktowała to zdanie jako proroctwo o autonomicznym wytwarzaniu oprogramowania, a w ciągu kilku dni Addy Osmani nazwał tym mianem całą dyscyplinę: loop engineering, czyli inżynierię pętli.⁷ Sięgnąłem po pełne transkrypcje trzech wystąpień, z których pochodzi ten klip. Opowiadają one historię znacznie spokojniejszą — i to właśnie ta spokojniejsza wersja nadaje się na fundament: każda pętla, którą Cherny rzeczywiście wymienia, ma warunek sukcesu możliwy do sprawdzenia przez maszynę za darmo. O tym, co można zautomatyzować, decyduje koszt weryfikacji, a nie konstrukcja pętli. Pętle produkcyjne działają u mnie od lutego i moje logi zgadzają się z transkrypcjami — łącznie z dwoma incydentami, które wbiły mi tę lekcję do głowy w najbardziej bolesny sposób.

TL;DR / Najważniejsze wnioski

• Wiralowy cytat pochodzi z wywiadu Cherny’ego dla Acquired Unplugged, w którym przedstawia pętle jako kolejny krok na osi ciągnącej się od kart perforowanych przez asembler i języki wysokiego poziomu aż po promptowanie.¹ Sam wyznacza tej przemianie krótki termin przydatności: „najbliższe kilka miesięcy, może reszta roku”.¹
• Mechanika jest z założenia banalna. W wystąpieniu dla Sequoi Cherny opisuje /loop jako Claude’a, który używa crona do zaplanowania powtarzalnego zadania.² Pętle, które wymienia z nazwy, pilnują pull requestów, dbają o zdrowie CI i co 30 minut grupują opinie z Twittera.²
• Każda z nich to praca porządkowa. Każda ma stan końcowy sprawdzalny maszynowo: zielone CI, zrebasowany PR, pogrupowane opinie. Żaden z wymienionych przez niego przykładów nie buduje funkcji bez nadzoru.
• Zadanie pisania pętli już rozpuszcza się w modelu. Cherny relacjonuje, że nowsze modele same z siebie uruchamiają pętle, a budowanie pętli po stronie użytkownika nazywa „problemem projektowania produktu”, co w jego ujęciu znaczy: „nie wykonuję dobrze swojej pracy”.⁵
• Trwała umiejętność ukryta pod memem to decyzja o tym, co można bezpiecznie zautomatyzować bez nadzoru. Jest to ocena weryfikowalności — i zostaje przy nas długo po tym, jak składnia pętli zniknie.

Co właściwie powiedział

Klip, który wszyscy udostępniali, pochodzi z wywiadu na żywo dla Acquired. Cherny poprzedza słynne zdanie historią rodzinną: jego dziadek programował na kartach perforowanych w Związku Radzieckim, a ojciec pisał w asemblerze i „wyśmiałby mnie za to, że piszę w Pythonie”. Dalej fragment, który obiegł internet:

„Taka jest natura programowania: poziom abstrakcji zawsze idzie w górę… Rok temu kodowałem tak, że pisałem kod z jakimś autouzupełnianiem w IDE. W listopadzie odinstalowałem IDE, bo z niego nie korzystałem… Wtedy uruchamiałem może pięć, dziesięć instancji Claude’a równolegle, a moje kodowanie polegało na promptowaniu Claude’a, żeby pisał kod. Teraz poziom znowu poszedł w górę… już nie promptuję Claude’a. Mam działające pętle. To one promptują Claude’a i same wymyślają, co robić. Moja praca polega na pisaniu pętli”.¹

Pełny wywiad Acquired Unplugged; fragment o pętlach zaczyna się od 11:14.

Dwa szczegóły z pełnej transkrypcji nigdy nie trafiły do klipów. Po pierwsze, Cherny sam datuje tę przemianę: pętle to coś, co „zobaczymy w najbliższych kilku miesiącach, może przez resztę roku”.¹ Opisuje etap, a nie punkt docelowy. Po drugie, uwaga źródłowa dla wszystkich, którzy śledzą tę dyskusję: kilka wiralowych wpisów przypisywało materiał o pętlach jego godzinnemu występowi w podcaście Y Combinatora. Sprawdziłem pełną transkrypcję tego odcinka. Nie ma w nim ani jednej wzmianki o pętlach; odcinek dotyczy historii powstania produktu i subagentów.⁶ Treść znajduje się w wywiadzie dla Acquired oraz w 24-minutowym wystąpieniu dla Sequoi.

Pętla to zadanie crona

Wystąpienie dla Sequoi dostarcza mechaniki — celowo nudnej:

„Cała rzecz polega na tym, że Claude używa crona, żeby zaplanować zadanie na jakiś moment w przyszłości, i jest to zadanie powtarzalne. Może działać co minutę, co pięć minut, codziennie”.²

Wystąpienie dla Sequoi zawiera każdy szczegół techniczny, który wiralowe klipy pominęły; część o pętlach zaczyna się od 7:56.

Cherny ma ich dziesiątki. Te, które wymienia z nazwy: pętla pilnująca jego PR-ów (naprawia CI, automatycznie rebasuje), pętla dbająca o zdrowie CI (naprawia niestabilne testy) oraz pętla, która co 30 minut ściąga opinie z Twittera i je grupuje.² Routines, zapowiedziane w maju na wydarzeniu Code with Claude organizowanym przez Anthropic, przenoszą ten sam wzorzec na stronę serwera, dzięki czemu pętla przeżywa zamknięcie laptopa.² Simon Willison, relacjonując keynote na żywo, zapisał sformułowanie, którego używa samo Anthropic: Routines to „prompty wyższego rzędu”.¹² Cherny od miesięcy powtarzał, że /loop i /schedule to dwie z najpotężniejszych funkcji produktu; jego kanoniczny punkt startowy to pięciominutowa pętla pilnująca PR-ów.¹¹

Wzorzec ma surowszego przodka. Technika Ralph Wiggum autorstwa Geoffreya Huntleya to, jego własnymi słowami, „Ralph to pętla w Bashu”: while true, które w nieskończoność podaje agentowi ten sam plik z poleceniem, a postęp między iteracjami utrwala się w plikach i historii gita.⁹ Anthropic dostarcza dziś Ralpha jako oficjalną wtyczkę, która przechwytuje próby wyjścia agenta i podaje mu to samo polecenie ponownie, dopóki nie pojawi się ciąg oznaczający ukończenie albo nie zostanie osiągnięty limit iteracji.⁹ The Register potwierdził, że sam Cherny korzysta z Ralpha, i przytoczył ostrzeżenie Huntleya co do kierunku, w którym prowadzi ekonomia: startupy wykorzystają tę technikę do klonowania istniejących biznesów SaaS i podcinania im cen, bo kodowanie agentowe kosztuje mniej więcej 10 dolarów za godzinę.¹⁰ Rodowód ma znaczenie, bo pokazuje faktyczny wiek pomysłu: pętla to najstarsza konstrukcja sterująca w informatyce i w samym tym konstrukcie nie ma niczego nowego.¹⁵

Każda wymieniona przez niego pętla to praca porządkowa

Oto obserwacja, którą dyskusja pominęła. Warto jeszcze raz wypisać pętle Cherny’ego i spojrzeć na ich stany końcowe:

Każda z nich albo ma warunek sukcesu sprawdzalny maszynowo, albo produkuje wynik, w którym błędy nic nie kosztują. Żaden z wymienionych przykładów nie brzmi „zbuduj funkcję, kiedy ja śpię”. Człowiek, u którego każdej nocy pracuje kilka tysięcy agentów, opisuje własną automatyzację jako naprawę CI, rebasowanie i segregowanie opinii.

Pozorny kontrprzykład tylko potwierdza regułę. Własny zespół inżynierski Anthropic przez dwa tygodnie uruchamiał 16 agentów w nieskończonych pętlach i wyprodukował liczący 100 000 wierszy kompilator C napisany w Rust, przy koszcie obliczeń rzędu 20 000 dolarów.⁸ Kompilator to najlepiej weryfikowalny artefakt w całym oprogramowaniu: gigantyczny zestaw testowych programów albo kompiluje się i działa poprawnie, albo nie. Zespół wybrał cel, przy którym weryfikacja jest niemal darmowa — a mimo to Nicholas Carlini, który prowadził eksperyment, napisał, że wdrażanie przez programistów oprogramowania, którego nigdy osobiście nie zweryfikowali, jest „realnym powodem do niepokoju”.⁸

Esej Addy’ego Osmaniego, który nadał dyscyplinie nazwę „loop engineering”, dochodzi do tego samego ograniczenia od strony projektowej: „Pętla działająca bez nadzoru to również pętla popełniająca błędy bez nadzoru”.⁷ Proponowana przez niego architektura (osobni agenci weryfikujący, żeby wykonawca nigdy nie oceniał własnej pracy) to próba wytworzenia taniej weryfikacji tam, gdzie nie występuje ona naturalnie.⁷

Czego nauczyły mnie moje własne pętle

O swoim nocnym systemie agentowym pisałem w lutym, kiedy grzeczną nazwą tej techniki wciąż było odwołanie do Simpsonów.¹⁶ Od tamtej pory wszystkie pętle, które przetrwały w moim zestawie, zbiegły się do tego samego kształtu — a te, które poległy, nauczyły mnie więcej niż te, które działały.

Te, które przetrwały, mają kształt kontroli. Nocna pętla czyta commity z danego dnia, mapuje zmienione pliki na działające adresy URL, ładuje każdą dotkniętą stronę i raportuje wynik pozytywny lub negatywny wraz z czasami ładowania. Pętla bezpieczeństwa obserwuje nocą endpointy i pisze poranny briefing. Pętla crawlowa czyta aktywność Googlebota i Bingbota na moich witrynach i raportuje dryf indeksacji. Żadna z nich niczego nie tworzy. Każda obserwuje, porównuje ze stanem oczekiwanym i raportuje. Kiedy któraś się pomyli, kosztem jest nieaktualny raport, a nie zepsuty produkt. Poranna lektura zajmuje kilka minut, bo wynik dla każdej pozycji jest binarny: przeszło, nie przeszło, zajrzyj tutaj.

Porażkami były pętle, które działały. Funkcja izolacji, automatycznie tworząca worktree gita dla równoległych agentów, dwukrotnie usunęła katalogi robocze, które uznała za zbędne; promień rażenia tej automatyzacji objął pliki, których nie utworzyła i których nie rozumiała. Zaplanowane czyszczenie pamięci podręcznej zadziałało kiedyś w złej kolejności względem wdrożenia i roboty wyszukiwarek przez 11 godzin dostawały 404 dla istniejących stron, bo czyszczenie usunęło poprawne odpowiedzi z cache’u, zanim serwer źródłowy podał ich zamienniki.¹⁶ Żadna z tych porażek nie wzięła się ze złego modelu. Obie wzięły się stąd, że dałem prawo zapisu pętli, której warunków wstępnych nie ustaliłem do końca. Każda ma dziś zabezpieczenie: automatyzacja worktree jest zablokowana całkowicie, a czyszczenie cache’u uruchamia się dopiero po pozytywnej weryfikacji wdrożenia. Ogólna reguła, jaką z tego wyciągnąłem: pętla, która tylko czyta, potrzebuje harmonogramu; pętla, która pisze, musi najpierw przedstawić dowód kolejności i ograniczenie promienia rażenia, zanim na harmonogram zasłuży.

Ta sama reguła tłumaczy element zestawu Cherny’ego, w który najtrudniej ludziom uwierzyć. „Właściwie większość pracy wykonuję dziś z telefonu” — mówi, prowadząc sesje przez zakładkę code w aplikacji Claude.² Telefon to fatalne miejsce do przeglądania kodu i całkiem dobre do czytania raportu przeszło/nie przeszło. Teza o telefonie jest przebraną tezą o weryfikacji: jego pętle emitują wynik na tyle czytelny, że można go przyjąć lub odrzucić jednym spojrzeniem — a to możliwe jest tylko wtedy, gdy warunki sukcesu zaprojektowano, zanim pętla ruszyła.

Drabina kosztu weryfikacji

Jeśli teza się broni, wybór tego, co zautomatyzować, sprowadza się do jednego pytania: kto weryfikuje wynik i ile ta weryfikacja kosztuje? Oto drabina, z której korzystam, zanim jakiekolwiek zadanie dostanie harmonogram.

Kolumną, która rozstrzyga, jest druga, a trudność zadania nie pojawia się w niej ani razu. Trudne zadanie z darmowym weryfikatorem (niestabilny test) automatyzuje się wcześniej niż łatwe zadanie z kosztownym weryfikatorem (jednowierszowa zmiana tekstu, którą musi zatwierdzić człowiek). Pętle Cherny’ego, kompilator Anthropic i moje ocalałe pętle mieszczą się w górnej połowie drabiny; wiralowe komentarze zakładały dolną.

Kształt, który przechodzi tę drabinę, wygląda zawsze jak ten sam wzorzec nadzoru, niezależnie od skali:

Anatomia pętli, która zasługuje na swój harmonogram. Weryfikator narysowano grubszą kreską, bo to on jest elementem nośnym: gdy go usunąć, pętla nadal działa, tylko nikt nie wie, co zrobiła.

Najmniejsza pętla warta uruchomienia jest tylko do odczytu, sama się weryfikuje i daje się ogarnąć jednym spojrzeniem — dzięki czemu można ją bezpiecznie napisać dziś, a jutro nudno będzie ją obserwować:

# Nightly site check: observes and reports, never edits.
# Run it under a permission mode that blocks writes outside reports/.
while true; do
  claude -p "Read today's commits. For each changed file that maps to a live
    page, fetch the staging URL and confirm it returns 200 and renders its
    headline. Append PASS or FAIL per page, with the reason, to
    reports/site-check-$(date +%F).md. Write nothing outside reports/."
  sleep 86400
done

Wewnątrz Claude Code ta sama pętla to jedna linia: /loop 24h, a po niej instrukcja. Awans przychodzi później. Dopiero gdy raport jest nudny od miesiąca, pętla zasługuje na rozważenie kolejnego szczebla drabiny — wcześniej nie.

Praca, która zostaje

Najdziwniejszy fragment wystąpienia dla Sequoi podcina mem, który sam zrodził. Cherny mówi, że nowsze modele zaczęły uruchamiać pętle, choć nikt ich o to nie prosił: on prosi o zapytanie do danych, a model zauważa, że dane zmieniają się w czasie, proponuje cykliczny raport co 30 minut i sam podpina go do Slacka.⁵ Jego wniosek: „To nie użytkownicy mają wymyślać, jak lepiej trzymać narzędzia… to w gruncie rzeczy problem projektowania produktu, a ja nie wykonuję dobrze swojej pracy”.⁵ Argument z regresu, który sceptycy podnosili na X (jeśli dziś pętle piszą ludzie, jutro pętle napiszą modele), okazuje się mapą drogową Anthropic — przyznaną przez człowieka, którego ten mem dotyczy.

Idzie dalej: „W miarę jak model robił się lepszy, ramy agenta stają się jakby mniej ważne” — i przewiduje, że tryby uprawnień, zabezpieczenia przed wstrzykiwaniem złośliwych poleceń oraz punkty kontrolne z człowiekiem w pętli będą zanikać wraz z postępami w dopasowaniu modeli (alignment).³ Co do połowy tego zakładu obstawiam przeciwnie. Rusztowanie bezpieczeństwa może się skurczyć. Rusztowanie orkiestracji staje się natomiast całą pracą — i to według jego własnej relacji: agenci inżynierów Anthropic koordynują się ze sobą przez Slacka, podczas gdy ich właściciele pracują, a „nie mamy już nigdzie w firmie ręcznie pisanego kodu. Cały SQL piszą modele”.⁴ Ktoś decyduje, czego ci agenci mogą dotknąć, co liczy się jako ukończone i co się dzieje, gdy dwóch z nich się nie zgadza. Ta warstwa decyzyjna to prawdziwy interfejs agenta, a cron jest w niej częścią najłatwiejszą.

Trwałą umiejętnością nie jest zatem składnia pętli, którą model już wchłania, ani promptowanie, które wcześniej wchłonęły pętle. Trwałą umiejętnością jest ocena leżąca pod jednym i drugim: rozstrzygnięcie, co można bezpiecznie zautomatyzować bez nadzoru. To rozstrzygnięcie zawsze dotyczy kosztu weryfikacji. Naprawa CI zautomatyzowała się pierwsza, bo zestaw testów już był weryfikatorem. Grupowanie opinii zautomatyzowało się, bo błędy nic nie kosztują. Rozwój funkcji stawia opór, bo weryfikacja wciąż kosztuje tyle, ile człowiek czytający diff — a pewien doświadczony inżynier na Hacker News nazwał wynikającą z tego pułapkę wprost: narzędzie wymaga wprawnego osądu, żeby nim sterować, a korzystanie z narzędzia osłabia dokładnie ten osąd.¹⁴

Wywiad Caseya Newtona z Chernym dla Platformera ukazał się pod tytułem „Twórca Claude Code o końcu inżyniera oprogramowania”. Cherny przewiduje w nim, że tytuł „inżynier oprogramowania” do końca roku rozpłynie się w czymś w rodzaju „budowniczego”, podczas gdy liczba osób piszących kod za pośrednictwem agentów wzrośnie stukrotnie.¹³ Budowniczowie są w tej prognozie tymi, którzy wybierają pętle. Wybierać dobrze znaczy wiedzieć — zanim cokolwiek ruszy — skąd będzie wiadomo, że zadziałało.

Najważniejsze wnioski

Dla inżynierów prowadzących agentów kodujących: - Kandydatów do automatyzacji warto oceniać według kosztu weryfikacji, a nie poziomu ekscytacji. Naprawa CI, rebasowanie, monitoring i generowanie raportów mają dziś darmowe weryfikatory — od nich należy zacząć. - Warto stosować podział na odczyt i zapis: pętla tylko do odczytu potrzebuje harmonogramu, a pętla z prawem zapisu — jawnego ograniczenia kolejności i limitu promienia rażenia, zanim ruszy bez nadzoru. - Raport należy zaprojektować przed pętlą. Jeżeli nie da się odrzucić jej wyniku z telefonu w 10 sekund, pętla nie jest gotowa do pracy nocą.

Dla liderów zespołów: - Sufitem użytecznej równoległości jest przepustowość przeglądu kodu, a nie liczba agentów. Dokładanie agentów powyżej tego sufitu daje niesprawdzone merge’e, a nie wydajność. - Wykonawców należy oddzielić od sprawdzających. Agent weryfikujący własną pracę jedynie deklaruje poprawność; osobny weryfikator, patrzący z innego punktu, ma przynajmniej szansę tę deklarację podważyć.

Dla twórców narzędzi: - Cherny nazywa budowanie pętli po stronie użytkownika porażką projektowania produktu, a modele już same inicjują pętle.⁵ Budowanie UX do tworzenia pętli oznacza budowanie dla warstwy, którą dostawca modelu zamierza wchłonąć. Trwalsza powierzchnia to weryfikacja: dowody, ślady wykonania oraz ergonomia przyjmowania i odrzucania.

FAQ

Przypisy