Loop Engineering: come creare agenti AI che si auto-migliorano

L'AI non ti ruberà il lavoro. Ma un professionista che sa progettare loop di automazione intelligenti, forse sì. E la cosa più affascinante? Questi loop stanno già rivoluzionando il modo in cui sviluppatori e consulenti utilizzano gli AI agents.

Quando ho iniziato a esplorare Claude e i framework agentici, il mio workflow era lineare: scrivevo un prompt, ottenevo una risposta, iteravo manualmente. Oggi, con il loop engineering, quel processo può auto-sostenersi per ore, giorni o settimane. Senza che io debba intervenire a ogni passo. In questo articolo ti mostro come siamo passati dal prompt engineering al loop engineering, e perché questo cambio di paradigma è più di un semplice trend.

Dal Prompt Engineering al Context Engineering: l'evoluzione del controllo

Partiamo dalle basi. Il prompt engineering consisteva nel definire con precisione le istruzioni da dare al modello: "Sei un copywriter", "Sei un analista di dati", "Rispondi in tono formale". Scrivevi un system prompt — spesso lungo migliaia di token — e il modello rispondeva in base a quel contesto iniziale. Claude, ad esempio, utilizza system prompt strutturati con sezioni come task, context, examples, success criteria, constraints. Questa fase è ancora fondamentale, ma è solo il primo strato.

Il passo successivo è stato il context engineering : il modello non si limita più a rispondere, ma accede autonomamente a file, web, database e app esterne (grazie a protocolli come MCP). Diventa un agente. Il problema? Ogni chiamata a un tool riempie la finestra di contesto del modello (la context window). Anche con 1 milione di token disponibili, oltre i 200.000 le performance degradano — fenomeno noto come context rot. Il context engineering si concentra quindi su tecniche di compaction: riassumere, pulire, liberare spazio per continuare a operare.

Funziona, ma è inefficiente. Ogni riassunto perde dettagli, e i task complessi richiedono troppe iterazioni manuali.

Harness Engineering: strutturare il lavoro in fasi autonome

Qui entra in gioco l'harness engineering. Invece di comprimere il contesto all'infinito, si crea un'impalcatura esterna che suddivide il task in step sequenziali. Ogni step utilizza l'intera context window disponibile, poi scrive i risultati su file locali (tipicamente in formato Markdown: memory.md, history.md, agent_state.md) e svuota la memoria per ripartire pulito allo step successivo.

Questa architettura trasforma il file system in un'estensione della memoria del modello. L'agente legge e scrive file, utilizza tool come memory_search per recuperare informazioni semantiche o dirette, e procede in autonomia. È l'approccio che ho visto implementato in framework come CrewAI e in agenti generalisti come Windsurf o Cursor (basati su architetture simili).

L'harness engineering permette di gestire progetti lunghi — clonare un sito web complesso, migrare un servizio, addestrare un modello — senza saturare la memoria del modello. Ma richiede ancora che tu avvii manualmente ogni task, verifichi i risultati, e rilanci il processo.

Loop Engineering: l'agente che si fa le domande (e le risposte)

Il loop engineering è l'ultimo strato: metti l'intero harness dentro un ciclo automatico. Non scrivi più prompt iterativi. Definisci un obiettivo, una condizione di uscita, e lasci che l'agente cicli fino al raggiungimento del goal. È un loop su loop su loop: il modello chiama i suoi tool (primo loop), completa gli step del harness (secondo loop), e ripete l'intero processo finché non è soddisfatto o raggiunge un limite predefinito (terzo loop).

Facciamo un esempio pratico. Ho chiesto a Claude Code (usando il comando /loop) di creare un portale web per monitorare risultati sportivi. L'agente ha generato l'app, ma invece di fermarsi lì, l'ho messa in loop: ogni volta che rileva nuove notizie (trigger), riscrive il codice, aggiorna i link, sistema il layout. Senza che io debba riaprire l'editor.

Un altro caso d'uso: ho pubblicato un'app open source su GitHub. Usando loop engineering, ho configurato un ciclo che monitora le issue aperte. Quando un utente segnala un bug, l'agente legge l'errore, analizza il codice, propone una fix, testa la soluzione e committa la modifica. Tutto in autonomia. Il mio ruolo? Definire il trigger (issue su GitHub) e la condizione di uscita (problema risolto e test passati).

Struttura di un loop: trigger, execution, verifica, memoria

Ogni loop ben progettato si basa su quattro elementi:

• Trigger : evento che avvia il ciclo (temporale: "ogni giorno alle 9", oppure event-driven: "quando ricevi una mail", "quando viene aperta una issue")
• Execution : l'harness esegue il task, chiamando tool e scrivendo risultati su file
• Verifica : l'agente controlla se la condizione di uscita è soddisfatta
• Memoria : i risultati vengono salvati su file Markdown o database, pronti per il loop successivo

