Miért érdemes meghagyni az AI-nak az ismétlődő munkát?

Tegnap láttam egy tweetet, ami nyolcmillió megtekintést kapott. Peter Steinberger azt írta: "Nem kellene többé promptolnod a kódoló ügynököket. Olyan hurkokat kellene tervezned, amik őket promptolják." Boris Cherny, a Claude Code megalkotója hasonlóról beszélt az Acquired Unplugged podcaston: "Én már nem promptolom a Claude-ot. Hurok fut nálam, és az promptolja."

Aztán jött a szokásos internetes reakció: mindenki vitatkozott, senki nem látott konkrét példát, és az egész elméleti ködbe veszett.

Nálam az elmúlt hónapokban valódi hurkok futnak. Nem azért, merttrendiben vagyok—egyszerűen elegem lett a kézi munkából, és automatizáltam. Amit találtam: a hurok-gondolkodás nem valami haladó technika az AI-guruknak. Ez egy természetes evolúció, ami akkor történik, amikor abbahagyod, hogy szuper-okos másoló-beillesztőnek tekintd az AI ügynököket, és elkezded őket rendszerként kezelni—olyan rendszerként, ami figyel, dönt, és cselekszik a nevedben.

A háromféle "hurok", amiről mindenki mást gondol

Itt romlik el a beszélgetés: amikor az emberek "hurokról" beszélnek, három különböző dolgot érthetnek alatta, és az eltérések számítanak.

Az első az autonóm feladat-hurok—lényegében "csináld, amíg kész nem lesz". Gondolj Geoffrey Huntley Ralph scriptjére, ami folyamatosan fut, vagy a /goal parancsra, amit a Codex és Claude Code már natívan tartalmaz. Ez a "beállítom és elfelejtem" mód.

A második az ütemezett vagy eseményvezérelt hurok—olyan munka, ami akkor fut, amikor te nem ülsz a gépnél. Peter Steinberger HEARTEBEAT.md-je a mérvadó példa: egy ellenőrzőlista, amit az ügynök minden 30 percben újra átgondol. E minta utódai közé tartoznak a Codex automatizációi és a Claude Code ütemezett rutinjai.

A harmadik az orchesztációs szétágazás—dinamikus munkafolyamatok több párhuzamosan futó ügynökkel. A Claude Code map/reduce-stílusú műveletei ide tartoznak. Ez közelebb áll az actor modellhez, mint bármihez, ami egyszerű huroknak nevezhető.

Az én véleményem? Steinberger és Cherny a második típust írja le, az elsőbe csomagolva. Az én hurkaim ütemezettek és eseményvezéreltek kívülről, és közülük több belső kísérletező hurkot is végrehajt, amikor aktiválódik. Ez a kombináció az, ahol az igazi erő lakik.

A PR-babysitter: Az első lépés a hurok-tervezés felé

Már volt AI kód-áttekintésem minden pull requestnél. Először a Claude nézett át mindent, aztán a Codex beépített áttekintője, majd egy egyedi GitHub Action, ahol pontosan én контролиáltam, mit lát a modell—bekapcsoltam a teljes beszélgetési kontextust és a patch diff-et.

A valódi munkafolyamatom abszurd volt: beküldtem a PR-t, vártam az áttekintésekre, aztán kézzel másoltam-beillesztettem az észrevételeket az ügynökbe. Néha képernyőképeket is. Kézi, ismétlődő, lélekölő.

Egy nap megkérdeztem az ügynökömet: "Nem tudnád saját magad ellenőrizni a gh klienssel a review státuszát?" Tudta. Természetesen megkérdeztem: "Nem tudnád folyamatosan ellenőrizni, és szólni, amikor kész van?"

Ez az egyetlen kérés átalakította a munkafolyamatomat. Az ügynök most figyeli a review státusz változásait, új kontextust kér le, elemzi a visszajelzéseket, és elvégzi a tényleges munkát—válaszol a feedbackre. A hurok akkor ér véget, amikor triázs-döntéshozatalhoz ér: elfogadja a feedbacket, visszautasítja, vagy eszkalálja nekem.

A minta gyönyörűen általánosítható: figyeld a külső rendszerek állapotváltozásait, ébredj fel, amikor történik valami, szerezd be az új kontextust, elemezd, cselekedj, és triázz. Ha egyszer meglátod ezt a mintát, mindenhol észreveszed. A Codex csapat maga is szállít egy babysit-pr skillt, és a Claude Code dokumentációja már PR-babysittingként említi a /loop parancs headline use case-ét.

Belső hurkok: Az ügynök saját kísérleteinek futtatása

