Il Miglior ROI dell’AI Adesso è Correggere il Vecchio Codice, Non Scrivere Nuovo Codice

Ogni demo di prodotto AI a cui partecipo inizia allo stesso modo: una casella di prompt vuota, una richiesta in inglese chiaro e un’applicazione funzionante dopo pochi minuti. È un vero e proprio trucco di festa impressionante. È anche, credo, la cosa meno interessante che sta succedendo nell’AI aziendale adesso.

Il lavoro più consequenziale sta avvenendo in un posto molto meno glamour: all’interno di basi di codice di quindici anni fa che nessuno vuole toccare, scritte da ingegneri che hanno lasciato l’azienda dieci anni fa, che eseguono logica aziendale che nessuno ha completamente capito da anni. La maggior parte della copertura dell’AI si sbaglia. Il codice legacy non è un debito tecnico. È intelligenza aziendale accumulata: decenni di decisioni, codificate come software, con le persone che hanno preso quelle decisioni ormai scomparse.

Lo sviluppo in greenfield ottiene gli slot delle keynote. Il vecchio codice ottiene i soldi, a malincuore, e di solito senza la comprensione necessaria per spenderli bene.

La Vera Carenza Non Sono gli Sviluppatori, È la Memoria

Questo non è un problema isolato. Uno studio Pegasystems del 2025, condotto dalla società di ricerca Savanta su oltre 500 responsabili IT in tutto il mondo, stima che l’azienda media globale sprechi oltre $370 milioni all’anno a causa della sua incapacità di modernizzare efficientemente i sistemi legacy, con quasi $134 milioni di quel importo legati a progetti di trasformazione lenti e risorse-intensive.

Abbiamo recentemente lavorato con un’azienda di distribuzione di batterie che eseguiva oltre quindici applicazioni legacy, il tipo di dispersione che si accumula in vent’anni di fusioni, integrazioni una tantum e ingegneri che risolvono il problema di oggi senza pensare molto a quello di domani. Seppellito in quel codice c’erano regole di prezzo, soglie di inventario e vincoli di distribuzione che rappresentavano anni di decisioni istituzionali, scritte da nessuna parte se non nella logica che nessuno aveva completamente mappato.

È tentante definirlo un problema di talenti: assumere più sviluppatori, migrare più velocemente. Ma non puoi assumere il tuo modo fuori dal fatto che la persona che capiva perché un modulo funzionava in un certo modo ha lasciato l’azienda nel 2014. La maggior parte delle aziende soffre di una carenza di memoria, non di una carenza di talenti. E fino a poco tempo fa, non c’era un vero modo per risolvere questo problema su larga scala. O pagavi un pugno di ingegneri senior per tenere la conoscenza istituzionale nelle loro teste indefinitamente, o la perdevi il giorno in cui se ne andavano.

Cosa Cambia Veramente l’AI

Non abbiamo puntato uno strumento di generazione di codice sul vecchio codice e detto di riscrivere tutto; è più o meno come cancellare silenziosamente la logica aziendale che non sapevi esistesse. Invece, abbiamo usato agenti AI per fare il lavoro di base non glamour per primo: tracciare come le quindici applicazioni si connettevano effettivamente l’una all’altra, portare in superficie le decisioni incorporate nella logica che non erano state scritte da nessun’altra parte e tenere quel contesto come qualcosa che l’organizzazione poteva interrogare, non qualcosa che viveva solo nella testa di un ingegnere. Ciò si allinea con ciò che altri vendor di AI stanno documentando pubblicamente: la guida di Anthropic sulla modernizzazione dei sistemi COBOL con Claude Code descrive la stessa sequenza, automatizzando le fasi di esplorazione e analisi per prime, anziché saltare direttamente alla riscrittura.

Gli agenti non sono stati valutati su quanto codice hanno generato. Sono stati valutati su quanto conoscenza istituzionale potevano portare in superficie e preservare. Gli ingegneri hanno lavorato insieme a loro sulla migrazione effettiva e sulla generazione dei test, verificando l’interpretazione degli agenti della logica aziendale rispetto a come il sistema si comportava in produzione, non fidandosi della fede. Un segnale utile che abbiamo guardato: corrispondeva la spiegazione dell’agente di una regola a un modello che potevamo verificare indipendentemente nei log di produzione, o era un’ipotesi plausibile? Il divario tra quei due è esattamente dove i progetti di modernizzazione del legacy di solito vanno storti.

La stima originale per il progetto era di otto mesi e mezzo. È stato chiuso in quattro, una riduzione del 53%. Ma il risultato più duraturo non è stato la tempistica. La conoscenza istituzionale che un tempo evaporava ogni volta che un ingegnere lasciava l’azienda è diventata qualcosa che l’organizzazione poteva effettivamente conservare.

