"L’AI riscriverà il COBOL." Lo slogan circola da un paio d’anni, e come tutti gli slogan è vero a metà. I sistemi core di banche e assicurazioni poggiano ancora su applicazioni z/OS scritte decenni fa — PL/I, COBOL CICS, ASSEMBLER — e i due approcci classici alla modernizzazione hanno entrambi un difetto noto. La riscrittura manuale è lenta, costosa e dipende da competenze che stanno andando in pensione. La transpilazione automatica produce quello che in gergo si chiama "Java che parla COBOL": codice formalmente moderno e sostanzialmente immantenibile.

Negli ultimi tempi si è aggiunto un terzo modo di fallire, più sottile: dare i sorgenti a un modello linguistico e aspettarsi che ne esca un sistema. Non funziona, ma non per il motivo che si pensa. Il modello il codice lo scrive, e spesso lo scrive bene. Il problema è tutto quello che viene dopo.

La verifica è il vero collo di bottiglia

Generare codice con l’AI è diventato veloce ed economico. Verificarlo no. In un portafoglio di centinaia di programmi bancari, se ogni programma migrato richiede una review umana completa, l’AI non ha cambiato l’economia del progetto: ha solo spostato il costo dalla scrittura alla lettura.

Per questo un metodo serio investe più sulla verifica che sulla generazione. Nel nostro approccio ogni programma migrato attraversa una catena di gate automatici: compila nello stack target, rispetta gli standard all’analisi statica, supera i test generati con soglie di copertura, e — il gate decisivo — produce gli stessi output del programma originale a parità di input. Per l’online si aggiungono la coerenza delle mappe video e la copertura completa del catalogo transazioni.

Il punto concettuale è questo: il codice migrato non viene giudicato, viene confrontato. L’equivalenza funzionale con il sistema esistente non è un’opinione di chi fa la review, è un’evidenza misurata. La review umana resta, ma interviene per eccezione — programmi ad alta complessità, gate in fail — e questo cambia di un ordine di grandezza il tempo per programma. È il QA automatico, non il modello, il moltiplicatore di throughput.

La domanda da fare prima di scrivere una riga

C’è una singola domanda che pesa più di ogni altra in un assessment di fattibilità: quanto è standardizzato questo codebase?

Quasi ogni grande installazione mainframe ha librerie interne, costruite negli anni, che uniformano l’accesso ai dati e la gestione delle transazioni. Quando esistono e sono pervasive, l’apparente idiosincrasia di centinaia di programmi si rivela per quello che è: un numero finito di pattern ripetuti. E una migrazione guidata da pattern è un problema radicalmente diverso — per rischio, tempi e costi — da un redesign architetturale programma per programma.

La fase di studio serve esattamente a misurare questa copertura, layer per layer: l’accesso ai dati, il flusso delle schermate, l’orchestrazione delle transazioni. È un lavoro che si fa prima di impegnarsi su qualunque numero, perché da quella risposta dipende tutto il resto.

La conoscenza va nelle convention, non nelle teste

Una volta identificati i pattern, la tentazione è documentarli e affidarli all’esperienza del team. Noi facciamo una cosa diversa: li codifichiamo in convention parametriche che la pipeline consuma. Tutta la conoscenza specifica del contesto — gli standard del cliente, le sue librerie, i mapping tecnologici — vive in file di configurazione; la pipeline che li applica resta identica da un cliente all’altro.

Le conseguenze pratiche sono tre. La varianza di qualità tra programmi crolla, perché la traduzione non viene reinventata ogni volta. Il processo scala orizzontalmente: più istanze AI in parallelo sugli stessi pattern, su stream separati per il batch e per l’online. E il know-how si accumula in un artefatto riusabile invece che disperdersi a fine progetto.

I bug del legacy sono un deliverable

Un effetto collaterale prezioso del reverse engineering sistematico: i bug latenti del codice originale emergono. Accessi fuori dai limiti di un array, campi scambiati, righe critiche commentate quindici anni fa e mai più toccate. Sistemi che "funzionano da sempre" funzionano anche grazie a errori a cui tutto ciò che sta a valle si è adattato.

Per questo ogni anomalia trovata entra in un inventario formale, e per ciascuna si prende una decisione esplicita: preservare il comportamento o correggerlo. La decisione viene poi propagata in modo coerente su codice migrato, scenari di test e documentazione. Sembra burocrazia; è ciò che evita che il collaudo scopra divergenze "misteriose" tra vecchio e nuovo.

L’onestà sul perimetro è parte del metodo

Ultima lezione, la meno tecnica. In ambito bancario il rilascio in produzione appartiene ai processi e alle responsabilità del cliente: il confine contrattuale onesto per una migrazione è il collaudo, non il go-live. Allo stesso modo, una fase di studio seria può concludere che parti del portafoglio non convenga migrarle affatto. Un metodo che promette tutto, in questo dominio, sta promettendo male.

---

I principi completi del metodo — la pipeline ad agenti, i sei gate di QA, l’approccio per convention — sono descritti in dettaglio nel repository pubblico modernLegacy. L’implementazione è proprietaria, ma del metodo parliamo volentieri: se hai un portafoglio legacy e ti stai ponendo la domanda "da dove cominciare", la risposta breve è: da un assessment delle tue librerie interne. Per quella lunga, contattaci.