Decoerenza: il debito tecnico che cresce a ogni modifica, e che gli agenti rischiano di accelerare

Chi ha fatto rifare l’impianto elettrico in un appartamento di un condominio degli anni Sessanta conosce il momento in cui l’elettricista apre una scatola di derivazione e resta zitto. Dentro ci sono tre epoche: un paio di fili rivestiti di tela, di quando il palazzo era nuovo; i fili rigidi di un lavoro degli anni Ottanta; i cavi colorati secondo le norme di oggi, aggiunti da chi ha rifatto la cucina. Ogni giunzione, presa da sola, è stata fatta bene: chi l’ha fatta aveva davanti un guasto, e il guasto l’ha risolto. Il problema è la domanda a cui nessuna di quelle giunzioni sa più rispondere: se adesso mettiamo un piano a induzione, la linea regge?

Per saperlo bisogna seguire ogni filo fino in fondo, capire che cosa aveva in mente ogni elettricista passato di lì, e immaginare come si comportano insieme cose che nessuno ha progettato per stare insieme. Con un impianto tutto vecchio o tutto nuovo il conto si fa in mezz’ora, perché ci sono le tabelle. Per un impianto misto le tabelle non esistono.

Kristen Maevyn, che scrive di ingegneria del software su maevyn.codes, ha dato un nome a questa condizione in un saggio lungo uscito il 14 ottobre, The Decoherence Trap, «la trappola della decoerenza». La definizione è questa: la decoerenza è l’accumulo, dentro un sistema, di modelli validi ciascuno nel suo angolo ma incompatibili o ridondanti fra loro, fino al punto in cui il costo di una modifica non lo decide più il lavoro da fare, ma il lavoro di tradurre da un modello all’altro e di evitare effetti collaterali che nessuno aveva previsto. Nel codice, per fare un esempio nostro, i «modelli» sono i modi di fare la stessa cosa: tre librerie per le date, due maniere di gestire gli errori, quattro stili di chiamata asincrona nello stesso programma.

La parola viene dalla fisica quantistica, dove indica tutt’altro; il saggio non ci costruisce sopra niente e la usa nel senso comune di coerenza perduta. La tesi, invece, è forte. Fra le forme di debito tecnico la decoerenza è la peggiore; cresce tanto più in fretta quanto più un sistema è già decoerente; e l’uso massiccio dell’intelligenza artificiale per scrivere codice la sta producendo a un ritmo che non si regge. Il saggio è pubblicato con licenza CC BY 4.0 e merita di essere letto per intero. Qui proviamo a seguirne l’argomento, a metterlo accanto agli studi che cita (li abbiamo ricontrollati sulle fonti) e a dire dove convince e dove no.

Tre debiti, e il terzo è il peggiore

L’esempio di partenza del saggio è un palazzo per uffici con tubature destinate a invecchiare. Che prima o poi vadano cambiate è il primo debito, il più ovvio: l’usura. Che al momento di cambiarle convenga passare a uno standard nuovo (perché le norme sono cambiate, perché quelle vecchie non si fabbricano più, perché le nuove si mantengono meglio) è il secondo: il debito dell’avanzamento tecnico, il prezzo di stare al passo. Il terzo debito nasce da come si fa il passaggio.

Le strade sono tre. Si chiude il palazzo e si rifà tutto in una volta: costoso, paralizzante, ma alla fine il lavoro è finito. Si chiude un piano alla volta: meno disagi, un po’ più di spesa per tenere in piedi il resto mentre si lavora. Oppure si cambia un tubo quando si rompe: nessuna chiusura, il costo spalmato negli anni, una piccola riparazione dopo l’altra. Ai più la terza sembra la scelta naturale, ed è comprensibile. È anche la strada che produce decoerenza.

Per spiegare perché, Maevyn rilegge la nave di Teseo. Il paradosso classico chiede se una nave a cui si sostituiscono tutte le assi, una per una, sia ancora la stessa nave. Ma le assi nuove sono di legno come le vecchie. La domanda interessante è un’altra: si potrebbe trasformare, pezzo per pezzo, un vascello da guerra a vela in un cacciatorpediniere d’acciaio, tenendolo in grado di navigare a ogni passaggio? Una strada ci sarebbe, risponde il saggio, ma servirebbero le menti migliori, molto ingegno e molta cura. E bisognerebbe soprattutto arrivare in fondo, perché una nave per metà vascello e per metà cacciatorpediniere difficilmente se la cava in una battaglia di oggi.

