Dagli agenti basati su prompt al Loop Engineering

Un'affermazione sta circolando nei circoli del coding con AI: smetti di fare prompt ai tuoi agenti di coding e inizia a progettare loop che fanno prompt per te. Come ogni novità, questa cosa viene ripetuta spesso e spiegata raramente. Questa è la versione pratica: cos'è un agent loop, perché è importante e che aspetto ha in produzione.

Qui sotto puoi leggere alcuni dei miei pensieri (scritti con l'aiuto di Claude) da alcuni esperimenti, ricerche e conversazioni che ho avuto con alcuni dei nostri studenti, founder tecnici, ingegneri AI e startup.

Potresti anche trovare la nostra recente sessione live su "Autonomous Long-Running Coding Agents" come un buon punto di partenza per tutto questo.

Da dove viene l'affermazione

"Non dovresti più fare prompt agli agenti di coding. Dovresti progettare loop che fanno prompt ai tuoi agenti." Peter Steinberger (

@steipete ), 7 giugno 2026. 2,2 milioni di visualizzazioni.

Tweet originale

Boris Cherny, il creatore di Claude Code, fa lo stesso punto dall'altro lato.

"Non faccio più prompt a Claude. Ho loop che sono in esecuzione. Sono loro a fare prompt a Claude e a capire cosa fare. Il mio lavoro è scrivere loop." Boris Cherny (

@bcherny ).

Tweet originale

Il punto non è che l'ingegneria dei prompt sia morta. Con l'ingegneria dei loop, il lavoro sale di livello, dallo scrivere il codice allo scrivere il sistema che scrive il codice. Gli sviluppatori più avanti su questo percorso riportano mesi in cui hanno spedito centinaia di PR senza aprire un IDE, con ogni riga scritta dall'agente.

Cosa è realmente un loop

Un loop è un piccolo programma che scrivi e che fa quattro cose:

• fa prompt all'agente di coding per te,
• legge ciò che ha prodotto,
• decide se è finito,
• e se non lo è, fa di nuovo prompt con l'errore o il passo successivo.

Smetti di stare dentro al loop a digitare prompt; scrivi il loop e il modello diventa una subroutine che il loop chiama.

La forma è sempre la stessa: imposta un obiettivo, agisci, controlla, reinserisci l'errore e ripeti finché il controllo passa o il loop si ferma da solo.

"Loop" significa almeno cinque cose

Gran parte del disaccordo deriva da persone che usano una parola per cinque idee diverse. Ecco la progressione, dalla più vecchia alla più nuova.

• ReAct (2022). Il pattern di ricerca originale: ragiona, agisci, osserva, ripeti.
• AutoGPT (2023). Un loop di obiettivi auto-prompting, famoso per non sapere quando fermarsi.
• ralph loop. Un reset deliberato del contesto tra le iterazioni in modo che l'agente non anneghi nella propria cronologia.
• /loop e /goal. La cadenza e le condizioni di completamento sono integrate nell'agente, portando lo stato tra un turno e l'altro.
• orchestrazione. Un autore distribuisce molti agenti che leggono il tuo GitHub, Slack e chat, e decidono cosa costruire dopo.

Le parti che assembli realmente

La progressione spiega cosa le persone intendono per loop; questo è ciò di cui un loop è fatto. Le stesse sei parti si presentano sempre, e oggi la maggior parte è integrata negli strumenti di coding invece di essere script personalizzati che mantieni tu.

• Un trigger. Qualcosa che avvia il loop senza che tu prema "avvia": un programma, un webhook, una modifica a un file, un'etichetta che arriva su una PR. Questo è ciò che separa un vero loop da una singola esecuzione che ripeti a mano.
• Isolamento. Un checkout privato per agente, di solito un git worktree, così due agenti in esecuzione contemporanea non possono sovrascrivere i file l'uno dell'altro. Appena ne esegui più di uno, questo smette di essere opzionale.
• Contesto scritto. Le convenzioni, i passaggi di build e le regole specifiche del progetto vengono conservati dove l'agente li legge a ogni esecuzione. Se lo salti, il loop re-deriva il tuo progetto da zero ogni volta e indovina i vuoti.
• Accesso ai tuoi strumenti. Connettori al tracker dei problemi, CI, database e chat, così il loop può aprire la PR, collegare il ticket e pubblicare il risultato invece di stampare una correzione e aspettare che tu la porti fino in fondo.
• Un secondo agente controlla. Un worker separato che valuta l'output è tenuto separato da quello che lo ha prodotto, perché un modello che revisiona il proprio lavoro approva quasi tutto.
• Stato su disco. Un file markdown, una bacheca o una coda: qualcosa al di fuori della conversazione che registra cosa è finito e cosa viene dopo. Il modello dimentica tra un'esecuzione e l'altra; il file no.

Assembla questi sei elementi e avrai un buon punto di partenza per l'ingegneria dei loop. Una volta costruivi tutto a mano; ora la maggior parte è disponibile come funzionalità integrate, motivo per cui il pattern è passato da tecnica di nicchia a uso comune.

Un loop concreto: il babysitter delle PR

Un esempio concreto che puoi costruire oggi:

• Trigger. Ogni 15 minuti.
• Ambito. PR aperte etichettate agent-watch.
• Azione. Se la CI è rossa per un motivo deterministico, tenta una correzione. Se il main è avanzato, fai un rebase una volta.
• Budget. Un tentativo di correzione per PR, cinque minuti, dieci file modificati.
• Condizione di arresto. CI verde, o budget esaurito, poi fermati e notifica un umano.

Torni a PR unite invece che a un arretrato di build rotte. La stessa forma copre la maggior parte del lavoro operativo:

• Salute della CI. Ogni 30 minuti, prendi le esecuzioni fallite e raggruppale per firma, così dieci PR rosse con una causa principale diventano una cosa da guardare.
• Verifica del deploy. Dopo un push, colpisci i tuoi endpoint, conferma 200 e i contenuti attesi, e segnala le regressioni prima che lo facciano gli utenti.
• Clustering dei feedback. Ogni 30 minuti, prendi i commenti dai tuoi canali, raggruppali per temi e mappa ogni cluster al file o documento che lo possiede.

Un loop concreto di Claude Code con /goal

Il babysitter è un loop che cabli tu stesso; aiuta anche vedere uno che è integrato nell'agente. In Claude Code, il loop completo più piccolo è /goal: gli dai uno stato finale verificabile e lui continua a fare turni finché quello stato non è vero.

Ecco un esempio di /goal usato come comando in-sessione in Claude Code. Avvii la sessione, poi imposti l'obiettivo al suo interno:

1$ claude  # avvia Claude Code
2$ /goal tests in test/auth pass   # imposta l'obiettivo all'interno della sessione

È la stessa forma di agisci, controlla, ripeti di prima, con il verificatore integrato.

A questo punto è chiaro che un buon /goal assomiglia più a un contratto che a un prompt. Quelli buoni specificano quattro cose: lo stato finale che vuoi, le prove che dimostrano che lo hai raggiunto, i vincoli che l'agente non deve infrangere per arrivarci e il budget di lavoro che può spendere. Se lasci uno di questi vago, il modello riempie il vuoto con l'interpretazione più facile: si ferma presto, prende una scorciatoia o ridefinisce il successo così che il transcript sembri finito mentre il sistema reale è rotto.

• Imposta la condizione. Digita /goal più uno stato finale verificabile, ad esempio /goal tests in test/auth pass. Il primo turno inizia immediatamente.
• L'agente lavora un turno. Modifica, esegue i test e mostra i risultati nella sessione.
• Un valutatore controlla. Un modello veloce legge il transcript e decide se è soddisfatto o meno, così l'agente non valuta il proprio lavoro.
• Loop o fine. Non soddisfatto significa un altro turno con guida; soddisfatto significa che l'obiettivo si cancella da solo e l'esecuzione si ferma.

Lo stato passa da un turno all'altro, quindi non si ferma presto o lascia cadere un vincolo a metà. Alcuni controlli lo mantengono affidabile:

• Rendi il controllo misurabile. Un risultato di test, un codice di uscita, un conteggio di file o una coda vuota. npm test exits 0 è un obiettivo; "miglioralo" no.
• Limita l'esecuzione. Aggiungi qualcosa come "o fermati dopo 20 turni" così un loop bloccato si ferma invece di consumare turni.
• Abbinalo alla modalità auto così i turni vengono eseguiti senza supervisione e usa /goal clear per abbandonarlo presto.

Il passo del valutatore nasconde una sottigliezza utile: il controllore non deve essere lo stesso modello del programmatore. Una volta che il loop ha ruoli distinti (pianificatore, esecutore, valutatore, revisore visivo), ognuno può funzionare su un modello diverso, e scegliere quale modello ricopre quale ruolo diventa una decisione architetturale piuttosto che una singola scommessa su un "miglior" agente di coding. Alcuni modelli pianificano meglio, altri eseguono più economicamente, altri giudicano uno screenshot più accuratamente, e un buon orchestratore ti permette di scambiarli per ruolo invece di aspettare che un singolo fornitore vinca in ogni categoria.

Funziona bene per migrazioni di API (sposta ogni punto di chiamata finché compila e i test passano), refactoring (dividi un file finché ogni modulo è sotto budget), arretrati di issue (lavora una coda etichettata finché è vuota) e loop di valutazione (ottimizza un prompt finché il punteggio supera una soglia). /loop è la controparte per lavoro senza un singolo traguardo: invece di una condizione di completamento, ripete il prompt su base programmata, che è come un loop come il babysitter delle PR continua a funzionare.

Eseguire molti loop senza supervisione

Un singolo loop /goal è un agente che lavora verso un singolo traguardo. Eseguire molti processi senza supervisione alza la posta in gioco, perché un loop è affidabile solo quanto la sua capacità di controllare il proprio lavoro. La configurazione di Cherny per eseguire Opus autonomamente per ore si riduce a cinque passaggi:

1. Auto-approva i permessi così l'agente non si ferma a chiedere a ogni chiamata di strumento.
2. Usa workflow dinamici (inserisci Ultracode nel prompt) per distribuire il lavoro su molti agenti invece di un unico thread seriale.
3. Usa /goal o /loop per mantenerlo in esecuzione. /goal imposta una condizione di completamento, /loop ripete il prompt su base programmata, ed entrambi portano lo stato, quindi non si ferma presto.
4. Eseguilo nel cloud (app desktop o mobile) così la sessione sopravvive quando chiudi il laptop.
5. Dagli un modo per auto-verificarsi end-to-end. Claude in Chrome per il web, un simulatore MCP per il mobile e un server live per il backend. Questo è il passaggio che rende sicuri gli altri quattro.

La sequenza completa:

1claude --permission-mode auto                          # 1 · nessuna richiesta di approvazione
2ultracode  orchestrate sub-agents to ship the feature  # 2 · distribuisci
3/goal all tests pass and the demo loads clean          # 3 · continua
4→ cloud / desktop app                                  # 4 · chiudi il laptop
5→ chrome ext · sim MCP · live server                   # 5 · auto-verifica, poi fermati

crabfleet: orchestrazione come prodotto

L'orchestrazione è più facile da immaginare con uno strumento concreto. Il crabfleet di Peter Steinberger, un progetto OpenClaw pubblicizzato come "mission control for agent runs", è un loop confezionato come prodotto, e la sua forma si mappa su tutto quanto sopra.

• Lavoro come carte su una bacheca. I compiti vengono inseriti come carte costruite da un prompt, una issue GitHub o una PR, poi si spostano attraverso todo, running, human review e done. Quella bacheca è la coda del loop e il suo passo di stop e report, reso visibile.
• Esecuzioni durevoli, non fire-and-forget. Ogni esecuzione è un tentativo tracciato con heartbeat, quindi continua quando distogli lo sguardo e sopravvive alla chiusura del laptop. Subentri solo quando il runtime pubblicizza che supporta il passaggio di consegne.
• Agenti che generano agenti. Un'esecuzione può avviare sessioni figlie, inviare messaggi, leggere transcript e aggiornare il proprio riepilogo dall'interno di un sandbox: memoria su disco e distribuzione in un unico posto, un autore e molti agenti.

Funziona su sandbox cloud usa e getta con terminali basati su browser, ed è ciò che rende sicuro allontanarsi da un'esecuzione senza supervisione. Il punto non è lo strumento specifico, ma che il loop si è indurito in infrastruttura: una coda, esecuzione durevole, distribuzione e un gate di revisione umana sono ora cose che configuri invece di scriptare a mano ogni volta.

Dove va il costo ora

Per due anni, la domanda sul costo nel coding con AI è stata semplice: quale modello e quanti token. All'interno di un loop, quell'istinto punta al livello sbagliato. La spesa non è più una singola chiamata, ma quante volte il loop gira, quindi un loop che riprova sei volte prima di convergere costa sei volte tanto quanto uno che atterra al primo passaggio, sullo stesso modello.

Questo cambia ciò che vale la pena ottimizzare:

• Le iterazioni sono la voce di budget, non i token. Un modello più economico che fa il doppio dei loop non è più economico, quindi tieni traccia del costo per attività completata, non del costo per chiamata.
• Un verificatore debole è il bug più costoso che puoi rilasciare. Se il controllo che decide "fatto" è lasco, il loop o si ferma presto su lavoro rotto, o continua su lavoro che era già a posto, ed entrambi sprecano iterazioni complete. Stringi questo prima di qualsiasi altra cosa.
• Fallire velocemente è un controllo dei costi. Un loop senza un limite massimo di fallimenti consecutivi non alla fine ha successo; alla fine prosciuga il conto, quindi la condizione di arresto protegge la bolletta tanto quanto il codice.

Una volta ottimizzavi il prompt; ora ottimizzi il loop, perché è lì che si accumula il costo.

Quando non usare un loop

I loop ripagano quando un compito si ripete e una macchina può dire quando è finito. Al di fuori di questo, un loop automatizza solo il caos. Saltalo in questi casi:

• Modifiche una tantum. Se riesci a finirlo in un singolo passaggio, un loop è puro overhead.
• Lavoro senza ambito o esplorativo. "Scopri perché gli utenti se ne vanno" non ha una condizione di passaggio, quindi il loop non converge mai.
• Qualsiasi cosa senza un controllo automatizzato economico. Se l'unico verificatore sono i tuoi occhi, sei ancora dentro al loop. Costruisci prima il controllo, o fai il compito a mano.

Cosa può andare storto

Un loop che funziona mentre dormi commette anche errori mentre dormi, e le modalità di fallimento sono prevedibili.

• L'onere della verifica rimane umano. Il loop scrive più velocemente di quanto tu possa revisionare, quindi se smetti di leggere i diff, non hai rimosso il lavoro, lo hai solo rimandato.
• I gap di comprensione si allargano. Spedire codice che non hai scritto, più velocemente di quanto tu possa assimilarlo, erode il modello del tuo stesso sistema, e quel debito torna a farsi sentire durante il prossimo incidente.
• Deriva silenziosa su un controllo lasco. Un verificatore debole lascia passare lavoro sbagliato ma apparentemente corretto a ogni iterazione, quindi il loop sembra produttivo mentre scava una buca.

Niente di tutto ciò è un argomento contro i loop; è il motivo per cui l'ingegnere che progetta il loop conta di più, non di meno.

Come costruire il tuo

1. Scegli un compito ripetibile. Fare da babysitter alle PR, sistemare la CI, verificare i deploy: inizia con lavoro di routine.
2. Definisci un ambito ristretto. "Sistema la validazione del webhook di fatturazione, tocca solo app/api/billing e lib/billing" è meglio di "sistema il bug". Un loop lasco vaga.
3. Dagli un budget e una condizione di arresto. Tentativi massimi, runtime massimo, file massimi, spesa massima, fallimenti consecutivi massimi. Un loop che funziona senza supervisione è anche un loop che commette errori senza supervisione.
4. Aggiungi un verificatore indipendente. Un sub-agente separato valuta il lavoro, perché l'agente che ha scritto il codice è il peggior giudice di se sia finito.
5. Eseguilo con una cadenza. /loop per un intervallo, cron per un programma, hook nei punti del ciclo di vita o GitHub Actions così sopravvive alla chiusura del laptop.
6. Mantieni la memoria su disco. Il modello dimentica tra un'esecuzione e l'altra, quindi lo stato vive in markdown o su una bacheca, non nella finestra di contesto.

Il messaggio finale: il loop, non il modello, è ora la parte costosa e soggetta a errori. Costruiscilo come qualcuno che intende rimanere l'ingegnere responsabile dell'output, non solo la persona che avvia l'esecuzione.

Se vedi errori o cose che necessitano di ulteriori chiarimenti, non esitare a contattarmi.

Altri Riferimenti Utili

• Addy Osmani (@addyosmani), sui loop di coding assistiti dall'AI
• Matt Van Horn (@mvanhorn), "WTF Is a Loop?"
• Peter Steinberger (@steipete), sulla progettazione dei loop
• Boris Cherny (@bcherny), sull'esecuzione autonoma degli agenti