Smetti di fare il centralinista. Lascia che siano loro a cercarti

Qualche settimana fa Peter Steinberger ha twittato qualcosa che ha fatto il giro del web: "Non dovresti più fare il prompt agli agenti AI. Dovresti progettare loop che facciano loro il prompt." Poco dopo, Boris Cherny—il creatore di Claude Code—ha detto più o meno la stessa cosa su Acquired Unplugged: "Non faccio più prompt a Claude. Ho dei loop che girano. Sono loro che fanno il prompt a Claude."

E poi è successo quello che succede sempre: tutti hanno iniziato a discutere, nessuno ha capito cosa cavolo fosse un loop, e il dibattito è diventato un casino di astrazione.

Io ho iniziato a far girare loop concreti qualche mese fa. Non perché fossi in anticipo sulla curva—semplicemente mi ero rotto di fare lavoro manuale di triage e l'ho automatizzato. Quello che ho scoperto mi ha sorpreso: la mentalità da loop non è una tecnica avanzata per power user. È un'evoluzione naturale che succede quando smetti di trattare gli agenti AI come sofisticati copia-incolla e inizi a trattarli come sistemi che possono monitorare, decidere e agire per te.

I Tre Sabori di "Loop" su Cui Nessuno È d'Accordo

Ecco perché questa conversazione diventa confusa: quando la gente dice "loop", potrebbe intendere una di tre cose, e le differenze contano.

Primo: il loop di task autonomi—fondamentalmente "continua finché non è finito". Pensa allo script Ralph di Geoffrey Huntley (while :; do cat PROMPT.md | claude-code; done), oppure al comando /goal che Codex e Claude Code ora includono nativamente. È la modalità "imposta e dimentica".

Secondo: il loop programmato o event-driven—lavoro che gira mentre tu non sei alla scrivania. L'esempio canonico è lo stesso HEARTEBEAT.md di Steinberger in OpenClaw: una checklist che l'agente riconsidera ogni 30 minuti. Discendenti di questo pattern includono le automazioni di Codex e le routine programmate di Claude Code.

Terzo: orchestration fan-out—workflow dinamici con più agenti che girano contemporaneamente. Le operazioni in stile map/reduce di Claude Code cadono qui. È più vicino al modello ad attori che a un semplice loop.

Il mio punto? Steinberger e Cherny descrivono il secondo tipo, collegato al primo. I loop che faccio girare io sono programmati ed event-driven all'esterno, e diversi di loro eseguono loop interni in stile esperimento una volta triggerati. È quella combinazione che dà il vero vantaggio.

Il PR Babysitter: La Mia Porta d'Ingresso al Design dei Loop

Avevo già la revisione codice AI su ogni pull request. Claude revisionava per primo, poi Codex con la sua revisione integrata, poi una GitHub Action personalizzata dove controllavo esattamente cosa vedeva il modello—recuperando il contesto completo della conversazione più il diff della patch.

Il mio workflow reale era assurdo: facevo submit di un PR, aspettavo le revisioni, poi copy-pastavo i commenti nell'agente. A volte incollavo screenshot. Era manuale, ripetitivo, e svuotava l'anima.

Un giorno ho chiesto al mio agente: "Non puoi usare il client gh e controllare tu lo stato della revisione?" Poteva. Quindi, naturalmente: "Non puoi continuare a controllare e dirmi quando è finito?"

Quella singola richiesta ha trasformato il mio workflow. Ora l'agente monitora i cambiamenti di stato delle revisioni, recupera nuovo contesto, analizza i feedback, e fa il lavoro effettivo di affrontarli. Il loop finisce quando raggiunge una decisione di triage: accetta il feedback, spingi indietro, o escala a me.

Il pattern si generalizza benissimo: monitora i cambiamenti di stato in sistemi esterni, svegliati quando succedono, recupera contesto fresco, analizza, agisci, e fai triage. Una volta che vedi questa forma, inizi a trovarla ovunque. Il team di Codex distribuisce il proprio skill babysit-pr, e i documenti di Claude Code ora citano il babysitting dei PR come caso d'uso principale per il loro comando /loop.