Torniamo ai tubi. Ogni rottura chiama l’idraulico, il muro si apre, la riparazione è fatta a mano per quel punto, il muro si richiude. Se va bene l’idraulico lascia appunti; se va male, anni dopo qualcuno riaprirà quel muro chiedendosi che cosa sia successo lì dentro. Moltiplicato per decenni, il risultato è un mosaico di tubi vecchi e nuovi più complicato di ciascuno dei due sistemi preso da solo. Ogni giunto è un piccolo oggetto unico, con forze e proprietà poco studiate, e per lavorarci serve qualcuno che conosca bene tutti e due i sistemi.

Finché nessuno chiede niente di nuovo, va tutto bene. Poi arriva la richiesta: un’ala nuova, che prende l’acqua passando per l’edificio vecchio, e con una pressione più alta. Con un impianto omogeneo, vecchio o nuovo che sia, la domanda «regge la pressione?» ha una risposta da manuale: per entrambi i sistemi esistono strumenti e procedure, e quei conti si fanno tutti i giorni. Con un miscuglio di cui nessuno conosce le proporzioni, ogni toppa può cambiare la risposta, anche quella all’altro capo dell’edificio, perché sono tutte collegate.

Qui il saggio aggiunge il passaggio che a nostro giudizio è il più acuto. Chi guarda da fuori non vede la profondità del problema: vede che un lavoro di solito rapido stavolta è lento, e mette fretta. Sotto pressione l’esperto non fa l’analisi completa più in fretta. La interrompe prima, e fa qualcosa che è abbastanza sicuro funzionerà: un raccordo approssimativo, un pezzo insolito, una valvola in più per scrupolo. Quella modifica è di qualità più bassa e lascia il sistema più fragile e più complicato. La prossima richiederà ancora più attenzione, e se la pressione resta la stessa verrà fatta ancora peggio. Il gradino successivo, scrive Maevyn, è cominciare una seconda transizione prima di aver finito la prima.

Un’idea vecchia, con un nome nuovo

Maevyn è la prima a dire che il fenomeno non è nuovo, e vale la pena di dargli qualche antenato. Nel 1975, in The Mythical Man-Month, Fred Brooks scriveva che l’integrità concettuale è la considerazione più importante nel progetto di un sistema: meglio un sistema che rinuncia a qualche funzione ma riflette un solo insieme di idee di progetto, che uno pieno di idee buone ma indipendenti e scoordinate. È quasi la definizione di decoerenza letta al rovescio. Negli stessi anni Meir Lehman, studiando come evolveva il sistema operativo OS/360 dell’IBM, formulava la sua legge della complessità crescente: un programma che continua a essere modificato diventa più complesso, a meno che non si lavori apposta per mantenerne o ridurne la complessità.

Quello che il saggio aggiunge è una distinzione e una previsione. La distinzione separa la decoerenza dall’usura e dall’obsolescenza: le giunzioni non si consumano e non passano di moda, semplicemente non si parlano. La previsione riguarda la velocità. La decoerenza non cresce con il tempo, cresce con le modifiche. Un sistema decoerente lasciato fermo per dieci anni, scrive Maevyn, al ritorno è decoerente esattamente come lo si era lasciato (potrà avere altri debiti, ma non questo). Cambia solo quando lo si cambia, e chi fa molte modifiche molto in fretta può perdere coerenza altrettanto in fretta.

È qui che entrano gli agenti di programmazione, che di modifiche ne fanno moltissime.

Il labirinto che nessuno vede

Il software, rispetto a un palazzo, ha uno svantaggio: è invisibile. L’idraulico può fotografare il groviglio e mostrarlo al proprietario (il saggio ne riporta uno, preso dal forum r/Plumbing di Reddit). Chi programma percorre ogni giorno i corridoi del proprio codice, ne conosce ogni svolta e sente subito quando il giro si allunga, con più vicoli ciechi e più botole. Ma chi il labirinto non lo percorre non lo vede, e quando arriva il momento di proporre una pulizia la proposta è difficile da vendere, anche a chi un tempo programmava: quel labirinto non è il suo.

