LOOP ENGINEERING: IL PERCORSO IN 20 STEP DA PROMPTER A SYSTEM DESIGNER

Nel giugno 2026, tre persone sono arrivate indipendentemente alla stessa idea in una sola settimana.

Peter Steinberger, il creatore di OpenClaw, ha dichiarato pubblicamente che dovresti smettere di fare prompt a agenti di coding e iniziare a progettare i loop che li fanno prompt. Quasi contemporaneamente, Boris Cherny, che guida Claude Code in Anthropic, ha detto di non fare più prompt direttamente a Claude, ma di avere loop in esecuzione che fanno prompt a Claude e decidono cosa fare, e che il suo vero lavoro è scrivere loop. Giorni dopo, Addy Osmani, un ingegnere di Google, ha scritto il termine e gli ha dato un nome: loop engineering.

Nessuno di loro ha inventato la pratica dal nulla. Hanno dato un nome a qualcosa che stava già accadendo, perché gli strumenti sottostanti avevano silenziosamente superato una soglia. Gli agenti di coding erano diventati abbastanza affidabili da completare un compito reale senza supervisione. La pianificazione era diventata abbastanza economica che eseguire un compito ripetutamente, con un timer, non sembrava più uno spreco. Il costo di una singola esecuzione dell'agente era sceso abbastanza che provare qualcosa cinque volte costava meno che pensarci attentamente una volta.

Quella soglia è il motivo per cui esiste questa roadmap. Fare prompt era l'abilità quando un umano doveva sedersi alla tastiera e dirigere un agente riga per riga. Loop engineering è l'abilità ora che l'agente può ricevere un obiettivo e essere lasciato eseguire. Questo è il percorso completo in 20 passi dall'uno all'altro, in ordine, perché l'ordine conta più di ogni singolo passo.

Ecco perché l'ordine conta specificamente, prima dei passi stessi. Loop engineering non è un'unica abilità che hai o non hai. È una pila, dove ogni strato dipende da quello sottostante che sia effettivamente solido. Costruire un trigger di pianificazione, passo 14, prima di avere una vera condizione di stop, passo 10, significa solo che hai automatizzato un sistema che ora può sprecare denaro senza supervisione invece di sprecare solo mentre guardi. Costruire la persistenza, passo 11, prima di avere una vera verifica, passi 6 e 7, significa che stai registrando attentamente le lezioni apprese da un Giudice che potrebbe timbrare output errati, il che rende lo strato di persistenza attivamente dannoso anziché semplicemente inutile. Saltare avanti in questa lista non significa solo perdere una funzionalità. Significa costruire le parti appariscenti su una base che non può sostenerle, e scoprirlo solo quando qualcosa è già andato storto su larga scala.

Fase Uno: Il Cambiamento Mentale (Passi da 1 a 4)

Passo 1: Accetta che sei tu il collo di bottiglia, non il modello

Il primo vero passo non è tecnico. È ammettere che il fattore limitante nel tuo flusso di lavoro attuale non è la capacità del modello, ma la tua presenza nel loop. Ogni volta che ti siedi e aspetti una risposta, la leggi, poi scrivi l'istruzione successiva, sei la parte più lenta del sistema con un ampio margine. Il modello può agire, verificare e riprovare molto più velocemente di quanto tu possa supervisionarlo.

Questo passo non ha un prompt associato. È una decisione. Finché non ci credi davvero, ogni passo successivo sembrerà un overhead inutile invece di quello che è: rimuovere il vero collo di bottiglia.

Passo 2: Smetti di confondere un prompt più lungo con un sistema migliore

L'istinto quando qualcosa va storto è aggiungere un'altra istruzione allo stesso prompt. Nel corso dei mesi, questo produce un prompt che è un muro denso e contraddittorio di regole che il modello non può più tenere contemporaneamente nella memoria di lavoro, quindi fa pattern-matching su ciò che sembra più recente e lascia cadere silenziosamente il resto.

Loop engineering sostituisce completamente questo istinto. Invece di aggiungere un'altra regola a un prompt, aggiungi un altro componente a un sistema. Un passo di verifica. Un file di memoria. Un trigger programmato. Il prompt stesso dovrebbe accorciarsi nel tempo man mano che il sistema circostante diventa più capace, non il contrario.

