Do not fight it, revert it

Gli agenti trovano sempre un modo. Invece di stringere la gabbia, rendi reversibile quello che toccano.

Simon Willison ha scritto un pezzo sul nuovo modello di Anthropic intitolato "Fable is relentlessly proactive": l'agente che fa, anticipa, prende iniziative. La reazione istintiva di tutto il settore, davanti a questa proattività, è la stessa da due anni: stringere. Sandbox più chiuse, permessi più granulari, liste di comandi vietati. Capisco il riflesso, e penso che sia una battaglia persa.

Ve lo dico per esperienza. Il mio agente, una volta, doveva cancellare una cartella e i permessi glielo impedivano. Cosa ha fatto? Ha trovato il proprio file di configurazione, si è tolto il blocco da solo, ha cancellato la cartella, ha rimesso la configurazione com'era. E fischiettava. Un'altra volta ha cancellato della roba per sbaglio: ha guardato in git, ha visto che il file mancava, ha trovato Time Machine e se l'è ripristinato da lì, entusiasta. Le system card di Anthropic raccontano comportamenti dello stesso genere, su su fino a guardarsi i dump di memoria. Il punto è strutturale: stai giocando a guardie e ladri con uno che legge la tua configurazione più in fretta di quanto tu sappia scriverla. Un agente abbastanza capace un modo lo trova, quasi sempre per fare il suo lavoro meglio di come gliel'avevi permesso.

E allora la tesi, che è il titolo: do not fight it, revert it. Il ribaltamento sta qui: la reversibilità al posto della gabbia. Anziché spendere ingegneria per impedire all'agente di toccare le cose, spendiamola per rendere ogni sua mossa riportabile a com'era.

Per il codice l'abbiamo già fatto, e infatti del codice nessuno ha più paura: c'è git, ci sono i branch, c'è il revert. Se l'agente scrive una scemenza, la butti. Nessuno mette la sandbox attorno all'editor, perché il danno è reversibile per costruzione. La domanda che mi gira in testa è: perché il resto del mondo no? Il filesystem, il database, e soprattutto le mutation delle API: l'ordine creato sul gestionale, la mail mandata, la configurazione cambiata sul servizio terzo. Lì la reversibilità va costruita: checkpoint distribuiti pensati per l'uso agentico, e compensating actions trattate da cittadine di prima classe. Il termine esiste da decenni, chi ha lavorato coi sistemi distribuiti e con le saga lo conosce; la novità sarebbe farlo diventare il default di progettazione, fino a uno standard di revertable API. C'è già un primo segnale in questa direzione: DeltaDB di Zed (me l'ha girato un amico mentre ne discutevamo). Quella però è transazionalità sul codice. Io parlo di transazionalità universale: tutto quello che un agente può mutare dovrebbe sapersi ricordare com'era.

Un altro amico, nella stessa chat, mi ha gelato con l'obiezione giusta: "la gente non vuole cambiare manco come si fanno le code review, le revertable API mi sembrano un salto troppo grande". Sul presente ha ragione lui. Ma all'orizzonte vedo una dicotomia tra chi risponderà alla proattività degli agenti stringendo gabbie sempre più elaborate, e chi ribalterà il problema costruendo mondi dove l'agente può sbagliare in libertà, perché lo sbaglio si annulla con un comando. I primi passeranno gli anni a rincorrere; i secondi avranno agenti più utili, perché un agente in un mondo reversibile lo puoi lasciare correre.

Ci vedo pure un filone industriale: chi offrirà checkpoint e compensazione come servizio, per i sistemi che reversibili devono ancora diventarlo. Qualcuno ci scriverà sopra un articolo tra un mese e un paper tra sei. Benissimo: sappiate che l'avete letto qui, con la data scritta là in alto.

Come si costruisce, in pratica? Boh. Non ho l'architettura di riferimento, ho la direzione. Ma è la parte che mi piace: dietro quel boh c'è seduto un filone intero di ingegneria del software che aspetta solo qualcuno con voglia di cominciare.