Loop engineering: il gradino arrivato a giugno mentre guardavamo altrove

Su questo blog c'è una scala che è stata salita un gradino alla volta. Prima il prompt engineering dichiarato morto, perché scrivere bene la singola richiesta aveva smesso di essere la competenza che faceva la differenza. Poi il context engineering: non cosa chiedi, ma cosa l'agente ha davanti quando glielo chiedi. Poi l'harness engineering, cioè costruire l'ambiente in cui l'agente lavora invece di correggerlo a mano.

C'è un quarto gradino, ed è arrivato a giugno. Si chiama loop engineering, e chi lo sostiene dice che rende obsoleti i tre precedenti. Chi lo critica dice che è un cron job con il cappuccio.

Ho letto le fonti originali invece dei riassunti, e la cosa interessante è che hanno ragione tutti e due. Ma il punto vero sta in un posto che nessuna delle due tifoserie guarda.

Cos'è, detto da chi l'ha nominato

Il 7 giugno Addy Osmani pubblica un saggio intitolato Loop Engineering, ripubblicato due settimane dopo su O'Reilly Radar. La definizione è di una riga:

"You design the system that does it instead. A loop here can be thought of as a recursive goal where you define a purpose and the AI iterates until complete."

Non stai più promptando l'agente. Progetti il sistema che lo prompta al posto tuo. Il loop è un obiettivo ricorsivo: definisci uno scopo, l'agente itera finché non è raggiunto.

Osmani elenca cinque componenti, più uno che aggiunge dopo:

Automations: task di discovery e triage schedulati, che partono da soli
Worktrees: ambienti paralleli isolati, perché due agenti sullo stesso file collidono
Skills: la conoscenza di progetto codificata in file riusabili, per non rispiegare il contesto ogni volta
Connettori MCP: il collegamento verso issue tracker, chat, database
Sub-agent: agenti separati per ideare, implementare e verificare, perché chi scrive il codice non è l'esaminatore giusto del proprio lavoro
Memoria esterna: file markdown o board che tengono traccia fra un giro e l'altro

L'esempio che porta è concreto e vale più della definizione. Un'automazione parte ogni mattina, legge i fallimenti della CI e le issue aperte, apre worktree isolati dove un subagent scrive le correzioni e un altro le rivede contro le skill di progetto e i test, e i connettori aprono le pull request e aggiornano i ticket. Nessuno ha promptato niente: qualcuno ha progettato il giro.

Perché non è (solo) un rebrand

L'obiezione arriva subito ed è legittima: prompt, context, harness, loop. Quattro nomi in due anni, ognuno col suo ciclo di entusiasmo e la dichiarazione che il precedente non serve più. Chris Hood l'ha messa in un titolo che è già una recensione: "We Renamed Automation Again and Called it Loop Engineering".

C'è però una differenza strutturale che regge, ed è nella gerarchia. L'harness definisce l'ambiente di una singola esecuzione: quali tool ha l'agente, cosa può toccare, cosa vede. Il loop sta un livello sopra e aggiunge tre cose che l'harness non ha: quando parte, quante cose girano in parallelo, e quando si ferma.

E non è materiale da blogger entusiasta. Peter Steinberger l'ha compresso nella frase che ha fatto il giro: "You shouldn't be prompting coding agents anymore. You should be designing loops." Ma la citazione che pesa di più è di Boris Cherny, che guida Claude Code in Anthropic, e che diceva la stessa cosa da settimane prima:

"My job is to write loops."

Il capo del prodotto che più di ogni altro definisce come si lavora con gli agenti descrive il proprio mestiere così. Non è una moda di X.

La parte onesta

Detto questo, le obiezioni serie non sono battute e vanno prese una per una.

"Chi ha scritto la condizione di uscita?" È la più affilata. Se il criterio di arresto lo definisce un umano, il loop non è autonomo: è uno script con dentro un modello. E se non lo definisce nessuno, il loop non finisce, oppure finisce quando ha esaurito il budget. In entrambi i casi l'autonomia dichiarata è meno autonoma di come viene raccontata.