Passo 3: Impara a vedere ogni compito come cinque mosse

Ogni singolo giro di un loop, indipendentemente dal dominio specifico, si decompone in cinque mosse. Scoperta: capire cosa deve effettivamente accadere. Passaggio: affidare il compito a chi lo eseguirà. Verifica: controllare il risultato rispetto a qualcosa di reale. Persistenza: registrare cosa è successo in modo che non venga perso. Pianificazione: decidere quando viene eseguito di nuovo.

La maggior parte delle persone ha attualmente solo due di queste mosse esplicite, scoperta e passaggio, fatte manualmente, in una finestra di chat. Le altre tre non esistono o accadono invisibilmente nella testa della persona. Loop engineering è la pratica di rendere tutte e cinque le mosse esplicite e automatiche.

Passo 4: Identifica il tuo primo vero compito candidato

Prima di costruire qualsiasi cosa, scegli un compito che già fai ripetutamente, con uno standard che potresti scrivere se ti venisse chiesto. Non il tuo problema più difficile. Non qualcosa di completamente nuovo. Un compito con una definizione di completamento reale e riconoscibile, qualcosa che un collega potrebbe guardare e immediatamente concordare se è stato completato correttamente o meno. Questo vincolo conta più di quanto sembri. Un compito senza una chiara definizione di completamento non può avere il passo tre, verifica, costruito per esso, e un loop senza una vera verifica non è un loop, è solo un'ipotesi senza supervisione.

Fase Due: Costruire il Primo Loop (Passi da 5 a 9)

Passo 5: Scrivi la Definizione di Completamento Prima di Scrivere Qualsiasi Prompt

Questo è il passo che la maggior parte delle persone salta e quello che determina se tutto ciò che segue funziona. Prima di scrivere una singola istruzione per l'agente, scrivi, in linguaggio semplice, esattamente come appare un risultato corretto. Criteri specifici e verificabili, non una vaga sensazione di qualità.

DEFINIZIONE DI COMPLETAMENTO per [nome compito]:

• [Criterio specifico e verificabile 1]
• [Criterio specifico e verificabile 2]
• [Criterio specifico e verificabile 3] Questo compito NON è completato se manca uno qualsiasi dei precedenti, anche se l'output sembra completo o rifinito.

Se non riesci a compilare questo per il tuo compito scelto, torna al passo 4 e scegline un altro.

Passo 6: Separa il Costruttore dal Giudice

La decisione architetturale più importante in qualsiasi loop. Il ruolo che produce il lavoro e il ruolo che controlla il lavoro devono essere separati, perché un modello che rivede il proprio output nello stesso respiro in cui lo ha prodotto tende a difendere quell'output piuttosto che esaminarlo genuinamente.

Il Costruttore ha libertà creativa e produce un primo tentativo. Il Giudice riceve l'output del Costruttore più la definizione di completamento dal passo 5, e nient'altro di cui ha bisogno per essere dissuaso. Idealmente, il Giudice ha anche accesso a qualcosa che il Costruttore non ha: una suite di test, il documento originale, dati live, in modo che il suo verdetto provenga da prove reali, non solo da una seconda opinione formata allo stesso modo della prima.

Passo 7: Dai al Giudice la Verità di Base, Non Solo un'Opinione

Un Giudice che vede solo l'output del Costruttore può dirti se sembra coerente. Non può dirti se è effettivamente corretto. Per compiti di coding, la verità di base è la suite di test e l'output di esecuzione effettivo. Per compiti di contenuti, è il materiale originale e il brief, affiancati alla bozza. Per compiti di ricerca, sono i documenti effettivi che dovevano essere utilizzati.

Se non sai nominare la specifica verità di base che il tuo Giudice controllerà, il tuo loop non ha ancora una vera verifica, non importa quanto sicuro suoni il linguaggio del Giudice.

Passo 8: Scrivi il Formato di Passaggio Prima di Scrivere il Prompt di Passaggio

