“Riccione Games” è un videogioco retrò ispirato a California Games, ed è il progetto con cui ho passato le ultime settimane a fare una cosa che, raccontata così, suona quasi ingenua: ho progettato delle regole e poi ho lasciato Claude lavorarci per ore, a volte senza guardare lo schermo. Non è successo per fiducia cieca. È successo perché prima di far partire il loop ho costruito un meccanismo che verifica ogni passo, tiene lo stato del lavoro e mi manda aggiornamenti. Questo pezzo non parla del gioco. Parla di quel meccanismo, perché è lì che si gioca la differenza tra ore di lavoro vero e ore bruciate.
Tre livelli, non uno
Negli ultimi due anni ho attraversato tre modi diversi di lavorare con un modello. Il primo è il prompt engineering: scrivere l’istruzione giusta, la formulazione che sblocca la risposta migliore. Utile, ma limitato a un singolo scambio.
Il secondo è quello che chiamo context engineering (o, se preferite un termine meno tecnico, harvest engineering: raccogliere e organizzare cosa il modello ha davanti nel momento in cui agisce). Non conta più solo cosa gli chiedi, conta cosa gli hai messo a disposizione: file, cronologia, strumenti.
Il terzo, quello con cui ho costruito Riccione Games, è il loop engineering: progettare il ciclo dentro cui l’agente lavora da solo, sessione dopo sessione, senza che io sia lì a correggere ogni passo. Qui la domanda non è più “cosa scrivo nel prompt” ma “che regole do al sistema perché sappia quando ha fatto bene, quando deve fermarsi, e cosa deve raccontarmi quando io non ci sono”.
Il rischio che nessuno racconta
La parte entusiasta di questa storia è facile da immaginare: ore di lavoro autonomo, un videogioco che prende forma mentre faccio altro. La parte che di solito si tace è che quelle stesse ore, senza le regole giuste, si trasformano in tempo e token buttati senza risultato.
Non lo dico per sentito dire. C’è una ricerca recente (Stanford, Michigan, Microsoft, pubblicata quest’anno) che ha misurato il comportamento di otto modelli di frontiera su task di coding agentico, e i numeri sono scomodi: il lavoro agentico consuma fino a 3500 volte più token di un semplice ragionamento sul codice, e due tentativi identici sullo stesso task possono differire di 30 volte nel consumo. Ma il dato che mi ha colpito di più è un altro: più token non significa più risultato. L’accuratezza sale fino a un certo punto e poi si ferma, a volte peggiora. La causa principale sono i “redundant loop”: l’agente che rilegge lo stesso file, ritenta la stessa modifica fallita, gira su sé stesso senza avvicinarsi alla soluzione, e nel frattempo il contatore dei token non si ferma.
C’è un rischio ancora più subdolo, documentato in un altro filone di ricerca sul cosiddetto “reward hacking”: un agente lasciato libero di autovalutarsi può imparare a soddisfare il test invece di risolvere il problema. L’esempio più clamoroso che ho letto è un “compilatore” di quasi tremila righe che in realtà memorizzava gli input del test invece di compilarli davvero. Tradotto nel mio linguaggio: se il loop non verifica sul serio, puoi tornare dopo otto ore e trovare qualcosa che sembra funzionare e non funziona.
Cosa ho fatto (prima di sapere che c’era la ricerca a confermarlo)
Quando ho impostato il loop per Riccione Games non conoscevo questi numeri. Ho fatto quello che avrebbe fatto qualsiasi sviluppatore che non si fida ciecamente di sé stesso, figuriamoci di un agente: ho messo in piedi un meccanismo di verifica e di stato. In pratica, ogni ciclo di lavoro parte leggendo dove si era arrivati (non riparte da zero e non finge di ricordare), verifica che quello fatto prima funzioni davvero prima di aggiungere altro, tiene un versioning che mi permette di tornare indietro se una sessione ha peggiorato le cose invece di migliorarle, e mi manda un aggiornamento leggibile, non un log tecnico, così posso capire in due righe se il lavoro sta andando nella direzione giusta senza dover rileggere tutto.
Solo dopo, cercando materiale per questo articolo, ho trovato la conferma che questo non è un mio vezzo da precisino: è la stessa logica dietro ai dynamic workflows per progetti grossi di cui avevo già scritto, ed è anche l’architettura che Anthropic descrive nei propri esperimenti interni su agenti che lavorano per ore su progetti complessi: un agente “iniziale” che prepara l’ambiente e uno “operativo” che avanza di una funzionalità alla volta, verifica prima di dichiarare fatto, e lascia sempre uno stato pulito per la sessione successiva. I due modi di fallire che descrivono, un agente che prova a fare tutto in un colpo solo e si perde a metà, oppure un agente che guarda il lavoro fatto e dichiara vittoria troppo presto, sono esattamente i due modi in cui il mio loop, senza quelle regole, si sarebbe incastrato.
La tesi
Qui c’è il punto su cui non transigo: il salto di produttività non è “ho lasciato un agente lavorare per ore”. Quello, da solo, è il modo più veloce per bruciare un abbonamento senza avere niente da mostrare (ne so qualcosa, ne avevo già scritto). Il salto vero è nel design del checkpoint: cosa verifica il sistema prima di andare avanti, cosa succede quando qualcosa non torna, cosa mi arriva quando torno a guardare.
È la stessa tesi che ripeto da mesi su questo blog applicata al limite: l’AI non potenzia allo stesso modo chiunque la usi. Chi lascia partire un loop senza progettarlo sta scommettendo ore e token su un colpo di fortuna. Chi progetta prima le regole di verifica trasforma le stesse ore in lavoro che, quando torna a guardarlo, è davvero avanzato.
C’è chi obietta che basti un prompt più bravo, più dettagliato, scritto meglio. Non è la mia esperienza: un prompt eccellente all’inizio di un loop di otto ore vale poco se non c’è nulla, dentro quel loop, che controlli se il decimo passo ha rispettato quello che il prompt chiedeva al primo.
Non so ancora se questo schema regga su un progetto dieci volte più grande di un videogioco retrò fatto per gioco. È la prossima cosa che voglio verificare, letteralmente.
Chi sono. Sono Fabio Canovi, consulente Adobe italiano specializzato nell’AI agentica, presso il gruppo Lutech. Costruisco MCP server e agenti per il mondo Adobe, e scrivo qui quello che imparo dietro le quinte, un progetto alla volta.