De ce ar trebui să încetezi să mai faci prompting și să începi să construiești bucle

În urmă cu o lună, Peter Steinberger a publicat un tweet care a adunat opt milioane de vizualizări: „Nu ar trebui să mai faci prompting pentru agenții de codare. Ar trebui să proiectezi bucle care să facă prompting pentru agenții tăi." Aproximativ în aceeași perioadă, Boris Cherny—creatorul Claude Code—a spus ceva similar la Acquired Unplugged: „Nu mai fac prompting pentru Claude. Am bucle care rulează. Ele sunt cele care fac prompting pentru Claude."

Și apoi internetul a făcut ce face internetul: toată lumea a discutat, nimeni nu a văzut o buclă, și discursul a devenit un haos de abstracțiuni.

Eu rulez bucle reale de câteva luni. Nu pentru că sunt înaintea curbei—pur și simplu m-am săturat de munca manuală de triaj și am automatizat-o. Ce am descoperit m-a surprins: mentalitatea de buclă nu este o tehnică avansată pentru utilizatori puternici de AI. Este o evoluție naturală care se întâmplă odată ce încetezi să tratezi agenții AI ca pe niște copiatori sofisticați și începi să îi tratezi ca sisteme care pot monitoriza, decide și acționa în numele tău.

Cele trei tipuri de „buclă" pe care nimeni nu le agreează

Iată de ce această conversație devine haotică: când oamenii spun „buclă," ar putea însemna unul din trei lucruri, iar diferențele contează.

Primul este bucla autonomă de sarcini—în esență „continuă până când termini." Gândește-te la scriptul Ralph al lui Geoffrey Huntley (while :; do cat PROMPT.md | claude-code; done), sau comanda /goal pe care Codex și Claude Code o oferă acum nativ. Acesta este modul „setează și uită."

Al doilea este bucla programată sau condusă de evenimente—muncă care rulează în timp ce tu nu ești la birou. HEARTEBEAT.md al lui Peter Steinberger din OpenClaw este exemplul canonic: o listă de verificare pe care agentul o reconsiderează la fiecare 30 de minute. Descendenți ai acestui pattern includ automatizările Codex și rutinele programate ale Claude Code.

Al treilea este orchestrarea fan-out—fluxuri de lucru dinamice cu mai mulți agenți care rulează simultan. Operațiunile de tip map/reduce ale Claude Code se încadrează aici. Acesta este mai aproape de modelul actor decât de orice ar semăna cu o simplă buclă.

Părerea mea? Steinberger și Cherny descriu al doilea tip, conectat la primul. Buclele pe care le rulez sunt programate și conduse de evenimente la exterior, iar câteva dintre ele execută bucle interioare de tip experiment odată ce se declanșează. Această combinație este unde se ascunde adevărata pârghie.

PR Babysitter: Poarta mea de intrare în designul de bucle

Aveam deja revizuire de cod AI pe fiecare pull request. Claude review-uiea primul, apoi review-ul încorporat al Codex, apoi o acțiune GitHub personalizată unde controlam exact ce vedea modelul—aducând contextul complet al conversației plus diff-ul patch-ului.

Fluxul meu real de lucru era absurd: trimiteam un PR, așteptam să vină review-urile, apoi copy-paste review comments în agent. Uneori lipam screenshot-uri. Era manual, repetitiv și sufocant.

Într-o zi l-am întrebat pe agentul meu: „Nu poți să folosești pur și simplu clientul gh și să verifici statusul review-ului?" Putea. Așa că, natural, l-am întrebat: „Nu poți pur și simplu să verifici continuu și să îmi spui când e gata?"

Acea singură cerere mi-a transformat fluxul de lucru. Agentul acum monitorizează modificările de status ale review-ului, aduce context nou, analizează feedback-ul și face munca efectivă de a-l adresa. Bucla se încheie când ajunge la o decizie de triaj: acceptă feedback-ul, împinge înapoi, sau escaladează la mine.

Pattern-ul se generalizează frumos: monitorizează modificările de stare în sistemele externe, trezește-te când apar, adu context proaspăt, analizează, acționează și triajează. Odată ce vezi această formă, începi să o observi peste tot. Echipa Codex livrează propria lor skill babysit-pr, iar documentația Claude Code numește acum PR babysitting ca un caz de utilizare principal pentru comanda lor /loop.