Il comando /loop in Claude permette di settare intervalli temporali: /loop ogni mattina alle 9:00 aggiorna il report. Il comando /goal permette di definire obiettivi verificabili: /goal ottimizza il codice finché il caricamento della pagina non scende sotto i 100ms | fai al massimo 50 tentativi.

Cinque livelli di verifica: quando il loop funziona (e quando no)

La parte più delicata del loop engineering è la condizione di uscita. Se il goal non è verificabile, il loop diventa infinito o inutile. Ho individuato cinque livelli di verifica, dal più deterministico al più soggettivo:

1. Verifica deterministica : condizioni booleane. Esempio: "L'app compila senza errori". True o false, nessuna ambiguità.
2. Regole e vincoli numerici : soglie misurabili. Esempio: "Il tempo di caricamento è sotto i 100ms", "L'accuratezza del modello supera il 90%". Verificabili con benchmark.
3. Verità ritardata : risultati che maturano nel tempo. Esempio: "Il post su LinkedIn raggiunge 300 reazioni". Il loop può girare ogni giorno, controllare i risultati passati, e auto-migliorarsi in base al feedback del mondo reale. Ottimo per campagne pubblicitarie, contenuti virali, esperimenti A/B.
4. LLM come giudice : il modello si auto-valuta. Esempio: "Clona questa pagina web finché non sei soddisfatto della UI". L'agente confronta screenshot dell'originale con il render della sua versione, assegna un punteggio (da 0 a 1), e continua a iterare finché non raggiunge 0.90. Meno preciso, ma utile per task creativi o estetici.
5. Checkpoint umano : sei tu a validare ogni iterazione. Il loop si ferma, ti mostra il risultato, e aspetta il tuo feedback. Meno automatico, ma necessario per decisioni strategiche o compliance.

I primi tre livelli sono ideali per il loop engineering. Il quarto funziona bene per sviluppo UI, refactoring, ottimizzazioni algoritmiche. Il quinto è un fallback quando l'automazione completa non è sicura.

Test reale: ottimizzare il prodotto tra matrici con loop engineering

Ho voluto testare il loop engineering su un problema classico: ottimizzare il calcolo del prodotto tra matrici. Ho creato uno script Python base che moltiplica matrici di dimensioni crescenti (500x500, 1000x1000, 2000x2000, 3000x3000) e misura i tempi di esecuzione. Risultati iniziali: 0.04s, 0.18s, 1.90s, 3.98s.

Poi ho lanciato il comando: /goal migliora i tempi di esecuzione del prodotto tra matrici, scrivi i risultati su file Markdown con log delle modifiche | fai al massimo 10 tentativi.

Claude ha iniziato a ciclare: primo tentativo, ha passato da float64 a float32. Secondo tentativo, ha introdotto NumPy con multi-threading. Terzo tentativo, ha spostato il calcolo su GPU usando PyTorch e CUDA. Decimo tentativo: ha attivato i Tensor Core con float16 (half precision) per massimizzare il throughput.

Risultato finale: speedup di 320x rispetto allo script originale. Tempo finale per la matrice 3000x3000: circa 0.012s. Il file optimization_log.md conteneva tutte le modifiche applicate, step by step, senza che io dovessi scrivere un singolo prompt intermedio.

Questo è il vero potenziale del loop engineering: delegare l'ottimizzazione iterativa a un processo autonomo, con piena tracciabilità.

Quando usare il loop engineering (e quando evitarlo)

Il loop engineering è potente, ma non è la soluzione universale. Funziona meglio quando:

• Il task è ripetitivo e ben definito (refactoring, test automatici, aggiornamenti periodici)
• La condizione di uscita è verificabile (performance misurabili, test unitari, threshold numerici)
• Il feedback è automatico o ritardato ma tracciabile (issue su GitHub, metriche di engagement, risultati di training)

Evitalo quando:

• Il goal è vago o soggettivo ("Migliora il design", "Rendi il testo più coinvolgente") senza criteri misurabili
• Il task richiede decisioni strategiche o contestuali che solo un umano può prendere
• Il costo computazionale del loop supera il beneficio (troppi token consumati per risultati marginali)

Nel mio caso, uso loop engineering per task di sviluppo (ottimizzazione codice, test automatici, deploy continui) e per automazioni di marketing (aggiornamento report, monitoraggio campagne con Make o n8n). Per contenuti strategici o analisi complesse, preferisco ancora un approccio iterativo manuale con Claude o OpenRouter.

Il loop engineering non sostituisce il pensiero critico. Ma libera tempo prezioso per concentrarsi su decisioni ad alto valore, mentre l'AI si occupa dell'esecuzione ripetitiva. E forse, proprio qui, sta la vera evoluzione: non "chi usa l'AI", ma "chi sa progettare sistemi che usano l'AI in autonomia". Fino a quando, però, continueremo a essere noi a definire i loop — e non viceversa?