Ogni due mesi, nel mondo dell’intelligenza artificiale, sembra cambiare tutto: cambiano i modelli, cambiano le promesse, cambiano perfino le parole d’ordine. Stavolta la formula da ricordare è “loop”. Non si tratta di una moda tecnica per addetti ai lavori, ma del meccanismo che sta trasformando gli agenti AI da sistemi che rispondono a sistemi che fanno, verificano, correggono e riprovano. Ed è proprio qui che si gioca una parte importante del prossimo salto dell’AI.
Un tweet che ha spostato l’asse
Il momento di cristallizzazione del paradigma ha una data precisa: 7 giugno 2026, praticamente ieri l’altro. Peter Steinberger, fondatore del progetto open-source OpenClaw e ingegnere di OpenAI, pubblica su X due frasi che raggiungono 2,2 milioni di visualizzazioni in pochi giorni: chi lavora con gli agenti di coding dovrebbe smettere di scrivere prompt e iniziare a progettare i loop che li generano al posto suo.
Quasi in contemporanea, Boris Cherny, il creatore e responsabile di Claude Code di Anthropic, offre la versione più limpida del concetto: il suo lavoro non è più scrivere prompt per Claude, ma scrivere i cicli che li producono in autonomia. Il nome “loop engineering” viene coniato da Addy Osmani, ingegnere di Google, in un altro post ampiamente condiviso che mette ordine nel dibattito.
Il termine ha radici più antiche: il pattern ReAct (Reason-Act) del 2022 era già un ciclo di ragionamento, azione e osservazione, e AutoGPT nel 2023 lo aveva reso autonomo con il problema notorio di non sapere quando fermarsi. La tecnica artigianale più citata nella pratica è il cosiddetto “ralph loop” del luglio 2025, un semplice ciclo scritto per la shell bash ideato dallo sviluppatore Geoffrey Huntley, che resettava il contesto a ogni iterazione, faceva completare all’agente un’unità discreta di lavoro, validava e ripartiva.
Con quel metodo Huntley decise di realizzare un progetto per dimostrare che la tecnica aveva senso. Costruì una cosa in particolare: Cursed, un linguaggio di programmazione esoterico (cioè linguaggio progettato a tavolino per mettere alla prova i limiti del design dei linguaggi informatici a scopo dimostrativo), spendendo solo (almeno, così si dice nei forum specializzati) 297 dollari in API: una cifra diventata un riferimento ricorrente nelle discussioni tecniche dell’epoca.
Cosa è un loop e come funziona
L’architettura di base è semplice nel concetto. Il ciclo fa quattro cose: invia un prompt all’agente, legge l’output prodotto, verifica se il compito è completato e, se non lo è, rilancia con l’errore riscontrato o con il passo successivo. L’ingegnere non sta più dentro il ciclo a dettare ogni mossa: scrive il ciclo, e il modello diventa una subroutine richiamata in modo iterativo. Con l’arrivo degli agenti AI questa trasformazione sta già ridisegnando i flussi di lavoro in molti ambienti professionali.
A rendere concreta questa astrazione sono i comandi /goal e /loop, introdotti da Claude Code nella versione 2.1.139 rilasciata a metà maggio 2026. Con /goal, il programmatore definisce una condizione finale verificabile (ad esempio, per la scrittura di codice: “tutti i test in test/auth passano con exit code 0 e lint è pulito“) e l’agente lavora per turni autonomi fino a quando quella condizione non risulta vera.
Con /loop, invece, l’agente viene rilanciato su un intervallo di tempo definito, utile per task ricorrenti senza una singola condizione di arrivo: dal monitoraggio delle pull request al clustering dei feedback ogni trenta minuti. OpenAI Codex ha introdotto lo stesso meccanismo nella versione 0.128.0 del 30 aprile 2026, a conferma che l’approccio sta convergendo verso uno standard condiviso.
Il verifier: la parte più difficile
La distinzione più critica del comando /goal non è nella ripetizione meccanica, ma nella verifica indipendente. Dopo ogni turno dell’agente-esecutore, un modello separato e più veloce, legge il transcript e decide se la condizione finale è soddisfatta. Un modello che ha prodotto il codice tende sistematicamente a sovrastimare la correttezza del proprio lavoro e, se incaricato di giudicare i propri output, dichiara “fatto” su quasi tutto. Separare il ruolo di chi produce da quello di chi controlla è la mossa che rende il ciclo affidabile.
Dynamic Workflows di Anthropic, la funzione che coordina centinaia di sub-agenti in parallelo, porta questo principio alla scala industriale: Claude Code insieme a Opus 4.8 può eseguire migrazioni sull’intera codebase, dall’avvio fino al merge, usando la suite di test esistente come metro di valutazione automatica. Sul fronte dei costi, la variabile critica non è più il costo per milione di token, ma il numero di iterazioni prima della convergenza: un loop mal progettato che gira sei volte costa sei volte di più di uno che converge al primo tentativo, a prescindere dal modello scelto.
Isolamento e memoria su disco
Quando i loop diventano multipli e girano in parallelo, entra in gioco un altro problema: quello dell’isolamento dei file sui quali gli agenti stanno lavorando. Due agenti che modificano gli stessi file in contemporanea producono conflitti imprevedibili nel repository. Per fortuna degli ingegneri del software e degli agenti AI, esistono già delle tecniche pensate per gestire questo tipo di soluzioni, soprattutto con i software di controllo delle versioni che tracciano tutte le modifiche fatte alla codebase, cioè al repository con il codice, come ad esempio Git creato da Linus Torvalds (sì, proprio quello di Linux).
Ecco quindi la soluzione: sono i git worktree, checkout privati uno per ogni sub-agente, che si creano all’avvio e si eliminano al completamento. Senza questo meccanismo, far girare più agenti in parallelo sullo stesso progetto significa “corrompere” i singoli file in modo silenzioso.
C’è anche un altro aspetto importante: la memoria. I modelli di frontiera vengono addestrati in fasi discrete e ogni nuova sessione riparte da zero rispetto al contesto del progetto. La soluzione emersa è mantenere la memoria su disco: nel caso di Claude Code, un file CLAUDE.md dove vengono registrate le convenzioni, i progressi e gli errori già incontrati, aggiornato dall’agente stesso ogni volta che incontra una lezione nuova. Con l’integrazione degli agenti in ambienti come Xcode, questa memoria esternalizzata è diventata parte dell’infrastruttura nativa di sviluppo, non più un’aggiunta artigianale. Il principio si applica a qualsiasi forma di persistenza esterna al contesto: board, code, file markdown, database.
Dove è già arrivato il paradigma
I risultati in contesti produttivi sono numerici. Stripe ha distribuito Claude Code a 1.370 ingegneri e un team ha completato in quattro giorni una migrazione da Scala a Java di diecimila righe di codice, lavoro stimato in dieci settimane-persona. Ramp ha ridotto dell’80% il tempo di indagine sugli incidenti di produzione integrando lo stesso strumento nel flusso di sviluppo. Da notare che con Xcode 27 di Apple, l’ambiente di sviluppo si apre agli agenti di Claude e di Codex di OpenAI tramite il Model Context Protocol (MCP), con accesso diretto a test, anteprime e simulatore.
La direzione convergente dei principali strumenti, da Claude Code a OpenAI Codex fino al progetto open-source crabfleet di OpenClaw, è sempre la stessa: una coda di task visibile come board, esecuzione duratura che sopravvive alla chiusura del laptop, sub-agenti che avviano altri sub-agenti, escalation umana quando il budget è esaurito.
Nvidia e Microsoft con RTX Spark hanno portato questa architettura fino al livello hardware, progettando macchine per far girare agenti in locale ventiquattro ore su ventiquattro. Il loop, insomma, non è più un’astrazione per i forum tecnici e smanettoni entusiasti delle tecnologie AI. Invece, è già diventata una vera infrastruttura, utilizzata da ingegneri del software che lavorano per software house o per grandi aziende a “progetti veri” destinati ad andare in produzione.
Almeno, fino al prossimo cambiamento di paradigma, tra un paio di mesi.
Tutte le notizie e gli approfondimenti sull’intelligenza artificiale sono disponibili nella sezione dedicata di macitynet.