Gli ingegneri del software hanno trascorso decenni a scrivere software. Il prossimo decennio potrebbe essere trascorso scavando, con l’AI che agisce meno come autore e più come archeologo, ricostruendo attentamente il ragionamento sepolto nel codice che ha superato le persone che lo hanno scritto.

Una Struttura Approssimativa per Fare Ciò Senza Rompere le Cose

I progetti che vanno bene sembrano seguire grossomodo la stessa sequenza, sia che il sistema sia un motore di prezzo o una pipeline di reclami:

Scopri: mappa come i sistemi si connettono effettivamente, non come il diagramma di architettura del 2016 dice che si connettono.

Comprendi: fai in modo che l’agente porti in superficie la logica aziendale e le ipotesi dietro di essa, in un linguaggio chiaro che un esperto di dominio possa verificare.

Verifica: controlla quell’interpretazione contro il comportamento reale di produzione, non solo contro i commenti del codice.

Trasforma: migra o ricostruisci solo una volta che le prime tre fasi tengono, con gli esseri umani che possiedono il via libera.

Saltare direttamente a Trasforma e non si sta modernizzando. Si sta scommettendo con la logica che non si capisce ancora.

Perché Ciò È Importante Al Di Là Dei Team di Ingegneria

La memoria istituzionale non si limita a decadere silenziosamente quando un ingegnere senior si ritira. Diventa un’acuta passività nel momento esatto in cui un’azienda può permetterselo meno: durante un’acquisizione, quando un nuovo proprietario deve capire cosa ha effettivamente acquistato; durante una migrazione ERP, quando la vecchia logica deve essere tradotta in un nuovo sistema correttamente per la prima volta; durante un audit di conformità o una risposta agli incidenti, quando qualcuno deve spiegare perché il sistema si è comportato in un certo modo, sotto scadenza, a un regolatore che non accetterà “la persona che lo ha costruito se n’è andata nel 2014” come risposta.

Trattata in questo modo, la modernizzazione del legacy smette di essere un elemento di linea per l’ingegneria e inizia ad assomigliare a una questione di resilienza organizzativa, il che significa che non sono solo i CTO che dovrebbero preoccuparsene. Sono i CIO che valutano cosa succede quando il personale tecnico chiave si dimette, i team di M&A che cercano di valutare cosa stanno effettivamente acquistando e i consigli di amministrazione che pensano a quanto della conoscenza operativa dell’azienda esiste da nessun’altra parte se non nel codice che attualmente nessuno legge.

L’Avertimento Che Conta

Nessuno di questo funziona senza supervisione. La versione più rischiosa di questo approccio è quella in cui l’interpretazione di un agente della vecchia logica aziendale viene affidata senza verifica, perché i sistemi legacy sono esattamente il posto in cui un’ipotesi di AI confidentemente sbagliata costa di più. La piena autonomia nel tuo nuovo microservizio è una scommessa ragionevole. La piena autonomia nel motore di prezzo che nessuno ha toccato dal 2011 non lo è. Il valore è che l’AI rende possibile diventare nuovamente gli ingegneri che capiscono l’azienda, in un sistema che attualmente nessuno capisce. Non li sostituisce.

Dove Credo Che Ciò Vada Ora

Per vent’anni, le aziende hanno trattato il software legacy come qualcosa da cui fuggire: un centro di costo da finanziare a malincuore e modernizzare il più velocemente possibile. Credo che l’AI stia per rivelare che molto di quel codice era in realtà uno dei repository di conoscenza più preziosi che l’azienda abbia mai costruito. Aveva solo bisogno di qualcosa in grado di leggerlo. I ricercatori stanno già documentando l’altro lato di questo ciclo: una revisione della letteratura multivocale del 2026 sullo sviluppo assistito da LLM scopre che l’attuale ricerca della velocità accelerata dall’AI sta creando “debito di integrazione rapida”, codice spedito più velocemente di quanto possa essere capito. La modernizzazione del legacy è solo la bolletta che arriva finalmente, una generazione prima.

Mi chiederei se altri leader tecnologici e ingegneri stanno vedendo lo stesso spostamento: il ritorno sull’investimento AI si sta manifestando di più in ciò che stai costruendo o in ciò che sei finalmente in grado di capire e preservare? E per chiunque abbia provato a eseguire agenti AI contro un sistema veramente vecchio e non documentato, dove l’interpretazione dell’agente ha retto alla verifica e dove si è silenziosamente dissolta?