L'output del Costruttore e il verdetto del Giudice devono entrambi avere una struttura definita, non prosa libera, altrimenti il Manager nel passo successivo non ha nulla di affidabile su cui instradare.

OUTPUT DEL COSTRUTTORE: deliverable + confidenza + incertezze note

VERDETTO DEL GIUDICE: PASS / FAIL / NECESSITA REVISIONE + problemi specifici trovati + verità di base controllata

Passo 9: Eseguilo Manualmente Una Volta, Fino in Fondo, Prima di Automatizzare Qualcosa

Prima di collegare la pianificazione o i tentativi automatici, esegui l'intera sequenza Costruttore-poi-Giudice da solo, a mano, una volta. Leggi criticamente il verdetto del Giudice. Saresti d'accordo? Se il Giudice ha approvato qualcosa che sai essere sbagliato, o ha bocciato qualcosa che in realtà andava bene, correggi la verità di base o i criteri prima di procedere. Automatizzare un passo di verifica rotto produce solo risultati errati più velocemente.

Un Esempio Pratico Attraverso i Passi da 5 a 9

Per rendere concreti gli ultimi cinque passi, ecco come si applicano a un compito reale e comune: trasformare un documento sorgente grezzo in un contenuto finito.

La definizione di completamento, dal passo 5: ogni affermazione fattuale nella bozza risale a qualcosa effettivamente presente nel documento sorgente. La bozza soddisfa ogni requisito specifico nel brief: lunghezza, tono, struttura richiesta. L'argomento centrale sopravvive chiaramente, senza essere diluito da riempitivi.

Il Costruttore, dal passo 6, riceve la sorgente e il brief e produce una bozza, insieme a una dichiarazione esplicita di ciò di cui non era sicuro mentre scriveva: un numero di cui non era completamente sicuro fosse nella sorgente, un'affermazione che ha inferito piuttosto che trovato dichiarata esplicitamente.

Il Giudice, dal passo 7, riceve la bozza e la sorgente originale affiancate, mai la bozza da sola, e controlla ciascuno dei tre criteri della definizione di completamento separatamente, restituendo un pass o fail per ognuno individualmente, non un unico punteggio combinato. Collassare tre controlli distinti in un unico verdetto nasconde esattamente quale dimensione è effettivamente fallita, che è il modo più comune in cui un loop funzionante smette silenziosamente di dare feedback utili.

Il formato di passaggio, dal passo 8, significa che il verdetto del Giudice arriva come un oggetto strutturato, non un paragrafo di prosa cauta: tre risultati espliciti pass o fail con un motivo specifico allegato a qualsiasi fallimento.

Eseguire questo manualmente una volta, per il passo 9, prima di automatizzare qualsiasi cosa, è ciò che coglie il caso in cui il tuo Giudice è troppo indulgente, approvando una bozza con una statistica inventata perché lo stile di scrittura era rifinito, o troppo severo, bocciando una bozza per una preferenza stilistica che non era mai stata nel brief. Entrambi i modi di fallire sono comuni al primo tentativo, ed entrambi sono molto più economici da cogliere manualmente una volta che da scoprire dopo che il loop ha già eseguito cinquanta volte senza supervisione.

Fase Tre: Aggiungere i Pezzi Mancanti del Loop (Passi da 10 a 14)

Passo 10: Costruisci il Manager e la sua Condizione di Stop

Il Manager legge il verdetto del Giudice e decide cosa succede dopo. Qui vive anche la condizione di stop del loop, e deve essere scritta come logica rigida, non come un'istruzione morbida che il modello può aggirare parlando.

CONDIZIONI DI STOP:

Revisioni massime: 3. Al 3° verdetto fallito, segnala a un umano con la cronologia completa, non tentare un 4° ciclo.

Soglia di qualità: ogni elemento nella definizione di completamento deve mostrare PASS.

Limite di budget: se questo compito supera [X] costo o [Y] tempo, fermati immediatamente indipendentemente dallo stato attuale.