Loop Interni: Far Girare gli Esperimenti dell'Agente

C'è un altro pattern di loop che ho apprezzato più lentamente: il loop esperimento. Il concetto di autoresearch di Andrej Karpathy mi ha fatto riflettere—lanciare molte iterazioni, misurare i risultati, tenere quello che funziona. L'ho puntato su un percorso Python lento e ho lanciato 49 esperimenti in un'ora, abbassando la latenza p95 da 339ms a 34ms per circa 24 dollari.

Lo stesso pattern si applica a problemi più difficili: debug del comportamento dell'agente in produzione. Quando qualcosa va storto—una traccia strana in Braintrust, feedback utente in Slack, o qualcosa che incontro io stesso—faccio partire un worktree, incollo la traccia, e invoco il loop di test.

Ecco cosa rende questo loop diverso: forza una disciplina che l'intuizione naive del modello combatte. Lasciato a sé, un modello codificherà "mai fare X, Y, Z" nel system prompt e overfitterà sull'unica traccia che gli hai mostrato. I riferimenti dello skill distillano la ricerca su perché quell'approccio fallisce, e il contratto del loop richiede un'ipotesi e una matrice di test.

Mi servono tre casi: quello originale che fallisce, un positivo adiacente che dovrebbe prendere lo stesso percorso, e un controesempio che dovrebbe prenderne uno diverso. Tre o quattro probe girano contemporaneamente contro dev locale, ricostituendo l'esatto contesto utente dalla traccia. Ogni run viene valutato su chiamate tool, latenza, delta token in input, e correttezza. Il modello non può barare memorizzando—deve effettivamente capire.

Cosa Cambia Davvero Quando Costruisci Loop

Il cambiamento più grande non è tecnico—è concettuale. Quando fai prompt a un agente, sei ancora tu a guidare. Sei il pedale dell'acceleratore, il navigatore, il controllore qualità. I loop invertono tutto. Diventi l'architetto di sistemi che si guidano da soli.

Questo non significa che l'autonomia totale sia l'obiettivo. Sono ancora io al gate del triage su tutto ciò che conta. I loop gestiscono la tediosità, il monitoraggio, la ripetizione. Io gestisco le chiamate di giudizio che contano davvero.

Il secondo cambiamento è che i loop ti costringono a essere esplicito sui criteri di successo. Un buon loop ha condizioni di uscita chiare, punti decisionali chiari, percorsi di escalation chiari. Non puoi costruire un loop senza definire cosa significa "fatto". Quella disciplina si riversa su tutto.

Terzo, i loop sono componibili. Il PR babysitter lavora insieme al loop esperimento. Controlli programmati triggerano risposte on-call. Inizi a costruire una libreria di comportamenti che lavorano insieme piuttosto che un mucchio di prompt one-off.

Il Punto di Partenza Pratico

Se vuoi sperimentare con i loop, inizia con qualcosa che hai già automatizzato male. Probabilmente hai una GitHub Action che fa qualcosa su schedule, o una sessione Claude Code che rilanci manualmente, o un processo di revisione che coinvolge copy-paste di output tra strumenti.

Prendi il più fastidioso. Chiediti: quale cambiamento di stato sto aspettando? Quale contesto serve all'agente quando quel cambiamento succede? Quale decisione deve prendere?

Poi costruisci il loop. Non deve essere elegante. Deve funzionare, e deve rimetterti in controllo del tuo tempo.

Le configurazioni complete, gli skill e il workflow CI dietro i loop che faccio girare sono in una repo snapshot pubblica: camwest/agent-skills. Non è un prodotto rifinito—è un sistema funzionante che evolve mentre imparo. Questo è il punto. I loop non sono una destinazione; sono una pratica.

Il dibattito sugli agenti AI sta affogando nell'astrazione. Ecco la versione concreta: smetti di fare prompt, inizia a costruire loop, e vedi cosa succede quando lasci che la macchina gestisca il monitoraggio mentre tu gestisci il senso.