Con due sistemi mescolati il problema è serio; con tre o più diventa combinatorio. Non basta sapere come si passa da A a B: bisogna pensare ad A verso C, a B verso C, ad A verso B verso C, a C verso B verso A. Le buone pratiche e le astrazioni aiutano a isolare le parti (l’equivalente, nei tubi, di una valvola che limita la pressione). Ma arriva un punto, sostiene Maevyn, in cui anche gli ingegneri migliori non attraversano più il labirinto in sicurezza: ci riescono l’80 o il 90% delle volte, e prima o poi sbagliano strada. È questa la trappola del titolo.

Persone che si stancano, labirinti che crescono: sembra il problema perfetto per sciami di agenti che lavorano giorno e notte. La risposta del saggio dipende da come cresce la complessità. Se cresce in proporzione alla dimensione del codice, aggiungere agenti e data center basta a tenere il passo. Se cresce in modo esponenziale, perché ogni modifica rende più probabile che anche la successiva aggiunga complessità, aggiungere capacità serve solo a spingersi un po’ più in là prima che il labirinto si mangi tutta la potenza di calcolo disponibile. Maevyn, per esperienza, crede alla seconda ipotesi.

Un conto giocattolo

Per vedere quanto conta la differenza basta un modello minimo, nostro e non del saggio. Supponiamo che ogni modifica renda la successiva un po’ più costosa, di una frazione fissa $\delta$. Allora il costo della modifica numero $n$ è

$$c_n = c_0\,(1+\delta)^n$$

dove $c_0$ è il costo di partenza. Con $\delta$ allo 0,1%, dopo mille modifiche la successiva costa 2,7 volte la prima: un fastidio. Con $\delta$ all’1% ne costa circa ventimila: un muro. Nel singolo commit la differenza fra i due casi è un arrotondamento; dopo mille commit è un abisso. Se invece $\delta$ è negativo, cioè se ogni modifica lascia il sistema un po’ più ordinato di come l’ha trovato, la stessa formula lavora a favore.

Il modello dice altre due cose. Il contatore è $n$, il numero di modifiche, non il calendario: è esattamente la tesi del saggio. E chi fa il triplo delle modifiche al mese, a parità di $\delta$, arriva al muro in un terzo del tempo. Gli agenti alzano $n$ per definizione. La domanda è che cosa fanno a $\delta$.

Una simulazione, e che cosa dimostra davvero

Il saggio fa qualcosa di simile, ma su un grafo. Il codice è fatto di nodi (i componenti), grandi quanto il componente, con un colore che indica il paradigma dominante e archi che sono le connessioni. Un attore, che rappresenta chi sviluppa, realizza una funzione percorrendo un tratto di grafo a caso e modificandolo. Il suo comportamento dipende da un fattore di coerenza. Basso, l’attore va veloce, decide d’istinto, sceglie la soluzione semplice senza guardare il contesto e aggiunge complessità. Alto, ci mette di più, ragiona, e ha più probabilità di fare una modifica pulita o perfino di togliere complessità.

Tre cose rallentano il cammino. Il numero di connessioni di ogni nodo, perché per sapere che effetto avrà la modifica bisogna capire almeno in parte i vicini. I passaggi da un colore all’altro, perché cambiare paradigma a metà lavoro costa: bisogna capirli tutti e due, e capire come si collegano. E la lunghezza del percorso, che si allunga con le connessioni e può crescere fino all’intero sistema, il punto in cui per toccare qualunque cosa bisogna capire tutto.

All’inizio l’attore frettoloso è molto più veloce di quello attento. Poi il grafo cambia, e con lui i percorsi. Mettendo in grafico le funzioni completate contro il fattore di coerenza viene fuori una curva che, scrive Maevyn, ogni ingegnere riconosce: lo sweet spot, il punto giusto. Lì il sistema è abbastanza coerente e si investe per tenerlo tale: pochi paradigmi dominanti, abbastanza margine per adattarsi, niente perfezionismo. Sopra, si lavora sodo perché ogni nodo nuovo entri nei paradigmi esistenti e si toglie complessità a ogni occasione: le funzioni escono più lente, ma il sistema resta navigabile. Sotto, la caduta è a picco; con un fattore di coerenza negativo il tempo per consegnare una funzione cresce senza un limite visibile.

Due esperimenti della simulazione vanno ricordati. Un sistema che parte molto coerente e viene gestito con una strategia di poca coerenza (fattore +0,2: un po’ di cura, ma con le scorciatoie) si degrada lentamente all’inizio, poi supera alcuni punti di flesso ed entra nella trappola. Un sistema che parte decoerente, ma su cui si lavora per ricomporlo, si sposta verso la coerenza e accelera.