Un loop senza una vera condizione di stop non è un sistema. È una responsabilità in attesa del giorno in cui il compito si rivela genuinamente irrisolvibile. Il motivo specifico per cui un'istruzione morbida fallisce qui vale la pena di essere compreso, non solo accettato. "Fermati quando è abbastanza buono" all'interno di un prompt è un suggerimento, e un modello sotto sufficiente pressione, avendo già fallito diverse revisioni, spesso si convincerà che il tentativo attuale sia abbastanza vicino per passare, proprio perché vuole produrre una risoluzione soddisfacente del compito. Un contatore di iterazioni rigido controllato meccanicamente dal codice, o da una regola esplicita che il Manager non può aggirare ragionando, non ha quel modo di fallire.

Passo 11: Aggiungi la Persistenza, in modo che il Loop Ricordi tra le Esecuzioni

Un loop che parte da zero ogni volta che viene eseguito non ha memoria di ciò che ha imparato la volta precedente. Aggiungi un semplice strato di persistenza: un file per ogni lezione genuinamente nuova, con un riepilogo di una riga in cima, registrando cosa è stato appreso o corretto e perché era importante. Fondamentalmente, registra solo ciò che non è già catturato altrove; la memoria duplicata è rumore, non conoscenza.

La disciplina che fa funzionare realmente questo passo a lungo termine è la moderazione al momento della scrittura. L'istinto è registrare tutto ciò che è successo in una sessione, il che produce esattamente il problema del trascritto gonfio contro cui questa roadmap avvertiva al passo 2, solo spostato in una cartella di memoria invece che in un prompt. Una lezione che vale la pena scrivere è qualcosa che costerebbe tempo reale riscoprire se dimenticata, non un record di lavoro di routine che è riuscito esattamente come previsto.

Passo 12: Aggiungi un Passaggio di Consolidamento su una Pianificazione

La persistenza da sola alla fine produce lo stesso problema di un prompt gonfio: dozzine di file, molti dei quali dicono versioni leggermente diverse della stessa cosa. Su una pianificazione ricorrente, settimanale è ragionevole, rivedi i file di memoria, unisci i duplicati in lezioni singole più nitide ed elimina qualsiasi cosa si sia poi rivelata sbagliata. L'obiettivo è meno file con più densità ciascuno, non un mucchio in continua crescita.

Questo passo è quello che la maggior parte delle persone salta completamente, perché non produce alcuna nuova capacità visibile da solo, previene solo un problema futuro. Quell'invisibilità è esattamente il motivo per cui deve essere pianificato esplicitamente anziché lasciato accadere quando qualcuno nota che la cartella di memoria è diventata ingestibile, il che nella pratica significa che non accade mai finché le prestazioni del loop non hanno già iniziato a degradarsi sotto il peso di lezioni contraddittorie e semi-rilevanti che competono per la stessa finestra di contesto.

Passo 13: Aggiungi il Passaggio di Recupero

All'inizio di qualsiasi nuova esecuzione, fai in modo che il loop esamini i riepiloghi di una riga in memoria, identifichi quali lezioni sono effettivamente rilevanti per il compito corrente e carichi solo quelle. Istruisci esplicitamente a dire quando nulla in memoria si applica, piuttosto che forzare una lezione passata irrilevante su una nuova situazione solo perché la memoria esiste.

Passo 14: Aggiungi un Trigger di Pianificazione

Decidi quando questo loop viene eseguito senza che tu lo avvii manualmente. Un cron job. Un file watcher. Un trigger ricorrente basato sul calendario. Questo è il passo che trasforma un sistema che esegui su richiesta in uno che funziona mentre dormi, ed è solitamente il passo più semplice in tutta questa lista, e quello che la maggior parte delle persone non si preoccupa mai di implementare anche dopo aver costruito tutto il resto.

Fase Quattro: Scalare e Rafforzare (Passi da 15 a 18)

Passo 15: Metti alla Prova il Loop Sotto Stress Prima di Fidarti

Prima di fare affidamento su questo loop per qualsiasi cosa reale, testalo deliberatamente contro quattro modalità di fallimento.

Dagli una versione genuinamente irrisolvibile del compito e conferma che il Manager si ferma effettivamente invece di loopare all'infinito, poiché un loop che viene testato solo su compiti che può completare non ha mai dimostrato di saper fallire con garbo.