Van egy másik hurok-minta, amit tovább tartott megérteni: a kísérleti hurok. Andrej Karpathy autopesearch koncepciója gondolkodtatott el ezen—sok iteráció futtatása, eredmények mérése, ami működik, azt megtartjuk. Ezt egy lassú Python útvonalra alkalmaztam, és egy óra alatt 49 kísérletet futtattam, ami a p95 latency-t 339ms-ról 34ms-re csökkentette nagyjából 24 dollárból.

Ugyanez a minta nehezebb problémákra is működik: ügynök-viselkedés debugolása éles környezetben. Amikor valami rosszul sül el—furcsa trace a Braintrust-ban, felhasználói visszajelzés a Slackben, vagy valami, amit magam találok—indítok egy worktree-t, beillesztem a trace-t, és meghívom a teszt hurkot.

Az teszi mássá ezt a hurkot: kikényszerít egy fegyelmet, amivel a modell naiv intuíciója harcol. Ha magára hagyod, a modell belekódolja a "soha ne csináld X, Y, Z"-t a system promptba, és túlilleszkedik arra az egy trace-re, amit mutattál neki. A skill referenciái desztillálják a kutatást arról, miért bukik meg ez a megközelítés, és a hurok-szerződés hipotézist és teszt-mátrixot igényel.

Három esetre van szükségem: az eredeti hibás eset, egy szomszédos pozitív, ami ugyanazon az úton kell menjen, és egy ellenpélda, ami más úton kell menjen. Három-négy próba fut párhuzamosan a lokális dev ellen, pontosan rekonstruálva a felhasználói kontextust a trace-ből. Minden futás pontozódik tool hívások, latency, input-token delta és helyesség alapján. A modell nem csalhat memóriával—valóban meg kell értenie.

Mi változik meg, amikor hurkokat építesz

A legnagyobb eltolódás nem technikai—koncepcionális. Amikor promptolsz egy ügynököt, te vagy az, aki vezeted. Te vagy a gázpedál, a navigátor, a minőségellenőr. A hurkok megfordítják ezt. Te leszel az architecte az önmagát vezérlő rendszereknek.

Ez nem jelenti azt, hogy a teljes autonómia a cél. Még mindig a triázs-kapun vagyok minden fontosnál. A hurkok kezelik az unalmat, a monitorozást, az ismétlést. Én kezelem az ítélőképességet igénylő döntéseket, amik tényleg számítanak.

A második eltolódás az, hogy a hurkok kikényszerítik, hogy explicit légy a sikerkritériumokban. Egy jó huroknak világos kilépési feltételei vannak, világos döntési pontjai, világos eszkalációs útvonalai. Nem építhetsz hurkot anélkül, hogy meghatároznád, hogyan néz ki a "kész". Ez a fegyelem mindenhová beszivárog.

A harmadik: a hurkok komponálhatók. A PR-babysitter együttműködik a kísérleti hurkkal. Az ütemezett ellenőrzések kiváltják az on-call válaszokat. Elkezdesz egy viselkedéskönyvtárat építeni, amik együttműködnek, ahelyett hogy egy halom egyedi prompt lenne.

A gyakorlati kiindulópont

Ha ki akarsz kísérletezni hurkokkal, valamivel kezdd, amit már rosszul automatizáltál. Valószínűleg van egy GitHub Actionöd, ami ütemezés szerint fut valamit, vagy egy Claude Code sessiont manuálisan újra és újra futtatsz, vagy egy review folyamat, ami másolás-beillesztást igényel a toolok között.

Válaszd a legidegesítőbbet. Kérdezd meg magadtól: milyen állapotváltozásra várok? Milyen kontextusra van szüksége az ügynöknek, amikor az bekövetkezik? Milyen döntést kell meghozzon?

Aztán építsd meg a hurkot. Nem kell elegánsnak lennie. Működnie kell, és vissza kell adnia neked az időd feletti kontrollt.

A teljes konfigurációk, skill-ek és CI munkafolyamatok, amik a hurkjaimat működtetik, egy publikus snapshot repóban vannak: camwest/agent-skills. Nem egy polírozott termék—egy működő rendszer, ami evolve-ol, ahogy tanulok. Ez a lényeg. A hurkok nem célállomások; gyakorlatok.

Az AI ügynökökről szóló diskurzus fullad az absztrakcióban. Itt a konkrét verzió: hagyd abba a promptolást, kezdj el hurkokat építeni, és nézd meg, mi történik, amikor a gépre bízod a monitorozást, miközben te kezeled a jelentést.