I pesi della simulazione sono arbitrari, e Maevyn lo dice prima che glielo dicano: non sostiene che la simulazione dimostri che i sistemi reali evolvono così. La simulazione mostra che quella curva può emergere da regole semplici e decisioni locali, e che chi cambia un sistema oggi migliora o peggiora la capacità di chi lo cambierà domani. È una verità ovvia, ammette, ma le sue conseguenze si perdono facilmente quando la complessità non si vede come si vedono i tubi. La versione completa della simulazione è pubblica, e si può provare cambiando i parametri.

Il saggio descrive anche il ciclo in cui, a suo giudizio, vive la maggior parte delle aziende, ben sotto il punto giusto. La decoerenza cresce finché nessuna funzione si chiude più in tempi ragionevoli. Si lancia un grande sforzo di pulizia. Le funzioni ricominciano a uscire, lente ma accettabili. Lo sforzo non si completa, o si completa senza arrivare al punto giusto, l’attenzione si sposta altrove e il sistema ricomincia a perdere coerenza. Da capo. Le persone, insomma, non ne sono affatto immuni, e Maevyn non lo pretende. La sua domanda è più stretta: gli agenti sono migliori della media delle culture ingegneristiche? Molto migliori?

Che cosa dicono i dati

Finora, risponde il saggio, non ci sono prove che lo siano, e i primi studi puntano semmai dall’altra parte. Ne cita tre. Li abbiamo letti: le cifre che seguono vengono dalle fonti e non dal riassunto del saggio, che in qualche punto arrotonda.

Il primo è un working paper di Fiona Chen e James Stratton, di Harvard, nella versione del 4 agosto 2026. Usa i dati di Jellyfish, una piattaforma che misura l’attività dei team di sviluppo: circa 300 milioni di eventi di lavoro in 718 aziende, presi da GitHub, Jira e dai calendari. Il disegno è una differenza nelle differenze scaglionata, che sfrutta il momento diverso in cui le aziende hanno adottato assistenti e agenti di programmazione. Con gli agenti il codice prodotto cresce parecchio, il lavoro finito non in modo misurabile, e in mezzo c’è un tappo: la revisione.

Il paper aggiunge tre dettagli che contano. Chi sviluppa passa a scrivere codice fra il 30 e il 40% del proprio tempo, quindi accelerare solo quella parte sposta il collo di bottiglia altrove. Le aziende rispondono spostando persone sulla revisione: la quota di chi rivede codice cresce del 14%, da circa il 29 a circa il 33%. E il tappo resta anche dove si usa l’AI per rivedere: entro marzo 2026 quasi l’80% delle aziende l’aveva provata, ma solo il 23,3% dei commenti di revisione viene dall’AI. Va detto che è un working paper, non ancora passato da una rivista, e che i dati vengono da una piattaforma commerciale.

Il secondo studio è di Carnegie Mellon (Hao He, Courtney Miller, Shyam Agarwal, Christian Kästner e Bogdan Vasilescu) ed è stato presentato a MSR 2026, la conferenza di riferimento per chi studia i repository di codice. Confronta 806 progetti open source su GitHub che hanno adottato Cursor con progetti simili che non l’hanno fatto, e la velocità e la qualità prendono strade opposte.

La parte più interessante è la catena causale, stimata con un secondo modello: è la complessità accumulata a rallentare il lavoro dopo. Raddoppiare la complessità riduce le righe aggiunte del 64,5%; e anche tenendo conto di quanto cresce il codice, l’adozione di Cursor porta da sola a un codice più complesso del 9%. Gli avvisi dell’analisi statica, invece, crescono soprattutto perché cresce il codice: a parità di dimensione, l’effetto diretto di Cursor sugli avvisi non è significativo. Nei termini del conto giocattolo, per gli avvisi cresce $n$, per la complessità cresce anche $\delta$. Gli autori parlano di «debito di complessità» e di un circolo che si autoalimenta. Il loro consiglio è pratico: far crescere il controllo di qualità alla stessa velocità con cui cresce il codice.