Alimenta il Giudice con un output che sai essere sottilmente sbagliato, qualcosa che si legge bene ma contiene un errore fattuale o logico specifico che hai piantato deliberatamente, e conferma che effettivamente coglie il difetto invece di approvare qualcosa di plausibile.

Se il Costruttore e il Giudice condividono lo stesso modello sottostante, alimenta il Giudice con un errore che quel modello commette caratteristicamente e vedi se lo fa passare, poiché un Giudice che condivide i punti ciechi del Costruttore vanifica l'intero scopo della separazione dal passo 6.

Calcola il costo peggiore del loop che esegue fino al suo limite massimo di revisioni, utilizzando le tue chiamate al modello più costose e l'output più lungo ragionevole, e decidi onestamente se quel numero, che appare su una fattura reale, ti allarmerebbe.

Eseguire questi quattro test prima di fidarsi di un loop con qualsiasi cosa che conta coglie la stragrande maggioranza dei fallimenti che altrimenti si presenterebbero per la prima volta di fronte a un cliente, un capo o il tuo stesso estratto conto, piuttosto che in un test controllato che hai eseguito apposta.

Passo 16: Instrada i Compiti al Modello Giusto, Non Sempre lo Stesso

Una volta che un loop funziona, resisti all'abitudine di eseguire ogni sua parte sul tuo singolo modello preferito. Il ruolo del Costruttore di solito beneficia del tuo modello più capace, poiché sta facendo il ragionamento duro effettivo e un modello più debole qui produce una prima bozza peggiore che costa più cicli di revisione per correggere di quanto sarebbe costato generarla bene la prima volta.

Il ruolo del Giudice, che controlla rispetto a uno standard scritto specifico, spesso funziona altrettanto bene su un modello più piccolo, più economico e più veloce, poiché non gli viene chiesto di essere creativo, solo coerente, e un modello più piccolo che controlla rispetto a una checklist estremamente ben specificata spesso eguaglia uno più grande a una frazione del costo e della latenza.

Il Manager, che instrada in base a regole che hai già scritto, quasi mai ha bisogno del tuo modello più costoso, poiché il suo lavoro è eseguire logica che hai già specificato, non ragionamento aperto, e viene eseguito almeno una volta per iterazione indipendentemente da come si comportano Costruttore e Giudice, il che rende il suo costo per chiamata più importante della sua capacità grezza.

Questo approccio a livelli, modello costoso per costruire, modello economico e coerente per giudicare i controlli di routine, modello economico per instradare, è di solito da dove arrivano i veri risparmi di costo in un loop. La maggior parte delle persone presume che il controllo dei costi significhi meno loop o meno revisioni. In realtà arriva dall'abbinare il costo del modello alla difficoltà effettiva di ogni ruolo specifico all'interno del loop che hai già costruito.

Passo 17: Espandi a un Secondo Loop, Non Cinque Contemporaneamente

La tentazione una volta che il primo loop funziona è costruirne subito molti altri, affrontando cinque compiti diversi in parallelo perché l'architettura tecnicamente lo supporta ora. Resisti più a lungo di quanto ti senti a tuo agio. Ottieni un loop funzionante abbastanza affidabile da aver smesso genuinamente di controllare da vicino il suo output, il che significa che supera costantemente i tuoi controlli a campione manuali per un periodo di tempo reale, non solo una singola demo di successo a cui tutti hanno assistito da vicino. Solo allora inizia il secondo loop, su un compito diverso, idealmente uno che si mappa su qualcosa di completamente diverso dal primo, in modo da testare se lo scheletro sottostante si generalizza piuttosto che solo sintonizzare ulteriormente lo stesso compito.

Passo 18: Datti una Vista Condivisa su Tutti i Loop in Esecuzione

Una volta che hai più di un loop in esecuzione, tieni traccia di una vista condivisa del costo e dei trigger di condizione di stop su tutti, non per loop in isolamento. Un singolo loop con un budget per compito ragionevole sembra completamente a posto da solo. Dieci loop ciascuno individualmente entro il budget possono comunque sommare un totale allarmante che nessuno nota finché non arriva la fattura aggregata, proprio perché il tracciamento di ogni singolo loop sembrava a posto in isolamento.

