Il problema non è che il COBOL sia vecchio. Il problema è che spesso regge ancora processi critici, ma quasi nessuno li capisce davvero fino in fondo. Quando un team eredita un gestionale bancario, assicurativo o amministrativo con migliaia di righe e documentazione incompleta, capire come fare reverse engineering codice Cobol con AI diventa una necessità operativa, non una curiosità tecnica.
L’AI può aiutare molto, ma va usata nel modo giusto. Non sostituisce l’analista senior, non interpreta da sola il contesto aziendale e non può inventare regole di business mancanti. Quello che fa bene è accelerare la lettura del codice, ricostruire relazioni, proporre spiegazioni, individuare pattern e trasformare un patrimonio legacy opaco in qualcosa di finalmente navigabile.
Quando l’AI serve davvero nel reverse engineering COBOL
Il reverse engineering di un’applicazione COBOL serve quasi sempre per quattro motivi: manutenzione urgente, migrazione verso piattaforme più moderne, audit applicativo oppure recupero della conoscenza persa con il turnover del personale. In questi scenari il collo di bottiglia non è solo tecnico. È cognitivo.
Un programma COBOL può essere leggibile nella sintassi, ma difficile da comprendere nella logica reale. Ci sono paragrafi riutilizzati in punti diversi, copybook condivisi da decine di moduli, accessi a file o database storici e nomi di variabili che riflettono convenzioni interne di vent’anni fa. L’AI è utile quando deve ridurre questo carico iniziale e offrire una prima mappa del sistema.
Funziona bene soprattutto per generare documentazione tecnica, spiegare blocchi di codice, classificare moduli per funzione e ricostruire dipendenze. Funziona meno bene quando deve decidere da sola il significato di una regola di business ambigua o interpretare eccezioni nate da vincoli normativi ormai cambiati.
Come fare reverse engineering codice Cobol con AI senza perdere il controllo
L’errore più comune è incollare interi sorgenti in un modello linguistico e chiedere: “spiegami tutto”. È veloce, ma produce sintesi superficiali oppure plausibili e sbagliate. Un approccio più affidabile è progressivo.
Si parte dall’inventario. Prima di usare l’AI bisogna sapere quali artefatti esistono: programmi COBOL, copybook, JCL, file di configurazione, definizioni CICS o IMS, script SQL, tracciati record, documentazione residua. Senza questa base, il modello vede frammenti e non il sistema.
Poi si passa alla segmentazione. I moduli vanno analizzati per unità logiche: identification division, data division, procedure division, paragrafi chiave, accessi a file, chiamate a subprogram, sezioni di validazione ed elaborazione batch. Questo permette di porre domande molto più precise e ottenere risposte verificabili.
Il terzo passaggio è la contestualizzazione. Se all’AI dai solo il codice, ottieni un commento sul codice. Se invece aggiungi lo scopo del programma, il tipo di input, l’output atteso e il ruolo nel flusso applicativo, la qualità dell’analisi cresce in modo netto.
Infine c’è la validazione. Ogni spiegazione generata deve essere confrontata con esecuzioni reali, job batch, dati di test e analisi umana. L’AI è un acceleratore di comprensione, non una fonte definitiva di verità.
Un flusso pratico che funziona
In un progetto reale, il lavoro efficace di solito segue questo ordine. Prima si estrae il catalogo completo dei sorgenti e delle dipendenze. Poi si costruisce una matrice tra programmi, copybook, file e chiamate esterne. A quel punto l’AI può essere usata per commentare ogni modulo, produrre un riassunto funzionale e segnalare le aree a maggiore densità logica.
La fase successiva consiste nel chiedere al modello di individuare pattern specifici: punti di input, trasformazioni dati, calcoli economici, validazioni, gestione errori, scritture su archivi, dipendenze da date, controlli su codici cliente o pratica. Qui la domanda conta più dello strumento. Una richiesta generica produce testo generico. Una richiesta come “elenca le condizioni che determinano lo scarto del record e indica in quale paragrafo avvengono” produce valore concreto.
Dopo l’analisi del singolo modulo si passa alla vista trasversale. L’obiettivo è ricostruire il flusso end-to-end: da dove arrivano i dati, dove vengono trasformati, quali file o tabelle aggiornano e quali condizioni alterano il comportamento. Questa è la parte in cui l’AI aiuta a creare diagrammi descrittivi, documentazione operativa e basi per una futura modernizzazione.
Cosa chiedere all’AI per ottenere risultati utili
Nel reverse engineering COBOL, i prompt migliori sono orientati a un compito verificabile. Per esempio, è utile chiedere di descrivere lo scopo di un paragrafo, elencare input e output, identificare campi chiave, spiegare quando viene eseguita una chiamata esterna oppure segnalare possibili dead code.
Un’altra richiesta molto utile è la traduzione dal linguaggio tecnico al linguaggio di business. Un team IT può capire il PERFORM THRU, ma il referente applicativo ha bisogno di sapere se quella sezione calcola interessi, genera una distinta oppure blocca una pratica incompleta. L’AI è particolarmente efficace come ponte tra lettura tecnica e sintesi funzionale.
Vale anche il contrario. Se si dispone di una descrizione funzionale incompleta, il modello può aiutare a cercare nel codice i punti che la implementano. Non è una ricerca perfetta, ma riduce molto il tempo perso a navigare sorgenti senza priorità.
I limiti reali dell’AI sui sistemi legacy
Qui serve prudenza. Il COBOL non vive quasi mai da solo. Spesso è immerso in ecosistemi con JCL, scheduler, transazioni CICS, database DB2, VSAM, file flat e naming convention non documentate. L’AI può spiegare bene il frammento locale, ma perdere la logica distribuita tra componenti.
C’è poi il rischio delle allucinazioni. Se un copybook manca, se una CALL dinamica non è risolta o se una tabella esterna decide il comportamento, il modello tende a colmare i vuoti con supposizioni plausibili. Per questo bisogna distinguere sempre tra ciò che è dedotto dal codice e ciò che è solo inferito.
Un altro limite riguarda sicurezza e compliance. Caricare codice legacy in strumenti cloud senza controllo può esporre logiche proprietarie, dati sensibili o dettagli di infrastruttura. In ambienti regolati conviene usare piattaforme aziendali con governance chiara, mascheramento dei dati e tracciamento degli accessi.
Strumenti e approccio operativo
Non esiste un solo tool giusto. Nella pratica il lavoro migliore combina parser statici, repository di codice, strumenti di dependency analysis e modelli AI per la spiegazione semantica. I parser servono a estrarre struttura e relazioni con precisione. L’AI serve a trasformare quella struttura in comprensione umana.
Se il parco applicativo è ampio, conviene partire da una pipeline semplice: scansione dei sorgenti, classificazione dei moduli, estrazione delle dipendenze, arricchimento con commenti AI, revisione umana e pubblicazione della documentazione. Questo evita l’effetto demo, cioè una bella analisi su un singolo file che poi non scala sull’intero sistema.
Per team piccoli o PMI che devono solo capire un’applicazione critica, può bastare anche un processo semi-manuale ben governato. In questi casi conta più la disciplina del metodo che la sofisticazione della piattaforma.
Come validare i risultati senza fidarsi alla cieca
La validazione dovrebbe avvenire su tre livelli. Il primo è sintattico: il codice, i copybook e le dipendenze citate dall’AI esistono davvero? Il secondo è funzionale: la spiegazione corrisponde agli output osservabili del programma? Il terzo è di business: la regola identificata ha senso rispetto al processo aziendale reale?
Se disponibile, conviene costruire casi di test a partire da record storici anonimizzati. Quando il modello afferma che una certa condizione scarta un movimento o calcola una commissione, bisogna provare quell’affermazione con input controllati. Questo è il punto in cui l’analisi smette di essere descrittiva e diventa affidabile.
È utile anche mantenere una documentazione con livelli di confidenza. Alcune regole saranno confermate da test ed evidenze. Altre resteranno ipotesi ad alta probabilità. Separarle evita errori seri nei progetti di migrazione o refactoring.
Quando il reverse engineering con AI conviene davvero
Conviene quasi sempre quando la documentazione è scarsa, il personale storico non è più disponibile e i tempi di analisi sono stretti. Conviene molto anche prima di una riscrittura, perché riduce il rischio di portare nel nuovo sistema errori vecchi o dipendenze ignorate.
Conviene meno se ci si aspetta una ricostruzione perfetta e automatica del dominio applicativo. Se il sistema incorpora decenni di eccezioni non scritte, serviranno ancora interviste, test e revisione umana. L’AI riduce il tempo necessario per arrivare alle domande giuste. Non elimina il bisogno di porle.
Per un uso serio, anche su contesti operativi non enormi, la strategia migliore è trattare l’AI come un analista junior molto veloce: legge tanto, riassume bene, collega indizi utili, ma ogni decisione critica va controllata. È proprio questa combinazione tra automazione e verifica che rende il reverse engineering del COBOL finalmente praticabile, anche quando il sistema sembra una scatola nera da non toccare.