Il terzo è il più ampio per numero di commit e di repository. Yue Liu, David Lo e altri quattro autori hanno raccolto 302.579 commit firmati da un assistente di AI (GitHub Copilot, Claude, Cursor, Gemini e Devin) in 6.299 repository pubblici con almeno cento stelle, guardando i file di produzione in Python, JavaScript e TypeScript. Per ogni commit hanno lanciato gli analizzatori statici prima e dopo la modifica, così da attribuire al commit esattamente i problemi che ha introdotto, e poi hanno seguito ogni problema fino all’ultima versione del repository. Un commit su undici (il 9,1%) ne introduce almeno uno, fra il 7,5 e il 14,8% a seconda dell’assistente; l’89,3% dei problemi sono code smell, difetti di manutenibilità più che errori; e il 22,7% dei problemi è ancora lì, anche quando è stato introdotto più di nove mesi prima.

Tre studi diversi, una stessa forma: più codice, lo stesso lavoro finito, più complessità lasciata indietro a ogni modifica. È la frase con cui il saggio li riassume, e regge.

Regge però su una cosa diversa dalla decoerenza, e conviene dirlo. Nessuno dei tre la misura. Contano avvisi dell’analisi statica, complessità, code smell, tempi di revisione: debito a livello di codice. Liu e colleghi scrivono esplicitamente che il debito architetturale e l’erosione del progetto, cioè proprio il terreno della decoerenza, restano fuori dalla portata dei loro strumenti. Il loro studio, poi, non ha un gruppo di controllo umano: spiegano che costruirne uno affidabile è difficile, perché l’AI si usa anche senza lasciare traccia nei commit, e quindi quel 9,1% non dice se le persone facciano meglio o peggio. Il confronto più solido sulla qualità del codice è quello di Carnegie Mellon, che un gruppo di controllo ce l’ha (anche se, ammettono gli autori, quei progetti possono usare altri strumenti di AI senza lasciare traccia), ma guarda solo progetti open source, un solo strumento, e solo i progetti che hanno salvato nel repository i file di configurazione di Cursor. Sono dati compatibili con la tesi, non una sua dimostrazione.

Il telaio, non il tessuto

L’obiezione principale la si sente spesso. La prima generazione di agenti scrive codice peggiore, ma se è «abbastanza buono» può già sostituire le persone nella maggior parte del lavoro di programmazione, e intanto si costruiscono i processi attorno agli agenti che verranno. È la storia della Rivoluzione industriale: i primi telai meccanici facevano tessuti peggiori di quelli fatti a mano, e poi hanno recuperato. Maevyn ricorda, con Cory Doctorow, che gli industriali li adottarono perché permettevano di disciplinare il lavoro e concentrare il potere, e che operai e consumatori pagarono per generazioni condizioni peggiori e merci peggiori.

Ma il paragone, osserva il saggio, regge solo se il codice è il tessuto. E nessuno compra codice: si comprano applicazioni. Ogni schermata mostrata, ogni modulo inviato, ogni record aggiornato è il prodotto; il codice è la macchina che lo produce, ed è per questo che il software rende tanto, perché un cliente in più non costa quasi niente. Il telaio dell’Ottocento produceva tessuti mediocri per anni senza diventare più disordinato: si consumava, veniva sostituito da un modello migliore, ma mentre lavorava non accumulava decoerenza. Un agente che scrive codice somiglia piuttosto a una macchina che progetta telai, e una macchina del genere non è mai esistita.

Una macchina che progetta le macchine successive è anche il sogno dell’auto-miglioramento ricorsivo, la cosiddetta esplosione di intelligenza: un’AI abbastanza brava da costruire un’AI migliore, che ne costruisce una migliore ancora. È un dibattito che abbiamo già raccontato dal lato di chi fa ricerca. Il saggio ci entra dal lato del codice.

Che cosa si può misurare dentro un data center

Nel maggio di quest’anno Tom Reed, scettico sull’esplosione di intelligenza, ha chiamato «singolarità di Goodhart» il limite di un’AI che migliora chiusa in una bolla, senza dati nuovi dal mondo: quando una misura diventa un obiettivo, smette di essere una buona misura (è la legge di Goodhart, nella formulazione dell’antropologa Marilyn Strathern). Dall’altra parte Tom Davidson, ricercatore di Forethought, che ha scritto molto sulla velocità del decollo dell’AI (sui suoi modelli si sono appoggiate previsioni come lo scenario AI 2027), ha concesso a settembre che i dati rallenteranno il progresso quando l’AI arriverà al «soffitto della qualità umana», oltre il quale non resta una dimostrazione umana migliore da cui imparare. Un rallentamento, sostiene, non un muro: costruire problemi difficili e verificarne le soluzioni è più facile che risolverli, e già oggi esperti umani costruiscono ambienti di apprendimento per rinforzo che producono dati sopra quel soffitto.

