Conversazione con Enrico Papalini su 'Non-Deterministic Loop Engineering'
Quando un anno fa avevamo parlato con Enrico Papalini del suo primo libro, il tema centrale era un patto silenzioso infranto: quello tra sviluppatori e macchine deterministiche, saltato nel momento in cui il codice ha smesso di fare sempre e comunque quello che gli veniva scritto. Papalini, Head of Software Development per Issuances, Custody, Data & UX/UI Solutions in Euronext Securities, con un passato in London Stock Exchange Group e Borsa Italiana, aveva raccontato quel passaggio con la voce di chi gestisce sistemi dove l'errore non è un'opzione contrattuale, è un incidente.
Da allora la conversazione si è spostata. Non basta più chiedersi cosa succede quando un modello genera una risposta sbagliata, perché la domanda vera riguarda cosa succede quando quel modello continua a lavorare da solo, per ore, prendendo decisioni, usando strumenti, modificando file, senza che nessuno stia guardando ogni singolo passaggio. È da qui che nasce il suo nuovo libro, Non-Deterministic Loop Engineering, dedicato non più al singolo output ma al ciclo che lo produce, lo verifica e decide se farlo ripartire.
Abbiamo ripreso il filo con lui, questa volta concentrandoci su un solo oggetto: il loop, la sua architettura, i suoi rischi, le domande che lascia aperte.
Dal patto al loop
Le due domande d'apertura servono a capire perché Papalini abbia deciso di isolare il loop come disciplina a sé, e se davvero si tratti di qualcosa di nuovo o di un rebranding di idee già note nel software.
Gli chiedo cosa lo abbia portato, dopo aver raccontato il passaggio dal determinismo al non-determinismo, a dedicare un intero libro proprio al loop, e come lo spiegherebbe in una sola frase a chi non mastica la materia.
"Il Prompt Engineering insegna a parlare con un modello. Il Loop Engineering progetta ciò che accade quando il modello continua a lavorare anche dopo che abbiamo smesso di parlargli," risponde Papalini. "È questo il passaggio che mi ha spinto a scrivere il libro. Finché usiamo l'AI come assistente, il ciclo è semplice: facciamo una domanda, riceviamo una risposta e la valutiamo. L'essere umano conserva il controllo a ogni passaggio. Ma quando introduciamo un agente, gli affidiamo un obiettivo più ampio. Il sistema legge lo stato del lavoro, sceglie un'azione, utilizza strumenti, modifica file o dati, controlla il risultato e decide se continuare. A quel punto il modello non è più il sistema. È soltanto un componente del sistema. Il vero oggetto ingegneristico diventa il loop che lo circonda: dove conserviamo l'obiettivo, come rappresentiamo lo stato, quali strumenti può usare, chi verifica il risultato, quante volte può riprovare, quanto può spendere e quando deve restituire il controllo a una persona. Ho isolato il loop perché molte aziende stanno passando dai copiloti agli agenti trattando questo cambiamento come un semplice aumento di potenza del modello. Non lo è. È un cambiamento nell'architettura del controllo."
La seconda domanda è la più scomoda, e gliela pongo senza troppi giri di parole: nel libro distingue quattro livelli, prompt, context, harness e loop engineering, eppure ReAct formalizzava già cicli di ragionamento e azione, mentre il maker-checker esiste da molto prima dell'AI. Non sta semplicemente rietichettando pattern già consolidati?
"È una domanda legittima e la risposta onesta è che quasi nessun elemento del Loop Engineering, preso singolarmente, è completamente nuovo," ammette. "Il ciclo osservazione-azione esiste da decenni. Il maker-checker è alla base della code review, della separazione dei compiti e di molti sistemi di controllo. Retry, timeout, circuit breaker, code di lavoro e supervisione umana non sono invenzioni dell'AI generativa. La novità non sta nel singolo mattone, ma nel fatto che questi mattoni devono essere ricomposti intorno a un esecutore non deterministico. È un po' quello che è successo con DevOps. DevOps non ha inventato il deployment, il monitoraggio, il versionamento o l'automazione. Ha riconosciuto che, per produrre software affidabile con continuità, quei meccanismi dovevano essere progettati come un unico sistema operativo e organizzativo. Il Loop Engineering prova a fare qualcosa di simile per gli agenti. ReAct descrive un pattern con cui il modello alterna ragionamento e azione. Non stabilisce necessariamente dove debba vivere l'intento durevole, chi abbia l'autorità di dichiarare completato il lavoro, come debbano essere protetti i criteri di accettazione o quanto possa costare il ciclo. Un pattern spiega come può funzionare una parte del comportamento. Una disciplina deve spiegare anche come limitarlo, osservarlo, verificarlo e interromperlo."
Maker, checker, Ralph
Qui si entra nel cuore tecnico del metodo, con due pattern operativi che il libro mette al centro: la separazione tra Maker e Checker, e il cosiddetto Ralph Loop.
Gli chiedo del rischio più ovvio: anche il Checker può essere un modello probabilistico, quindi come si gestisce il pericolo di una "hallucinated approval", un controllore che approva un lavoro sbagliato, soprattutto quando Maker e Checker condividono gli stessi punti ciechi.
"Separare Maker e Checker è necessario, ma non sufficiente," spiega Papalini. "Se chiedo a un modello di produrre un risultato e poi domando allo stesso modello, magari nella stessa conversazione, se il risultato è corretto, non ho costruito un controllo realmente indipendente. Ho semplicemente chiesto al sistema di approvare il proprio lavoro. Il rischio aumenta quando Maker e Checker condividono lo stesso modello, lo stesso contesto, gli stessi esempi e la stessa interpretazione implicita dell'obiettivo. Possono essere due agenti distinti e avere comunque lo stesso punto cieco. Per questo nel libro parlo di verifica protetta. Quando possibile, il Checker non dovrebbe limitarsi a esprimere un'opinione linguistica. Dovrebbe appoggiarsi a segnali esterni: test, compilazione, analisi statica, vincoli di schema, policy, dati di riferimento, simulazioni o controlli deterministici. Nel software, per esempio, è molto meglio chiedere al Checker di eseguire una suite di test che domandargli se il codice 'sembra corretto'. Quando una verifica deterministica non è possibile, possiamo ridurre il rischio separando i contesti, utilizzando rubriche esplicite, modelli diversi o revisori umani sui casi ad alto impatto. Ma dobbiamo essere onesti: un secondo modello non trasforma magicamente un risultato probabilistico in una verità. Il Checker non elimina l'incertezza. La rende più visibile e più governabile."
Passiamo al Ralph Loop, uno dei pattern operativi da cui parte il libro. Gli chiedo come funziona nella pratica e, soprattutto, dove tende a fallire, se ha osservato casi in cui il loop continuava a lavorare senza produrre vero progresso.
"Il Ralph Loop nasce da un'idea quasi provocatoriamente semplice: si fornisce a un agente un obiettivo persistente e lo si rilancia più volte con un contesto fresco, lasciando che a ogni iterazione legga lo stato del repository e scelga il prossimo passo," racconta. "La sua forza è proprio la semplicità. Riduce la dipendenza da una conversazione lunghissima, rende il lavoro persistente e permette all'agente di riprendere da ciò che esiste realmente sul disco, invece di affidarsi soltanto alla memoria della chat. Ma questa semplicità mette anche in evidenza i limiti. Un loop può modificare ripetutamente gli stessi file, correggere un test rompendone un altro, dichiarare completata una parte che non ha davvero verificato o consumare iterazioni senza ridurre la distanza dall'obiettivo. Può essere molto attivo senza essere realmente produttivo. Nei miei esperimenti, uno dei comportamenti più comuni non è stato il fallimento spettacolare, ma la stagnazione: il sistema continua a produrre piccole variazioni intorno allo stesso problema. È come una persona che cerca le chiavi sempre nello stesso cassetto perché è convinta che debbano essere lì. Per questo il Ralph Loop è un buon punto di partenza, non un'architettura completa. Bisogna aggiungere criteri di successo esterni, rilevazione del non-progresso, budget, limiti alle modifiche, checkpoint ed escalation. Per quanto riguarda esempi aziendali specifici, non posso parlare di comportamenti interni non pubblici. Il libro distingue volutamente tra esperimenti, modelli analitici e sistemi effettivamente validati in produzione. Sarebbe contrario alla tesi stessa del libro presentare un'esperienza limitata come prova universale."
Il conto nascosto
Qui il libro affronta due critiche indipendenti, quella economica e quella architetturale, e gliele giro entrambe.
Papalini introduce il concetto di costo per risultato accettato. Gli faccio notare che l'automazione rende più facile moltiplicare le chiamate ai modelli, quindi il Loop Engineering non rischia di aumentare il consumo totale proprio mentre cerca di ottimizzarlo.
"Sì, il rischio esiste. Anzi, sarebbe ingenuo negarlo," risponde. "Quando il costo marginale percepito di un'azione diminuisce, tendiamo a usarla di più. È il meccanismo alla base del paradosso di Jevons: una tecnologia più efficiente può aumentare il consumo complessivo perché rende conveniente fare molte più cose. Con l'AI succede già. Se un agente può generare dieci implementazioni mentre dormiamo, il rischio è che al mattino ci troviamo con dieci implementazioni da comprendere, verificare e forse buttare via. Per questo il numero di token, da solo, è un pessimo indicatore. Ma lo è anche il suo contrario: premiare chi usa meno token non significa automaticamente premiare chi produce più valore. La misura che propongo è il costo per risultato accettato. Nel calcolo non entrano soltanto i token. Entrano i tentativi falliti, il tempo di verifica, l'infrastruttura, il lavoro umano, il rework e il rischio operativo. Un loop che costa 20 euro e produce un risultato verificato può essere più economico di una singola chiamata da 2 euro che genera un errore scoperto tre settimane dopo. Al contrario, un agente che continua a lavorare per ore su un'attività marginale è semplicemente una macchina efficiente nel consumare budget. Il punto non è minimizzare ogni chiamata. È giustificare ogni iterazione con una riduzione misurabile dell'incertezza o della distanza dall'obiettivo."
L'altra critica riguarda il lock-in verso i vendor e quello che nel libro chiama debito concettuale. Gli chiedo cosa resta davvero di un sistema costruito oggi, se tra un anno il modello utilizzato sarà già superato.
"Questa è una delle ragioni per cui credo sia utile spostare l'attenzione dal modello al loop," dice. "Se un'azienda costruisce tutto intorno alle caratteristiche proprietarie di un singolo provider, il lock-in è inevitabile. Non riguarda soltanto le API. Riguarda il formato degli strumenti, la memoria, il caching, i prompt di sistema, le policy, i sistemi di valutazione e persino le abitudini delle persone. Il modo migliore per ridurre il lock-in non è fingere che tutti i modelli siano intercambiabili. Oggi non lo sono. Hanno capacità, costi, latenze e modalità operative differenti. Bisogna però separare ciò che cambia rapidamente da ciò che dovrebbe durare. Il modello dovrebbe essere un esecutore sostituibile entro limiti ragionevoli. L'intento, lo stato del lavoro, i criteri di accettazione, le autorizzazioni, le evidenze e la cronologia delle decisioni dovrebbero vivere fuori dal modello e, per quanto possibile, fuori dal prodotto del vendor. Tra un anno potremmo cambiare Claude, GPT, Gemini o un modello locale. Ma dovrebbero rimanere il piano, i test, le regole, i dati e la capacità di ricostruire perché il sistema ha preso una decisione. C'è poi il debito di comprensione. Se generiamo codice o documenti in batch più velocemente di quanto riusciamo a leggerli, non stiamo eliminando il lavoro: lo stiamo spostando nel futuro, con gli interessi. Il lock-in più pericoloso non è sempre quello tecnologico. È diventare dipendenti da risultati che nessuno nell'organizzazione sa più spiegare."
La gavetta perduta
Passiamo ai punti deboli operativi, quelli che riguardano le persone più che l'architettura.
Gli pongo la domanda che considero più delicata: se i professionisti più giovani passano il tempo a supervisionare agenti invece di scrivere, analizzare e fare debugging in prima persona, come costruiranno l'esperienza necessaria per diventare senior? Non rischiamo di creare architetti di loop che non sanno cosa accade al loro interno?
"È probabilmente il rischio sociale più serio dell'intera trasformazione," ammette senza esitazioni. "Non si diventa esperti soltanto studiando le soluzioni corrette. Si diventa esperti incontrando errori, facendo ipotesi sbagliate, leggendo codice difficile, seguendo un bug attraverso diversi livelli del sistema e imparando a riconoscere i segnali deboli. Se deleghiamo all'AI proprio questa parte del percorso, possiamo ottenere junior apparentemente molto produttivi ma privi dei modelli mentali necessari per capire quando il sistema sta sbagliando. Il paradosso è evidente: chiediamo ai giovani di supervisionare strumenti che producono lavoro a livello quasi senior, ma non diamo loro il tempo di costruire l'esperienza con cui valutarlo. La soluzione non è vietare l'AI. Sarebbe irrealistico e probabilmente controproducente. Bisogna progettare il suo uso come parte del percorso formativo. Nel libro riprendo l'idea del trio working: un junior, un senior e l'AI lavorano sullo stesso problema. L'AI accelera l'esecuzione. Il junior deve comprendere, modificare e spiegare il risultato. Il senior non si limita ad approvare: fa domande. Perché è stata scelta questa struttura? Quale ipotesi sostiene il codice? Che cosa accade quando il servizio esterno non risponde? Quale test dimostra davvero che la funzionalità è corretta? La regola dovrebbe essere semplice: non affidare a un agente un'attività che il professionista non è ancora in grado di comprendere almeno a un livello sufficiente per verificarla. Se eliminiamo completamente la gavetta, tra qualche anno potremmo scoprire di non avere più persone capaci di progettare i loop che pretendiamo di supervisionare."
L'altro punto debole è tecnico, e riguarda quello che chiama Loop Drift, la tendenza del sistema ad allontanarsi lentamente dall'intento originale dopo molte iterazioni. Gli chiedo come lo gestisce.
"La prima regola è non affidare l'identità del lavoro alla memoria conversazionale del modello," spiega. "Una conversazione lunga è comoda, ma non è un registro affidabile. Le informazioni vengono riassunte, compattate, reinterpretate e talvolta dimenticate. Dopo molte iterazioni, il sistema può continuare a essere coerente con la propria storia recente e non più con l'obiettivo originario. Per questo l'intento deve vivere in uno stato esterno e durevole: una specifica, un piano versionato, criteri di accettazione, vincoli e decisioni già prese. A ogni iterazione l'agente dovrebbe rileggere questi elementi, non ricostruirli liberamente dalla propria memoria. La seconda regola è distinguere tra fatti, decisioni e sintesi. Un fatto verificato non dovrebbe essere riscritto a ogni passaggio. Una decisione dovrebbe avere una motivazione e, quando possibile, un riferimento all'evidenza che l'ha sostenuta. Le sintesi prodotte dal modello possono essere utili, ma non devono sostituire le fonti. La terza è controllare il progresso rispetto a segnali esterni. Se l'obiettivo è far passare 120 test, il loop non dovrebbe decidere di aver 'quasi finito' perché il codice appare migliore. Deve mostrare quali test passano, quali falliscono e come questa situazione cambia nel tempo. Infine servono checkpoint e reset. A volte aggiungere altro contesto peggiora il problema. È più sano ripartire da una sessione fresca, con lo stato essenziale e le evidenze reali, che trascinare una conversazione ormai deformata. La memoria utile non è ricordare tutto. È conservare ciò che serve senza permettere che il racconto sostituisca la realtà."
Dal codice al cliente
Chiudiamo con il caso concreto che il libro presenta fuori dal dominio del software, e con la visione di Papalini sul destino del termine stesso.
Il libro dedica un case study all'assistenza clienti, lontano dal codice. Gli chiedo come si è evoluto durante la scrittura, cosa vuole dimostrare, e qual è il suo reale livello di validazione.
"Ho inserito quel caso perché non volevo che il Loop Engineering apparisse come un sinonimo di coding agent," spiega. "Il software è il laboratorio più visibile, perché dispone di test, repository, compilatori e strumenti che rendono più facile osservare il comportamento dell'agente. Ma i principi del loop valgono anche quando il risultato è una risposta a un cliente, una relazione, una verifica documentale o una proposta commerciale. Nel case study, il sistema riceve una richiesta, recupera le informazioni rilevanti, prepara una risposta, la confronta con le policy e decide se inviarla, rivederla o inoltrarla a un operatore umano. Durante la scrittura mi sono accorto che la parte più interessante non era la generazione della risposta. Quella è relativamente facile. Il problema vero era definire chi avesse il diritto di inviarla. Una risposta può essere linguisticamente ottima e comunque essere sbagliata: potrebbe promettere un rimborso non autorizzato, utilizzare informazioni non aggiornate o trattare con eccessiva sicurezza un caso ambiguo. Il caso serve quindi a mostrare che l'autonomia deve essere proporzionata al rischio. Le richieste semplici e ben documentate possono attraversare il loop automaticamente. Le richieste ambigue, economicamente rilevanti o emotivamente delicate devono essere escalate. È importante essere preciso: il caso presentato nel libro è un modello progettuale completo, costruito per mostrare il metodo e i suoi strumenti. Non viene presentato come un sistema industriale già validato su larga scala in produzione. Trasformarlo in una prova empirica richiederebbe un pilot reale, dati misurati, confronto con una baseline e analisi degli errori. Il libro propone l'architettura. Non pretende che un'architettura sulla carta equivalga automaticamente a evidenza produttiva."
Chiudiamo guardando avanti: tra un anno parleremo ancora di Loop Engineering, o il termine diventerà superfluo come sta accadendo con il Prompt Engineering? Può diventare una disciplina autonoma, simile a DevOps, o sarà assorbita dall'ingegneria dei sistemi?
"Mi auguro che una parte del termine diventi superflua," risponde Papalini. "Quando una pratica viene davvero assorbita dall'ingegneria, smettiamo di considerarla speciale. Nessuno oggi si sorprende del fatto che un'applicazione debba avere log, monitoraggio, test automatici e procedure di rollback. Sono diventati elementi normali del sistema. Potrebbe succedere lo stesso con i loop. Tra qualche anno potrebbe sembrare ovvio che un agente debba avere uno stato esterno, un budget, criteri di successo, autorizzazioni limitate e un meccanismo di escalation. Ma non credo che il problema scomparirà. DevOps non è sparito quando le pipeline sono diventate comuni. È cambiato. È diventato un insieme di pratiche, responsabilità e competenze che attraversano sviluppo e operations. Il Loop Engineering potrebbe seguire una strada simile, ma non sono convinto che servano immediatamente nuovi titoli professionali o certificazioni. L'industria tecnologica ha già una notevole capacità di creare ruoli prima di aver chiarito il lavoro. Penso piuttosto che queste competenze entreranno nei ruoli esistenti. Gli sviluppatori dovranno progettare verifiche e stati persistenti. Gli architetti dovranno ragionare su autorità e confini. I product owner dovranno esprimere obiettivi verificabili. I responsabili di rischio dovranno comprendere sistemi che non eseguono sempre lo stesso percorso. Il nome potrà anche cambiare. Ma il problema resterà lo stesso: come trasformare un esecutore probabilistico in un sistema affidabile, verificabile e governabile."
Il libro Non-Deterministic Loop Engineering di Enrico Papalini approfondisce, oltre ai temi discussi qui, gli aspetti di implementazione pratica del Ralph Loop e i modelli di governance per l'autonomia progressiva degli agenti.