A giugno 2026 Addy Osmani ha dato un nome a una cosa in cui molti di noi erano scivolati senza saperla chiamare: il loop engineering. L'idea è che smetti di fare prompt agli agenti a mano e invece "progetti il sistema che lo fa" al posto tuo, un ciclo ricorsivo in cui definisci un obiettivo e l'agente itera finché non ha finito [1]. Boris Cherny, che ha costruito Claude Code, l'ha detto senza giri di parole: "non faccio più prompt a Claude, ho dei loop che fanno prompt a Claude" [1]. Peter Steinberger ha detto lo stesso dalla trincea: "non dovresti più fare prompt agli agenti di coding, dovresti progettare i loop che fanno prompt ai tuoi agenti" [1].
Il frame è corretto, e la scala che ci sta dietro è reale: prompt engineering, poi context engineering, poi harness engineering, poi loop engineering, ognuno che avvolge il precedente [1][2]. Quello che voglio contestare è la conclusione che molti solo dev ne stanno traendo, cioè "il prompting è finito, le parole hanno smesso di contare". È una lettura sbagliata, e costosa. Un loop non ripara un prompt debole. Esegue quel prompt su base ricorsiva, non presidiato, ancora e ancora, e toglie l'unica cosa che prima intercettava un turno sbagliato: tu, sulla sedia, che leggi l'output. Il loop engineering non manda in pensione il prompt management. È l'argomento più forte a suo favore uscito finora.
Cosa è davvero il loop engineering
Non sono qui a contestare il salto di quota, perché è reale. Ogni gradino della scala avvolge quello sotto. Il prompt engineering sono le parole che invii. Il context engineering è tutto ciò che il modello vede attorno a quelle parole. L'harness engineering è l'ambiente in cui gira l'agente. Il loop engineering è il ciclo in cima: il trigger, l'iterazione e la condizione di stop che guidano un agente verso un obiettivo senza che tu piloti ogni turno [1][2].
I componenti elencati da Osmani rendono concreta la forma: automations schedulate, git worktree per isolare agenti in parallelo, Skills salvate come convenzioni in SKILL.md, connettori MCP verso tool esterni, sub-agent che separano il maker dal checker, e memoria esterna perché lo stato sopravviva tra un run e l'altro [1][2]. È una disciplina reale ed è la direzione in cui va il lavoro agentico serio. Niente di tutto questo è in discussione qui.
Quello che è in discussione è cosa succede al prompt quando sali questa scala. E la risposta, nascosta in bella vista in quell'elenco di componenti, è che il prompt non sparisce. Viene sepolto, ripetuto e lasciato solo.
La scala del loop engineering: quattro livelli impilati, dal prompt engineering alla base (le parole), al context engineering (tutto ciò che il modello vede), all'harness engineering (l'ambiente in cui gira l'agente), fino al loop engineering in cima (il ciclo ricorsivo che guida l'agente). Un segnalino sul livello in cima dice: qui hai lasciato la sedia, quindi il prompt alla base ora gira non presidiato
I tuoi prompt possono migliorare. Promptimizer li riscrive e li testa automaticamente.
La lettura sbagliata: "smetti di fare prompt" non è "i prompt hanno smesso di contare"
Rileggi le citazioni con attenzione. Cherny e Steinberger parlano di chi fa il prompting, non di se il contenuto del prompt conti. "Ho dei loop che fanno prompt a Claude" ha comunque qualcosa che fa prompt a Claude. Il prompting si è spostato dalle tue dita a un sistema. Le parole in sé non sono evaporate; sono state promosse a payload del loop, dove girano più spesso e con meno supervisione di prima.
L'elenco dei componenti di Osmani lo tradisce due volte. Le Skills salvate come SKILL.md sono prompt codificati: le convenzioni e le istruzioni riutilizzabili che l'agente porta in ogni run. E "tieni il maker lontano dal checker", la separazione in sub-agent che raccomanda, è un passo di verifica, cioè l'ammissione che gli output del loop vanno giudicati da qualcosa di diverso dal loop che li ha prodotti [1]. Un loop è impalcatura costruita attorno ai prompt. Il prompt resta l'atomo che il loop ripete. Il loop engineering cambia chi preme il grilletto, non se il colpo in canna sia buono.
Un loop è un amplificatore
Il prompting interattivo aveva una rete di sicurezza che probabilmente non hai mai contato come tale: leggevi ogni risposta e aggiustavi il turno successivo. Se un prompt era un po' vago, intercettavi lo scostamento al secondo turno e lo correggevi. Quella rete non è una proprietà del tuo prompt. È una proprietà del fatto che tu sei presente.
Un loop cancella quella rete di proposito. L'autonomia è tutto il punto. Quindi un prompt che era "abbastanza buono" perché lo pilotavi tu ora gira senza nessuno che lo piloti. Osmani nomina il rischio direttamente: i loop non presidiati fanno errori non presidiati, e il drift è il fallimento a cui torna di continuo [1][2]. È la proprietà di amplificazione. Uno spigolo che ignoravi quando lo correggevi a mano non resta uno spigolo attraverso decine di iterazioni non presidiate; si accumula, e il loop va avanti perché niente al suo interno sa che l'output è peggiorato. Il loop scala qualunque cosa sia il prompt, difetti inclusi, e li scala mentre tu non stai guardando.
Questo ridefinisce tutto l'esercizio. Più sali la scala, più ogni ripetizione non presidiata dipende dalla qualità della scatola proprio in fondo. Non puoi salire e smettere di curare la base. Sali, e la base porta più peso per ogni run, non meno.
Tre cose che un loop pretende dai prompt che contiene
Se il loop deve eseguire i tuoi prompt senza presidio, quei prompt devono meritarsi la fiducia che il loop gli concede. Tre requisiti ne discendono in modo diretto, e tutti e tre sono prompt management, non loop design.
Le tecniche che stai leggendo funzionano. Testa subito i tuoi prompt con Prompt Score e vedi il punteggio in tempo reale.
1. Versionato. Modificherai i prompt e le skill dentro un loop; è normale. Ma quando la qualità dell'output di un loop cala, la prima domanda è "quale versione del prompt ha eseguito", e se la risposta è "quella che c'era nel file in quel momento", non puoi fare debug e non puoi tornare indietro. Un prompt che gira non presidiato in un loop senza uno storico delle versioni è una regressione che non risalirai mai alla causa.
2. Valutato a monte. Tutta la promessa del loop è che non stai guardando ogni turno, il che significa che la qualità non può essere una cosa che controlli a posteriori. Va misurata prima di consegnare il prompt al loop. La separazione maker-checker di Osmani è esattamente questo istinto: qualcosa di diverso dal generatore deve giudicare l'output. Un punteggio sui tuoi input reali è quel controllo, anticipato, così il loop parte da un prompt che sai già tenere invece che da uno che speri tenga.
3. Portabile. I loop cambiano modello e spezzano il lavoro tra sub-agent, spesso instradando i passi economici ad alto volume verso un modello più piccolo e facendo escalation di quelli difficili. Un prompt saldato al formato di un fornitore si rompe in silenzio nel momento in cui il loop instrada quel passo altrove. La stessa disciplina di portabilità che conta quando gestisci i prompt per gli agenti conta il doppio dentro un loop, perché è il loop, non tu, a decidere quale backend esegue il turno successivo.
Una matrice intitolata le tre pretese che un loop fa sui prompt che contiene. Riga uno, versionato: sapere quale versione del prompt ha eseguito il loop, così una regressione è tracciabile e reversibile. Riga due, valutato a monte: la qualità è misurata prima che il loop giri non presidiato, perché non stai guardando ogni turno. Riga tre, portabile: il prompt sopravvive quando il loop cambia modello o instrada un passo a un sub-agent. In fondo: il loop è nuovo, la disciplina del prompt sotto di esso no
Cosa si è rotto quando ho messo un task in un loop
Ho preso un task ricorrente che facevo a mano e l'ho avvolto in un loop: un trigger, un agente, un verificatore, una regola di stop. Il prompt interno era uno che usavo in modo interattivo da settimane e consideravo solido. Lasciato girare senza presidio, è andato in deriva. Un edge case che in una sessione live avrei individuato e corretto sul momento è passato, e siccome niente nel loop sapeva che quell'output era sbagliato, il loop ha portato avanti l'errore e ha continuato a iterarci sopra.
Il mio primo istinto è stato aggiustare il loop: regole di stop più strette, un sub-agent verificatore più forte, più guard-rail attorno al ciclo. Era il livello sbagliato. Il loop faceva esattamente quello che gli avevo detto. Il problema era l'atomo che ripeteva, un prompt che era sempre stato "a posto" solo perché lo rattoppavo in silenzio a ogni turno. La correzione vera era a monte: fissare il prompt a una versione, valutarlo contro gli edge case che mi mordevano, e solo allora lasciarlo girare al loop senza presidio. Una volta solida la base, il loop era solido. Stavo cercando di fare ingegneria attorno a un prompt debole invece di sistemarlo, che è esattamente la trappola da cui Osmani mette in guardia quando dice di costruire il loop "come chi intende restare l'ingegnere" [1].
Un diagramma a due pannelli, prima e dopo. Pannello sinistro, la correzione sbagliata: un prompt debole sta al centro di un loop, e l'ingegnere continua ad aggiungere regole di stop, verificatori e guard-rail tutto intorno mentre la deriva continua. Pannello destro, la correzione giusta: lo stesso prompt è versionato e valutato contro gli edge case prima che il loop lo esegua, e il loop attorno resta semplice e tiene
Il segnale
Il loop engineering è la quota giusta per il lavoro agentico, e non è una moda; il campo si sta davvero spostando dallo scrivere prompt al progettare i sistemi che li scrivono. Ma "progetta il loop" non ha mai voluto dire "trascura l'atomo che il loop esegue". La scala non ti libera dalla base. Le impila peso sopra, perché ogni gradino che aggiungi è un altro livello di automazione che ripete quel prompt di base senza di te nella stanza.
La frase di chiusura di Osmani è tutta la disciplina in una riga: costruisci il loop, ma costruiscilo come chi intende restare l'ingegnere [1]. Restare l'ingegnere significa possedere il prompt che il loop ripete. Significa versionarlo perché una regressione sia tracciabile, valutarlo perché tu ti fidi prima che se ne fidi il loop, e tenerlo portabile perché il loop possa instradarlo ovunque. Il loop è la parte nuova. La disciplina sotto è la parte più vecchia di tutta questa scala, ed è appena diventata portante.
Keep My Prompts ti permette di tenere una copia canonica e versionata di ogni prompt e skill, valutarla su sei criteri di qualità sui tuoi input e confrontarla tra modelli, così i prompt che i tuoi loop eseguono senza presidio sono quelli che hai già confermato tenere. Gratis per iniziare, senza carta di credito.