Nei giochi (Go, scacchi, StarCraft, Dota) le regole sono il mondo intero e la vittoria è chiara: lì migliorare in isolamento si può, e lo si è fatto. Il software sembra il candidato successivo, perché gira e si collauda al chiuso. Ma ciò che rende buono il software, risponde Maevyn, è la coerenza, e la coerenza dentro la bolla non si misura. Velocità, memoria e righe di codice si misurano benissimo, e lì un’AI può superare le persone anche al chiuso. Solo che il codice diventa veloce saltando lavoro, e salta lavoro facendo ipotesi sul resto del sistema (questa lista è già ordinata, quel valore non è mai zero): ogni ipotesi è una connessione nascosta che nessuno ha scritto. Ottimizzare tutto per quelle misure darebbe software piccolo, veloce e del tutto decoerente.

L’esempio scelto è quello dei future, i segnaposto per un valore che arriverà, che hanno messo ordine nella programmazione asincrona, dove prima convivevano molti modi sensati e incompatibili di fare la stessa cosa. L’idea è degli anni Settanta, una delle prime implementazioni (in MultiLisp) è del 1985; Java li aggiunge nel 2004, ma si diffondono davvero solo negli anni Dieci, con le promise concatenabili di JavaScript e i Task di C#. Che valessero il loro costo si è capito solo quando l’intero insieme dei programmi del web è esistito. Un’AI chiusa in un data center, conclude il saggio, può diventare brava a piacere nel rendere coerente il software che c’è già; per quello che non c’è ancora deve uscire dalla bolla, altrimenti non sa se i suoi algoritmi di apprendimento stanno migliorando o deragliando.

Il secondo argomento vale per ogni forma di esplosione. Ogni generazione di AI che lavora oltre la frontiera di ciò che capisce rischia di introdurre decoerenza nei propri sistemi: se va troppo veloce la accumula più in fretta di quanto la ripari, e si blocca o regredisce; se verifica tutto, la frena la velocità con cui raccoglie dati dal mondo. Maevyn lo mostra riprendendo il modello di Eth e Davidson sull’esplosione di intelligenza software, la cui proiezione, scrive, impenna prima del quinto mese, e aggiungendo una sola ipotesi: che il costo di ogni modifica raddoppi man mano che il lavoro accumulato cresce, come succede nel codice scritto dalle persone. La curva che ne esce è quella del blocco.

Nemmeno la matematica, l’altro campo che sembra verificabile al chiuso con le dimostrazioni formali, ne esce indenne. L’algebra di George Boole, pubblicata nel 1847, è rimasta, racconta il saggio, per quasi un secolo una curiosità della logica formale, finché Claude Shannon, al MIT, lavorando ai relè dell’analizzatore differenziale di Vannevar Bush, si è accorto che i circuiti seguivano le stesse regole: lo scrisse nella tesi di master, nel 1937. Shannon aveva davanti una stanza piena di relè e un problema vero; in pile sterminate di dimostrazioni tutte valide in locale e tutte insensate nell’insieme, chiede il saggio, quel collegamento l’avrebbe trovato? È un timore vicino a quello della dichiarazione firmata l’11 settembre da venticinque medaglie Fields, fra cui Terence Tao: risolvere problemi è uno strumento e un indicatore indiretto, lo scopo è la comprensione, e una produzione di massa, sempre più rapida, di enunciati veri o falsi rischia di distruggere il terreno fertile invece di farci nascere idee nuove.

Il collasso

L’ultima parte del saggio torna a terra. Fra gli anni Ottanta e i Duemila ogni azienda gestiva il proprio stack, ogni server era un fagotto unico di dipendenze, script e versioni, e in un’azienda media serviva una squadra solo per tenere tutto in piedi. Le guerre fra le varianti di Unix frammentavano ancora di più. Buona parte del lavoro degli ultimi vent’anni, con Linux e il software libero in testa, è stata aggiungere coerenza a quell’ecosistema. Maevyn teme che adesso si stia facendo il contrario, una specie di agricoltura del taglia e brucia: buttare via la coerenza costruita in comune per riscrivere ogni dipendenza, personalizzare ogni programma, allargarsi in ogni direzione per risolvere problemi di breve periodo. L’esempio che sceglie è Omarchy, una distribuzione Linux molto orientata agli agenti, nata come un insieme pulito di impostazioni predefinite e che, scrive, sembra avviata a diventare una distribuzione intera con un kernel suo. E precisa che sperimentare ai margini dell’ecosistema è sano, se poi quello che si scopre torna alla comunità.