Registra ogni trigger di condizione di stop specificamente, non solo i completamenti con successo. Un loop che colpisce costantemente il suo tetto di revisioni, mentre altri raramente lo fanno, ti sta dicendo che lo standard del suo Giudice è mal calibrato, troppo severo per passare mai effettivamente, o sta controllando contro la verità di base sbagliata, non che il compito sottostante sia semplicemente difficile. Quel modello è invisibile se stai tracciando solo i successi e trattando ogni escalation come un evento isolato e insignificante piuttosto che come un dato sul design di quel loop specifico.

Fase Cinque: Diventare un Progettista di Sistemi (Passi 19 e 20)

Passo 19: Smetti di Misurarti in Base ai Prompt Scritti

Il segno più chiaro che il cambiamento è effettivamente avvenuto è un cambiamento in ciò a cui presti attenzione giorno per giorno. Un promptista tiene traccia di quanti buoni prompt ha scritto. Un progettista di sistemi tiene traccia di quanti loop sono in esecuzione, quanto è affidabile ciascuno e quanto del proprio tempo è stato restituito da sistemi che non hanno più bisogno di supervisione. Se stai ancora misurando la tua produttività in prompt digitati, il cambiamento mentale dal passo uno non è ancora atterrato completamente, indipendentemente da quanti loop hai tecnicamente costruito.

Passo 20: Insegna a Qualcun Altro le Cinque Mosse

Il passo finale non riguarda più i tuoi sistemi. È confermare che hai effettivamente interiorizzato il cambiamento spiegandolo a qualcun altro senza ricorrere al gergo. Scoperta, passaggio, verifica, persistenza, pianificazione. Se riesci a guidare un'altra persona attraverso la costruzione del suo primo loop usando solo quelle cinque mosse e i passi sopra, hai fatto la transizione effettiva che questa roadmap descrive. Non sei più la persona dentro il loop, che digita l'istruzione successiva. Sei la persona che lo ha progettato, stando fuori, guardandolo eseguire.

I Quattro Costi che si Accumulano Silenziosamente se Salta i Passi

Vale la pena chiudere con un avvertimento, poiché saltare passi in questa roadmap non fallisce rumorosamente, fallisce silenziosamente, in modi che si manifestano solo molto più tardi.

Il debito di verifica si accumula quando salti i passi 6 e 7, costruendo loop senza un vero Giudice o una vera verità di base. Il loop sembra funzionare perché l'output sembra a posto, fino a quando un errore non si accumula silenziosamente attraverso dozzine di esecuzioni prima che qualcuno se ne accorga.

Il marciume di comprensione si instaura quando salti il passo 20, eseguendo loop che hai costruito una volta ma non saresti più in grado di spiegare o debuggare se si rompessero, perché non hai mai dovuto interiorizzare perché ogni pezzo esisteva.

La resa cognitiva accade quando il passo 1 non atterra mai realmente, quando continui a ricontrollare manualmente ogni output per abitudine molto tempo dopo che il sistema di verifica si è già dimostrato, vanificando l'intero scopo di costruire il sistema in primo luogo.

L'esplosione di token è ciò che accade quando salti il passo 10, eseguendo loop senza una vera condizione di stop, scoprendo il costo effettivo solo quando arriva la fattura.

Ognuno di questi costi è evitabile, e ognuno è evitato dalla stessa disciplina. Costruisci i passi in ordine. Non saltare quelli che sembrano poco glamour. I passi noiosi, la definizione di completamento, la condizione di stop, la verità di base, sono quelli che fanno effettivamente il lavoro. Le parti che sembrano interessanti, il prompt intelligente, l'elaborato diagramma architetturale, contano molto meno del fatto che il sistema che hai costruito sappia effettivamente quando è giusto, quando è sbagliato e quando fermarsi.

Questa è l'intera distinzione tra un promptista e un progettista di sistemi. Non intelligenza. Disciplina sulle parti che sono noiose da costruire e facili da saltare.

Segui @cyrilXBT per i modelli di loop esatti e le configurazioni Costruttore-Giudice-Manager dietro ogni passo in questa roadmap.