Bucle interioare: Fă agentul să își ruleze propriile experimente

Există un alt pattern de buclă pe care l-am apreciat mai greu: bucla de experiment. Conceptul de autoresearch al lui Andrej Karpathy m-a făcut să mă gândesc la asta—rulează multe iterații, măsoară rezultatele, păstrează ce funcționează. Am îndreptat asta spre o cale Python lentă și am rulat 49 de experimente într-o oră, reducând latența p95 de la 339ms la 34ms pentru aproximativ 24 de dolari.

Același pattern se aplică problemelor mai dificile: debugarea comportamentului agentului în producție. Când ceva nu merge bine—un trace ciudat în Braintrust, feedback de la utilizatori în Slack, sau ceva ce am întâlnit eu însumi—rostogolesc un worktree, lipesc trace-ul și invoc bucla de test.

Iată ce face această buclă diferită: forțează o disciplină pe care intuiția naivă a modelului o combăte. Lăsat singur, un model va hardcoda „nu face niciodată X, Y, Z" în system prompt și va supraajusta la singurul trace pe care i l-ai arătat. Referințele skill-ului distilează cercetarea despre motivele pentru care această abordare eșuează, iar contractul buclei necesită o ipoteză și o matrice de test.

Am nevoie de trei cazuri: cazul original care eșuează, un pozitiv adiacent care ar trebui să urmeze aceeași cale, și un contraexemplu care ar trebui să urmeze altă cale. Trei sau patru probe rulează simultan împotriva dev-ului local, reconstituind contextul exact al utilizatorului din trace. Fiecare rulare primește un scor pe apeluri de tool-uri, latență, delta de tokeni de input și corectitudine. Modelul nu poate trișa memorând—trebuie să înțeleagă cu adevărat.

Ce se schimbă de fapt când construiești bucle

Cel mai mare shift nu este tehnic—este conceptual. Când faci prompting pentru un agent, tu ești încă cel care conduce. Tu ești accelerația, navigatorul, controlorul de calitate. Buclele inversează asta. Devii arhitectul sistemelor care se conduc singure.

Astă nu înseamnă că autonomia completă este obiectivul. Sunt încă la poarta de triaj pentru tot ce contează. Buclele se ocupă de sarcini plictisitoare, monitorizare, repetiție. Eu mă ocup de deciziile de judecată care contează cu adevărat.

Al doilea shift este că buclele te forțează să fii explicit despre criteriile de succes. O buclă bună are condiții clare de ieșire, puncte clare de decizie, căi clare de escaladare. Nu poți construi o buclă fără să definești ce înseamnă „gata". Acea disciplină se scurge în tot restul.

În al treilea rând, buclele sunt compozabile. PR babysitter-ul funcționează alături de bucla de experiment. Verificările programate declanșează răspunsuri on-call. Începi să construiești o bibliotecă de comportamente care funcționează împreună în loc de un morman de promp-uri unice.

Punctul de plecare practic

Dacă vrei să experimentezi cu bucle, începe cu ceva ce ai automatizat deja prost. Probabil ai o acțiune GitHub care face ceva pe un program, sau o sesiune Claude Code pe care o rulezi manual în mod repetat, sau un proces de review care implică copy-paste de outputs între instrumente.

Alege-l pe cel mai enervant. Întreabă-te: ce schimbare de stare aștepți de fapt? Ce context are nevoie agentul când acea schimbare se întâmplă? Ce decizie trebuie să ia?

Apoi construiește bucla. Nu trebuie să fie elegantă. Trebuie să funcționeze și să te pună înapoi în controlul propriului timp.

Configurațiile complete, skill-urile și workflow-ul CI din spatele buclelor pe care le rulez sunt într-un snapshot repo public: camwest/agent-skills. Nu este un produs lustruit—este un sistem funcțional care evoluează pe măsură ce învăț. Asta este punctul. Buclele nu sunt o destinație; sunt o practică.

Discourse-ul din jurul agenților AI se îneacă în abstracțiuni. Iată versiunea concretă: oprește prompting-ul, începe să construiești bucle, și vezi ce se întâmplă când lași машината să se ocupe de monitorizare în timp ce tu te ocupi de semnificație.