Lo scenario che il saggio chiama collasso da decoerenza è questo. Se si spinge troppo e troppo a lungo senza mantenere o ricostruire la coerenza, si arriva a sistemi tanto grandi che solo gli agenti possono mantenerli. Se a quel punto si scopre che gli agenti non sanno riportarli indietro, facendo il lavoro di riparazione, si resta chiusi in un modo di sviluppare che degrada i sistemi per quanto ci si sforzi di aggiustarli. Non per sempre, ma per anni o decenni, durante i quali non si consegnano funzioni e non si lavora agli altri problemi urgenti. Maevyn scrive di averne più paura che di una superintelligenza fuori controllo, perché questo, dice, sta succedendo adesso.

Dove il saggio convince, e dove no

Convince la distinzione centrale. Dire che la decoerenza cresce con le modifiche e non con il tempo cambia il modo di guardare agli agenti: la domanda non è se scrivano codice buono, ma quanta coerenza lasciano a chi viene dopo, moltiplicata per il numero di modifiche che fanno. Convince il meccanismo della fretta, che chiunque abbia lavorato in un’azienda ha visto. E convince il collegamento con il tappo della revisione misurato a Harvard: se a ricucire la coerenza sono ancora le persone che rivedono il codice, generare più codice di quanto se ne riesca a rivedere non accelera niente.

Convince meno il salto dall’esperienza quotidiana alla tesi generale. Che la complessità cresca in modo esponenziale e non lineare è, per ammissione dell’autrice, una convinzione maturata sul campo, e la simulazione mostra che può succedere, non che succede. La parte sull’esplosione di intelligenza, poi, si regge su una premessa che il saggio afferma più di quanto dimostri: che la coerenza non abbia indicatori misurabili dentro la bolla. L’argomento di Davidson va nella direzione opposta (verificare è più facile che risolvere), e il saggio gli oppone una premessa più che una prova. Va anche notato che gli agenti di programmazione, nella pratica, in una bolla non ci stanno: ricevono il giudizio di chi li usa, i test, il comportamento in produzione. Il rischio di decoerenza nel codice di tutti i giorni e l’argomento contro l’auto-miglioramento in isolamento sono due tesi diverse, e la prima, per chi programma, è quella che conta.

Infine la posizione dell’autrice, che è dichiarata. Maevyn si riconosce nell’analisi di Cory Doctorow sul «centauro rovesciato» (non vogliamo che la macchina guidi noi, vogliamo guidare la macchina), considera l’AI utile soprattutto ai margini del lavoro e pubblica la propria politica d’uso. Non è un difetto del saggio: è il punto da cui guarda, e chi lo legge fa bene a saperlo.

Che cosa si può fare

Il saggio non è un manuale, ma dalle sue tesi e dagli studi che cita si ricavano alcune pratiche. Le prime due sono nostre, le altre hanno una fonte.

Contare i modi di fare la stessa cosa. La decoerenza non ha un linter, ma ha un indicatore rozzo e onesto: quante maniere ci sono, nel codice, di fare una chiamata di rete, leggere la configurazione, gestire un errore, trattare una data. Se il numero sale da un mese all’altro, $\delta$ è positivo, qualunque cosa dicano i test. È una domanda che si può fare anche a un agente, chiedendogli di elencarle.

Finire le migrazioni. Migrare a pezzi va benissimo, purché ci sia una fine. Il pattern che Martin Fowler ha chiamato strangler fig, il fico strangolatore che cresce attorno all’albero vecchio fino a sostituirlo, funziona proprio perché alla fine il sistema vecchio viene tolto. Una migrazione ha bisogno di una data, di un elenco dei punti che restano da convertire e di un controllo che fallisce quando lo schema vecchio ricompare. E, come avverte il saggio, non se ne comincia una seconda prima di aver chiuso la prima.