Il limite empirico è peggio. Gli agenti restano meno affidabili proprio sui task lungo-orizzonte ad alto valore economico, che sono esattamente quelli che i loop dovrebbero conquistare. Sui lavori più difficili anche i sostenitori ammettono che il tasso di successo si arrotonda a zero. Un loop non trasforma un agente inaffidabile in uno affidabile: lo fa sbagliare più volte, più in fretta, senza che tu guardi.

E il rebrand, in parte, c'è davvero. Automazione schedulata, isolamento dei processi, memoria su file: sono idee vecchie di decenni. Chi le presenta come nuove sta vendendo il nome, non la sostanza.

Dove hanno ragione tutti e due

Il punto che scioglie la contraddizione è che l'autonomia è la parte facile. Far girare qualcosa ogni mattina è un cron. Farlo girare in parallelo su worktree separati è ingegneria nota. La parte difficile, quella che decide se un loop produce valore o danno, è un'altra: la verifica e la condizione di uscita.

Osmani lo scrive nel suo stesso pezzo, in tre righe che chi lo cita salta sistematicamente:

"Verification is still on you. A loop running unattended is also a loop making mistakes unattended."

"Your understanding still rots if you allow it."

"The comfortable posture is the dangerous one."

Sono avvertimenti dell'autore, non della sua opposizione. E cambiano il senso di tutto il resto: il loop non toglie la verifica dal tavolo, la sposta. Prima verificavi il singolo output; adesso devi progettare chi verifica, e assicurarti che non sia lo stesso agente che ha prodotto il lavoro.

È il motivo per cui il quinto componente dell'elenco, i sub-agent verificatori, non è un dettaglio architetturale ma il pezzo che regge tutto. Con l'avvertenza che i sub-agent costano, e un verificatore in più su ogni giro è una moltiplicazione, non un'addizione.

Non serve costruirlo da zero

La cosa che nella discussione si perde, e che invece è la più utile per chi lavora, è che i cinque componenti non sono da inventare. Se usi Claude Code li hai già tutti, con altri nomi o con gli stessi:

le automazioni sono i job schedulati e le routine
i worktree sono git worktree, che esiste dal 2015
le skill sono letteralmente file SKILL.md, stesso nome
i connettori sono i server MCP che probabilmente hai già configurato
i sub-agent sono una funzione del prodotto, non un pattern da implementare

Il loop engineering, tolto il nome, è un modo di comporre pezzi che hai già in casa. Non è una tecnologia da adottare: è una decisione su come metterli insieme, e soprattutto su dove piazzare i punti in cui il giro si ferma e chiede.

Che è anche il motivo per cui si lega al pezzo di domenica su le regole da togliere dal CLAUDE.md. Se il controllo si sposta nel loop, le istruzioni statiche nel file diventano il posto sbagliato dove metterlo. Non perché siano inutili, ma perché stanno un gradino sotto.

Il gradino dopo, e quello prima di tutti

C'è un ultimo modo di guardarlo, ed è quello che rende la faccenda meno nuova e più solida.

Nel 1956 Ross Ashby formula la legge della varietà necessaria: un controllore può governare un sistema solo se ha almeno tanta varietà quanti sono gli stati che il sistema può assumere. Un prompt ha varietà fissa. Un file di regole ha varietà fissa. Un loop con dentro una verifica ha varietà quasi illimitata, perché genera risposte nuove a situazioni che non avevi previsto.

Ecco perché la scala prompt → context → harness → loop non è una sequenza di mode: è la stessa idea che sale di livello ogni volta che il livello sotto smette di bastare. È il loop cibernetico che Wiener descriveva nel 1948, applicato a un agente che scrive codice.

Con una condizione, però, che è tutto il contenuto dei tre avvertimenti di Osmani: la varietà la dà il verificatore, non l'automazione. Un loop senza una verifica vera non è un controllore a varietà alta. È un cron job col cappuccio, e a quel punto i critici hanno ragione loro.

Se stai per costruirne uno, la domanda da cui partire non è cosa automatizzare. È: cosa controlla che sia andata bene, e quando si ferma. Il resto è scheduling.

Fonti: