Il vero technical debt dell'AI è dimenticare gli errori
Il debito più caro dei sistemi AI non è il codice: è dimenticare gli errori. Tre casi datati, con capitale, interessi e come li estinguo.
In breve. Il debito tecnico dei sistemi AI non sta nel codice che invecchia: sta nelle lezioni che non vengono registrate. Ogni errore dimenticato è capitale preso in prestito, e gli interessi si pagano quando l'errore torna: ridiagnosi, doppioni, riscritture. Tre casi datati dai miei sistemi, con capitale, interessi e quietanze: due run che non sapevano l'uno dell'altro, una storia cancellata con lo squash, e cinque no che solo il registro ha ricordato.
Il debito che non sta nel codice
Ho un articolo intero su quanto costa davvero far girare agenti AI: token, tentativi ripetuti, test a pagamento. Quel debito si misura in euro e si vede in fattura. Ma da quando i miei sistemi girano da soli, quello che mi costa di più è un altro debito: le lezioni che il sistema ha pagato e poi ha dimenticato. Non compare in nessuna dashboard.
La contabilità è semplice. Capitale: un errore che accade e non lascia traccia durevole — niente regola, niente test, niente receipt. Interessi: ogni volta che lo stesso errore torna e ripago la diagnosi da zero, più le volte che costruisco una cura sopra un passato che non ricordo e la cura si rompe. Come ogni debito, si può tenere sotto controllo solo se è scritto da qualche parte: un debito che nessuno ha registrato non si estingue, si accumula.
Due run, stesso backlog, zero memoria
L'11 ottobre 2026, a quindici minuti di distanza, due merge mettono online due adattamenti inglesi dello stesso articolo: la PR #113 della factory alle 09:23 e la PR #104, separata a mano da una sessione owner, alle 09:38. Stesso backlog d'origine, slug diversi, stesso translationOf. Nessuno dei due giri sapeva dell'altro: il secondo ha pagato per intero un lavoro già fatto e già mergiato, e il risultato è andato online doppio. Due URL diversi, entrambi 200, con l'hreflang della pagina italiana che ne puntava uno solo.
Gli interessi, in questo caso, sono misurabili in lavoro: diagnosi del doppione, PR #114 di rimozione con redirect permanente 308 dal vecchio al nuovo URL, e un check che da allora fallisce se due articoli condividono lo stesso translationOf. Il capitale era una riga mai scritta: "questa voce è già in lavorazione altrove". Nessuno l'aveva dimenticata per negligenza: non esisteva un posto dove leggerla prima di partire.
La storia cancellata con lo squash
Il 27 settembre 2026 la stessa lezione era già stata pagata in un'altra forma. Uno squash aveva appiattito la storia di un branch e il range da adottare non era più attraversabile in modo governato: senza i merge commit, nessuno poteva più dire cosa era atterrato, in che ordine, e da dove. Incidente #307/#309, registrato nel playbook della factory: cancellare la storia è un modo elegante di dimenticare gli errori, e costa ogni volta che devi ricostruirla.
Da quel giorno la regola è mainline merge-only: le PR atterrano solo come merge commit, mai squash né rebase, e un controllo dedicato rifiuta i range che non tengono la regola prima che chiunque fonda o aggiorni. La memoria, qui, non è un documento: è una proprietà della storia git che nessun giro futuro può aggirare per sbaglio. Il passato resta interrogabile perché è strutturalmente impossibile cancellarlo con un click.
Cinque no che solo il registro ha ricordato
Il terzo caso è questo articolo. Il 10 ottobre 2026 un giro della factory lo scrive, lo verifica verde e prova a pubblicarlo: la sandbox nega le scritture git, niente PR, niente merge. Cinque volte, una dopo l'altra: stessa cura verde, stesso no, ognuno registrato nel diario come blocco publish_denied. Senza il registro, sarebbe stato lavoro perso: il giro dopo avrebbe riscritto lo stesso pezzo da zero, o nessuno si sarebbe accorto che mancava.
Invece ogni tentativo è rimasto scritto con la sua evidenza, e l'11 ottobre un retry esplicito ha rimesso la voce in lavorazione in un ambiente che poteva pubblicare. Quello che state leggendo è la quietanza: il debito non si è accumulato perché il capitale, "questo articolo esiste, è verde, aspetta solo di uscire", non è mai stato dimenticato. Dimenticare sarebbe costato una riscrittura; ricordare è costato una riga di diario per tentativo.
Estinguere: rendere l'oblio impossibile
I tre casi dicono la stessa cosa in tre valute diverse: non "ricordati di più", ma "rendi impossibile dimenticare". Il check di unicità, la mainline merge-only, il diario append-only sono la stessa mossa: spostare la lezione dal ricordo del singolo a un posto dove la macchina la rilegge da sola. Il meccanismo in dettaglio — ogni fallimento convertito in regola durevole con il suo test — l'ho descritto nei marginal gains per le macchine: questo articolo è la contabilità, quello è la cassa.
E c'è un corollario che applico sempre: chi dichiara estinto il debito non è chi l'ha pagato. Come spiego nella guida su come verificare il lavoro di un agente AI, il verdetto deve venire da mani indipendenti dalla cura — altrimenti è il debitore a firmarsi la quietanza.
Fatti e limiti
FACT. L'11 ottobre 2026 la PR #113 (merge 09:23) e la PR #104 (merge 09:38) mettono online due adattamenti EN dello stesso pillar con lo stesso translationOf; prima della PR #114 entrambi gli URL rispondono 200.
FACT. La PR #114 dell'11 ottobre 2026 rimuove il doppione, aggiunge un redirect permanente 308 e un check che fallisce se due articoli condividono lo stesso translationOf.
FACT. Dal 27 settembre 2026 la regola mainline merge-only richiede merge commit su main dopo l'incidente #307/#309; un controllo dedicato rifiuta i range non governati prima di fondere o aggiornare.
FACT. Il 10 ottobre 2026 questo articolo subisce cinque blocchi publish_denied nel seat run-c5fdbc96 con cura verde; l'11 ottobre un retry esplicito lo rimette in lavorazione.
INTERPRETATION. Tratto le lezioni non registrate come debito perché si comportano come debito: capitale silenzioso, interessi ricorrenti, estinzione solo per iscritto.
INTERPRETATION. Non ho misurato il costo in euro di questi tre casi; li riporto come episodi con provenance, non come statistica.
Limiti: tre episodi dai miei sistemi, non un'industria. Le cifre (orari dei merge, conteggio dei blocchi) sono rilette nelle fonti approvate al momento della scrittura. Dove le fonti tacciono, taccio anch'io.
Domande frequenti
Il technical debt dell'AI non sono i costi dei token?
Quello è un debito vero ma diverso: lo tratto nell'articolo sui costi nascosti degli agenti AI. Si misura in euro e si vede in fattura. L'oblio invece si misura in errori che tornano: non ha una dashboard, ha i sintomi. Ridiagnosi, doppioni, riscritture.
Non basta scrivere un postmortem dopo ogni errore?
Un postmortem che nessuno rilegge è capitale dato per estinto ma mai versato. La differenza la fa la riesecuzione meccanica: la lezione deve stare in un check, in una regola del registro o in una proprietà della storia, qualcosa che la macchina rilegge senza bisogno di ricordarsi.
Come faccio a sapere cosa il mio sistema ha già dimenticato?
Cerca i pagamenti, non i ricordi: diagnostica due volte lo stesso sintomo, cure che si contraddicono, fix che rompono fix precedenti. Ogni interesse pagato due volte è la spia di un capitale mai registrato. Parti da lì, e registra prima di curare.