Scrivere le regole dove l’agente le legge, e renderle meccaniche. Nel libro raccontiamo come la squadra di Ryan Lopopolo, in OpenAI, tiene in ordine un repository in cui nessuna riga di codice è scritta a mano: «principi d’oro» perentori nel repository (una libreria condivisa invece di funzioni scritte a mano da ogni agente, così che una regola stia in un posto solo) e una pulizia continua, fatta da agenti in sottofondo, che apre richieste di modifica piccole e mirate. Il debito, nella sua formula, è un prestito a interesse alto: conviene quasi sempre ripagarlo un poco alla volta, di continuo, invece che a ondate dolorose.

Legare il controllo di qualità alla velocità. È il consiglio degli autori di Carnegie Mellon: cicli di rifattorizzazione fatti scattare dalle metriche di qualità, requisiti di copertura dei test che crescono con le righe aggiunte, regole scritte per l’agente che impongano gli standard del progetto.

Dimensionare la revisione, non la generazione. Lo studio di Harvard dice dove si ferma il flusso: generare più codice di quanto le persone riescano a rivedere sposta il lavoro, non lo accorcia. Richieste di modifica più piccole, e attenzione al debito di comprensione (l’espressione è di Addy Osmani): il codice che nessuno ha letto, qualcuno dovrà capirlo quando qualcosa si rompe. Il libro ne ricava la regola di restare l’ingegnere: chi mantiene un sistema deve leggere quello che parte, non solo guardare la spia verde dei test.

Puntare gli agenti anche sulla ricomposizione. Se la decoerenza cambia solo quando il sistema cambia, anche le modifiche degli agenti possono abbassarla: unificare due librerie, togliere un adattatore, completare una migrazione lasciata a metà. Se ci riescano su larga scala è la domanda aperta del saggio, e la si può misurare sul proprio codice prima di darla per risolta in un senso o nell’altro.

Che cosa c’è in gioco

Maevyn chiude con due pensieri che tolgono al saggio il tono dell’apocalisse. Il primo: la decoerenza cambia solo quando i sistemi cambiano, quindi per quanto in fondo si sia arrivati si può sempre smettere di andare avanti e cominciare a tornare indietro. Se l’AI ci ha spinti dentro la trappola potrebbero volerci anni o decenni, ma la parte più dura è all’inizio, e da lì il lavoro si fa sempre più leggero, purché lo si finisca. Migliorare la coerenza quel tanto che basta per tornare alle vecchie abitudini vuol dire solo ricominciare il giro. Il secondo: i processi che costruiscono coerenza esistono già, e il software libero è fra i più riusciti. Sarà, annuncia, il tema del prossimo saggio, Open Capital.

Torniamo alla scatola di derivazione. L’elettricista bravo, davanti a tre epoche di fili, a volte propone di rifare la linea intera invece di aggiungere la quarta giunzione: costa di più oggi, e il cliente lo guarda storto. Per chi lavora con gli agenti il punto è lo stesso. Quanto codice scrivono si misura in un pomeriggio, e il numero è sempre lusinghiero. Che cosa lasciano a chi dovrà fare la modifica successiva si scopre più tardi, quando qualcuno chiede se la linea regge il carico nuovo.

Per approfondire

Kristen Maevyn, The Decoherence Trap: When AI slop drowns out the signal in an endless sea of noise, maevyn.codes, 14 ottobre 2026, maevyn.codes/decoherence, licenza CC BY 4.0; la simulazione interattiva è su maevyn.codes/decoherence/sim. Fiona Chen e James Stratton, Artificial Intelligence in the Firm: Bottlenecks in Software Production, working paper, Harvard University, versione del 4 agosto 2026, fion.ac/jellyfish.pdf. Hao He, Courtney Miller, Shyam Agarwal, Christian Kästner e Bogdan Vasilescu, Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects, MSR 2026, arxiv.org/abs/2511.04427. Yue Liu, Ratnadira Widyasari, Yanjie Zhao, Ivana Clairine Irsan, Junkai Chen e David Lo, Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild, arXiv, terza versione del 13 ottobre 2026, arxiv.org/abs/2603.28592. Tom Davidson, Data bottlenecks won’t prevent an intelligence explosion (but they will slow it down), Forethought, 8 settembre 2026, forethought.org. Terence Tao e altre ventiquattro medaglie Fields, A Severe Misalignment of AI in Mathematics, 11 settembre 2026, terrytao.wordpress.com. Frederick P. Brooks, The Mythical Man-Month, 1975, capitolo 4. Meir M. Lehman, Programs, Life Cycles, and Laws of Software Evolution, Proceedings of the IEEE, 1980.