L'ingegneria dei loop sta vivendo un momento di grande interesse. Scorrendo qualsiasi forum tecnico, troverete voci che sostengono che dovremmo smettere di trattare gli agenti AI come chatbot da istruire con prompt ingegnosi. Invece, dicono, dovremmo progettare dei loop: cicli autonomi che permettano a un agente di pianificare, eseguire, controllare il proprio lavoro e iterare mentre dormiamo. La proposta è seducente. Se il loop è ben costruito, l'agente rimane in carreggiata senza una costante supervisione umana, trasformando un intento grezzo in un output finito durante la notte.
Questa promessa funziona magnificamente in teoria. In pratica, la maggior parte degli agenti opera già in loop. Generano codice, ispezionano errori del compilatore o fallimenti dei test, applicano patch al codice ed eseguono nuovamente la suite. Quel ciclo di feedback di base non è nuovo. Ciò che i sostenitori chiedono ora è qualcosa di più ambizioso: un loop esterno che governi l'intero compito, non solo gli errori di sintassi. Costruire questo loop esterno è dove le cose si complicano, perché l'ingegneria del software è raramente un sistema chiuso con regole fisse.
Il problema della progettazione dei loop
Gli obiettivi di prodotto sono disordinati. Raramente si parte con una definizione di "done" perfetta. Più spesso, si scopre l'obiettivo reale mentre si è immersi nel processo di build. Un requisito che sembrava semplice su una lavagna si rivela avere casi limite che cambiano completamente la forma della soluzione. Quando si racchiude un agente in un loop rigido, quella rigidità diventa un limite. Il loop continua a colpire un obiettivo che potrebbe essere quello sbagliato. Peggio ancora, un loop flessibile a volte risolve l'impasse cambiando silenziosamente l'obiettivo per farlo corrispondere a qualsiasi output sia riuscito a produrre. Nessuno dei due esiti è utile. Uno spreca risorse di calcolo; l'altro distribuisce spazzatura con estrema sicurezza.
Il problema più profondo è il costo della specifica. Se si vuole che un loop giri senza supervisione, bisogna scrivere una specifica che anticipi quasi tutto. Cosa dovrebbe cambiare esattamente l'agente? Quale comportamento esistente è sacro e deve essere preservato? Sotto quali precise condizioni l'agente dovrebbe smettere di iterare? Quali rischi sono accettabili e quali effetti collaterali dovrebbero innescare un arresto immediato? Scrivere quel documento può richiedere più tempo che sedersi semplicemente con l'agente e guidarlo nel compito in tempo reale. Si paga una pesante tassa iniziale in cambio di un'automazione che ripaga solo se la verifica è drasticamente più economica dell'esecuzione.
Dove i loop danno davvero il meglio
Questo non significa che l'ingegneria dei loop sia inutile. Significa che è uno strumento specializzato, non una strategia universale. I loop brillano quando i costi di verifica si accumulano e i criteri di successo sono inequivocabili. Ci sono tre ambiti in cui questo tende a essere vero.
Lavoro meccanico di routine. Pensate ai compiti che fanno venire voglia ai senior engineer di andare in pensione: avviare applicazioni in una sequenza specifica, cliccare attraverso un'interfaccia di deployment per confermare ogni fase, cercare stringhe di errore note nei log dopo un rilascio tramite grep, o convalidare che un file di configurazione sia stato scritto su tutti i nodi corretti. Questi passaggi sono noiosi per gli esseri umani ma banali da verificare. Un loop può sorvegliare il processo, controllando gli endpoint di salute dopo ogni riavvio e effettuando il rollback al primo segno di problemi. L'umano definisce comunque il piano di rollout. Il loop si limita a eseguirlo con la pazienza di una macchina alle due del mattino.
Obiettivi di ottimizzazione misurabili. Quando il successo è un numero, i loop sono devastantemente efficaci. Abbassare la latenza p99 sotto i 150 millisecondi. Ridurre l'impronta di memoria del venti percento. Migrare un hot path da Python a Rust e assicurarsi che tutti gli unit test esistenti passino ancora. Il loop può generare una modifica, sottoporla a benchmark, mantenere la variante che ha spostato l'ago della bilancia e scartare il resto. Poiché la verifica è automatizzata e lo spazio di ricerca è ampio, il costo cumulativo della revisione manuale renderebbe questo lavoro impraticabile senza un loop. L'obiettivo è fisso. Il percorso è sconosciuto. Questo è il punto ideale.
Playbook operativi. La gestione degli incidenti e i ticket di supporto seguono spesso schemi che gli esseri umani hanno già individuato. Una specifica classe di errori di produzione richiede sempre la rotazione di una credenziale e la pulizia di una cache. Una categoria di richieste di supporto può essere risolta con un rimborso quando vengono soddisfatte tre condizioni specifiche. Un loop può monitorare questi trigger ed eseguire il playbook, scalando l'intervento solo quando lo schema si interrompe. Non decide che il playbook sia corretto; si limita a imporre la coerenza a una scala e a una velocità che gli ingegneri reperibili (on-call) non possono eguagliare.
Regolatori, non impostatori di riferimenti
Manca una distinzione cruciale in gran parte della conversazione attuale. I loop sono regolatori. Mantengono un sistema allineato a un obiettivo predeterminato, proprio come un termostato mantiene una stanza a settantadue gradi. Ma il termostato non sceglie i settantadue. Qualcuno ha dovuto decidere prima che quella fosse la temperatura giusta.
Applicato al software, questo significa che un agente all'interno di un loop può correggere bug, rifattorizzare funzioni o regolare parametri tutto il giorno. Non può, tuttavia, decidere quale funzionalità aiuti effettivamente il cliente o se un bug valga la pena di essere corretto prima della prossima release. Queste scelte richiedono giudizio sul contesto aziendale, sulle difficoltà dell'utente e sulle priorità strategiche. Gli agenti eseguono. Gli esseri umani decidono. Confondere le due cose è il modo in cui i team finiscono per avere sistemi splendidamente ottimizzati che risolvono il problema sbagliato.
L'ingegneria dei loop è utile, ma è limitata. Ti aiuta a far funzionare la macchina con disciplina e velocità. Non decide quale macchina costruire, per chi sia o cosa significhi il successo in termini umani. Il giudizio su quale funzionalità sia importante, quale rischio sia accettabile e quando l'obiettivo stesso debba cambiare, spetta a te. Costruisci loop per il lavoro che comprendi già abbastanza bene da poter essere verificato automaticamente. Mantieni il controllo su tutto il resto.
Questo articolo si basa su idee discusse originariamente da Isaac Hagoel in “Loop Engineering Minus The Hype.” Per altre discussioni sull'ingegneria, unisciti alla nostra community di apprendimento su Telegram.