Il 23 febbraio 2026, il prezzo delle azioni IBM crollò del 13% in un solo giorno, il calo giornaliero più marcato dall'ottobre del 2000. La causa scatenante fu l'annuncio di un laboratorio di intelligenza artificiale che affermava di essere in grado di modernizzare il COBOL. I consigli di amministrazione con infrastrutture mainframe lessero l'annuncio e si chiesero se l'intelligenza artificiale potesse ora convertire il loro COBOL e consentire loro di spegnere i mainframe. La risposta di IBM, pubblicata lo stesso giorno, fu precisa: la traduzione non coglie quasi per nulla la reale complessità, che risiede nell'architettura dei dati, nella sostituzione in fase di esecuzione, nell'integrità delle transazioni e nei requisiti non funzionali integrati nella piattaforma. Il mercato aveva confuso due problemi diversi e aveva valutato una soluzione a uno come se fosse una soluzione a entrambi.
I due problemi sono la comprensione e la traduzione. Non sono fasi della stessa attività. Si tratta di sfide tecniche autenticamente diverse che l'IA affronta con capacità e rischi altrettanto diversi. L'IA ha reso la comprensione del codice COBOL notevolmente più economica, ma non la sua sostituzione. Questa distinzione è fondamentale perché le organizzazioni che prendono decisioni di investimento per la modernizzazione devono sapere quale problema stanno effettivamente risolvendo, cosa offre concretamente l'IA per ciascuno di essi e in che misura il lavoro di verifica, che rimane indipendentemente dagli strumenti di IA, consumerà il budget che i risparmi ottenuti grazie alla comprensione e alla traduzione hanno reso necessario.
Le basi strutturali di cui l'IA ha bisogno
SMART TS XL identifica i programmi irraggiungibili prima che inizi la traduzione tramite IA, in modo da tradurre ciò che è in esecuzione, non ciò che esiste.
SCOPRI DI PIÙ…La distinzione che il mercato ha frainteso
Comprensione e traduzione non sono lo stesso problema.
La comprensione è la disciplina che permette di capire cosa fa un codice e perché, estraendo l'intento aziendale dall'implementazione tecnica. In un contesto COBOL, la comprensione significa: quali regole aziendali codifica questo programma? Quali condizioni governano ogni percorso di esecuzione? Quali dati legge e produce? Quali sistemi a valle dipendono dai suoi output? Cosa dovrebbe sapere un analista aziendale di questo programma per redigere una specifica per la sua sostituzione? La comprensione riguarda la semantica, il significato, non la sintassi.
La traduzione è la disciplina che si occupa di convertire il codice da un linguaggio a un altro preservandone il comportamento. Nel contesto COBOL, tradurre significa produrre codice Java (o Python, o Go) che esegua le stesse operazioni del codice COBOL, per tutti gli input, in tutte le condizioni, con un'equivalenza numerica sufficiente per i sistemi a valle che utilizzano gli output. La traduzione riguarda l'equivalenza strutturale e comportamentale: il nuovo codice deve superare tutti i test che il codice originale avrebbe superato, inclusi i test per i casi limite considerati dallo sviluppatore originale e di cui potresti non essere mai stato a conoscenza.
| Dimensioni | Comprensione | Traduzione |
|---|---|---|
| Domanda con risposta | Cosa significa questo codice? | Che cosa fa esattamente questo codice? |
| Tipo di uscita | Linguaggio naturale, documentazione | Codice eseguibile |
| Errore | Correggibile tramite revisione umana | Incidente di produzione |
| Capacità di intelligenza artificiale | I laureati LLM di alto livello eccellono nella prosa. | Debole, richiede determinismo |
| Vincolo di scala | Gestibile con finestre di contesto | Il limite di contesto a livello di portafoglio non è rispettato |
| Profilo di rischio | Basso, gli errori sono revisionabili | Elevati, gli errori sono invisibili finché non si verificano |
| Ruolo umano | Validatore e arricchitore | Revisore e collaudatore |
Questi problemi sono correlati, è necessaria una certa comprensione per una buona traduzione, ma non sono lo stesso problema, e il divario di capacità dell'IA tra i due è significativo. La comprensione del codice COBOL da parte dell'IA è davvero impressionante. La traduzione del codice COBOL in Java corretto per la produzione, tramite IA, è davvero difficile, e la confusione tra i due da parte del mercato è il motivo per cui Gartner ha previsto che oltre il 70% dei progetti di dismissione di mainframe avviati nel 2026 non produrrà i benefici previsti.
Dove la comprensione basata sull'IA si rivela davvero efficace.
Il problema della comprensione ha una caratteristica che rende l'intelligenza artificiale particolarmente adatta a risolverlo: l'output è in linguaggio naturale, e la generazione di linguaggio naturale è proprio ciò che i modelli linguistici di grandi dimensioni sanno fare bene. Quando l'IA legge un programma COBOL e produce documentazione, ovvero una descrizione di ciò che fa il programma, una spiegazione delle sue regole aziendali, un'enumerazione dei suoi flussi di dati, l'output è testo. Gli errori in quel testo sono recuperabili: un revisore umano può individuare una regola aziendale descritta in modo errato e correggerla senza alcuna conseguenza tecnica a valle. Il costo degli errori di comprensione è la correzione della documentazione, non un incidente di produzione.
Documentazione delle regole aziendali. Un modello linguistico di grandi dimensioni, presentato con un blocco EVALUATE in COBOL, potenzialmente contenente centinaia di condizioni WHEN accumulate nel corso di decenni di modifiche normative, può produrre una descrizione strutturata del significato di ciascuna condizione in termini aziendali. Per i programmi in cui la documentazione originale non esiste più o non è mai esistita, questo è di inestimabile valore. Un programma COBOL che implementa la logica di calcolo delle imposte in 63 giurisdizioni ha le regole di tali giurisdizioni codificate nella sua struttura EVALUATE; l'intelligenza artificiale può estrarle e documentarle più velocemente di qualsiasi processo manuale. Il risultato prodotto dovrebbe essere convalidato da un esperto del settore, ma l'esperto convalida l'output dell'IA anziché ricostruire la conoscenza da zero, un processo decisamente più rapido.
Ecco come si presenta la comprensione dell'IA nella pratica. Dato questo codice sorgente COBOL:
cobolo
EVALUATE TRUE
WHEN CUST-COUNTRY = 'US' AND CUST-STATE = 'CA'
COMPUTE TAX-AMT = GROSS-AMT * 0.0725
WHEN CUST-COUNTRY = 'US' AND CUST-STATE = 'TX'
COMPUTE TAX-AMT = GROSS-AMT * 0.0825
WHEN CUST-COUNTRY = 'UK'
COMPUTE TAX-AMT = GROSS-AMT * 0.20
WHEN CUST-COUNTRY = 'DE'
COMPUTE TAX-AMT = GROSS-AMT * 0.19
WHEN OTHER
MOVE ZERO TO TAX-AMT
END-EVALUATE.
Un LLM ben strutturato produce:
Business Rule: Tax Calculation
This paragraph applies jurisdiction-specific tax rates to GROSS-AMT:
- US/California: 7.25% (CA state sales tax)
- US/Texas: 8.25% (TX state sales tax)
- United Kingdom: 20% (UK VAT standard rate)
- Germany: 19% (DE MwSt standard rate)
- All other countries: tax-exempt (TAX-AMT = 0)
Note: No rate exists for other US states. Orders from NY, FL, IL
will be tax-exempt under current logic -- likely a gap requiring review.Questo output è davvero prezioso: documenta quattro regole aziendali, identifica una probabile lacuna (gli stati degli Stati Uniti senza tariffe esplicite) e lo fa in poche ore. Un esperto del settore lo esamina, conferma la lacuna e lo aggiunge ai casi di test. Il compito di comprensione è stato completato correttamente.
Descrizione delle dipendenze. Gli strumenti di analisi statica producono grafici delle dipendenze, che mostrano quali programmi chiamano quali, quali copybook vengono condivisi e quali dataset vengono scambiati tra i programmi. L'intelligenza artificiale può generare una descrizione in linguaggio naturale a partire da questo grafico: "CUSTPROC viene chiamato da 14 programmi, principalmente nella finestra di elaborazione batch notturna. Condivide CUSTMSTR con 47 programmi e produce output per CUST-REPORT-FILE, che viene utilizzato dal flusso di lavoro di reporting normativo". Questa descrizione è più utile per l'onboarding e la revisione dell'architettura rispetto a un semplice grafico delle dipendenze, e l'intelligenza artificiale la genera in pochi secondi a partire dai dati strutturati sulle dipendenze.
Generazione di casi di test a partire dal comportamento compreso. Una volta che l'IA ha documentato il comportamento del programma, può generare casi di test che coprono i percorsi di esecuzione documentati. Questo non equivale a dimostrare l'equivalenza comportamentale: i casi di test coprono i percorsi compresi dall'IA, che potrebbero tralasciare percorsi non previsti. Tuttavia, coprire il 60% dei percorsi di esecuzione tramite test generati dall'IA è meglio dello zero percento di copertura che molti programmi legacy presentano attualmente e fornisce un punto di partenza per l'integrazione manuale dei test necessaria alla validazione dell'equivalenza comportamentale.
Riconoscimento di pattern in programmi simili. I grandi portfolio COBOL contengono spesso molti programmi strutturalmente simili, in cui lo stesso schema di elaborazione viene applicato a entità diverse, o lo stesso calcolo normativo viene parametrizzato in modo differente. L'intelligenza artificiale può identificare queste somiglianze in migliaia di programmi e raggrupparle per tipo di pattern, consentendo una strategia di migrazione che affronta ogni pattern una sola volta e applica la soluzione in modo sistematico, anziché trattare ogni programma come unico.
Il filo conduttore è il seguente: gli output della comprensione basata sull'IA sono testi, i testi sono revisionabili dagli esseri umani e la revisione umana individua gli errori prima che abbiano conseguenze tecniche. Il profilo di rischio della comprensione basata sull'IA è sufficientemente basso da rendere il valore che offre autentico e gli errori che commette gestibili.
Dove la traduzione automatica tramite IA promette più di quanto possa fare
La traduzione ha una caratteristica che la rende fondamentalmente più difficile per l'intelligenza artificiale rispetto alla comprensione: l'output è codice eseguibile, e il codice eseguibile deve essere assolutamente corretto. Una traduzione accurata al 95% produce un programma che fallisce per il 5% degli input, il che in un sistema di elaborazione delle transazioni finanziarie può tradursi in un errore di rendicontazione normativa, una discrepanza nel calcolo del saldo o una non conformità. Il costo degli errori di traduzione non è una correzione della documentazione, bensì un incidente di produzione.
Il problema di precisione numerica. L'aritmetica decimale compressa di COBOL (COMP-3) produce risultati decimali esatti. Java double e di Python float usa il formato a virgola mobile binario IEEE 754, che non può rappresentare esattamente la maggior parte delle frazioni decimali. Un programma COBOL che calcola 0.1 + 0.2 con COMP-3 produce esattamente 0.3. Lo stesso calcolo in Java con double produce 0.30000000000000004Per un istituto finanziario in cui questo calcolo viene eseguito 10 milioni di volte a notte per le presentazioni normative, l'errore accumulato non è una curiosità in virgola mobile, ma una discrepanza nella rendicontazione finanziaria. Una traduzione AI che genera Java senza gestire esplicitamente la mappatura COMP-3-to-BigDecimal introduce sistematicamente questo errore, e lo fa per ogni campo che l'AI traduce come double anziché BigDecimal.
La differenza nel codice è sottile; la conseguenza no:
cobolo
* COBOL: COMP-3 packed decimal -- exact arithmetic
77 UNIT-PRICE PIC S9(7)V99 COMP-3.
77 QUANTITY PIC S9(5) COMP-3.
77 LINE-TOTAL PIC S9(11)V99 COMP-3.
COMPUTE LINE-TOTAL = UNIT-PRICE * QUANTITY.
* UNIT-PRICE = 19.99, QUANTITY = 3
* LINE-TOTAL = exactly 59.97 -- no rounding error
Giava
// Java: naive AI translation uses double -- introduces error
double unitPrice = 19.99;
int quantity = 3;
double lineTotal = unitPrice * quantity;
// lineTotal = 59.96999999999999... not 59.97
// Correct translation requires BigDecimal:
// BigDecimal lineTotal = new BigDecimal("19.99").multiply(new BigDecimal(3));In una singola transazione l'errore è invisibile. Ma con 10 milioni di transazioni notturne, sommate in un report sul capitale regolamentare, si tratta di una discrepanza significativa. Una traduzione automatica basata sull'intelligenza artificiale che non si occupa esplicitamente dei campi COMP-3 effettuerà questa sostituzione ogni volta.
Dipendenza dalle opzioni del compilatore. Lo stesso codice sorgente COBOL può produrre comportamenti diversi a seconda delle opzioni del compilatore utilizzate. NUMPROC(MIG) e NUMPROC(NOPFD) modificano la gestione delle eccezioni numeriche. Le opzioni RMODE, AMODE e DATA influenzano l'indirizzamento. Un'intelligenza artificiale che traduce il codice sorgente COBOL senza conoscere le opzioni del compilatore in uso, traduce il codice sorgente del programma, non il suo comportamento. Il codice Java tradotto potrebbe corrispondere al codice sorgente, ma non al comportamento in produzione.
Il problema dell'allucinazione su larga scala. La ricerca mostra che i modelli di classe GPT-4 presentano tassi di allucinazione dal 33 al 60% nelle attività di traduzione di codice generiche, generando codice dall'aspetto plausibile che aggiunge o rimuove comportamenti non presenti nel codice sorgente. Per un programma con 847 condizioni EVALUATE, un tasso di allucinazione del 5% significa che circa 42 condizioni vengono tradotte in modo errato. Queste 42 condizioni rappresentano regole aziendali che la traduzione ha violato silenziosamente. Senza un corpus di test completo che verifichi ogni condizione, queste violazioni sono impercettibili fino a quando la specifica combinazione di input che le innesca non raggiunge l'ambiente di produzione.
La posta in gioco è nei numeri:
Error Type | Detection Point | Cost Range
--------------------|--------------------|------------------
Comprehension error | Human review | Hours to fix
Translation error | Test suite | Days to isolate
Translation error | Production | $10K-$500K+ incident
Equivalence gap | Regulatory audit | $50K-$5M+ penaltyL'asimmetria: gli errori di comprensione vengono individuati prima che abbiano conseguenze tecniche. Gli errori di traduzione, invece, sfuggono alla revisione e si manifestano in modo esplosivo in fase di produzione, o peggio, in fase di presentazione alle autorità di regolamentazione.
Il limite massimo della finestra di contesto. Watsonx Code Assistant di IBM per Z raggiunge un'accuratezza strutturale pari o superiore all'80% nella traduzione da COBOL a Java per singoli programmi all'interno di una finestra di contesto. Un portfolio COBOL di 5 milioni di righe è composto da migliaia di programmi, con dipendenze tra programmi che si estendono a programmi che non possono trovarsi tutti contemporaneamente nella stessa finestra di contesto. Un programma che chiama un sottoprogramma la cui interfaccia, tradotta dall'IA, differisce dalle ipotesi del programma chiamante, crea un'incongruenza di interfaccia che nessuna delle due traduzioni da sola sarebbe in grado di rivelare. La traduzione su scala di portfolio richiede una comprensione che abbracci i programmi, non solo i singoli programmi.
Il problema della traduzione senza contesto. Un programma COBOL che elabora uno specifico evento aziendale lo fa con un contesto incorporato nel sistema circostante: la pianificazione batch che ne determina l'esecuzione, i dataset che devono essere disponibili all'avvio, l'ordine in cui elabora i record, i programmi a valle che leggono il suo output prima di essere eseguiti. Un'intelligenza artificiale che traduce il programma senza comprenderne il contesto traduce il codice sorgente, ma non il ruolo. Il codice Java tradotto potrebbe essere internamente corretto, ma fallire comunque a livello operativo perché viene eseguito nel momento sbagliato, nell'ordine sbagliato e senza i prerequisiti di dati su cui si basava il suo predecessore COBOL.
Il divario di equivalenza comportamentale
Il problema più significativo che né l'IA di comprensione né l'IA di traduzione risolvono è la dimostrazione dell'equivalenza comportamentale, ovvero la dimostrazione che il sistema modernizzato produce gli stessi output del sistema precedente per tutti gli input rilevanti per l'azienda e i suoi enti regolatori.
L'equivalenza comportamentale non è un problema di test nel senso tradizionale del termine. Non si tratta di chiedersi "il nuovo sistema supera la suite di test?", perché la suite di test per un sistema COBOL legacy spesso non esiste o copre solo una frazione dei percorsi di esecuzione contenuti nel programma. La domanda è piuttosto: per ogni input che il sistema di produzione ha mai ricevuto, il sistema modernizzato produce lo stesso output? E per ogni input che il sistema di produzione potrebbe ricevere in futuro, inclusi i casi limite che si verificano solo in rare condizioni di mercato, periodi di rendicontazione normativa o circostanze specifiche del cliente, il sistema modernizzato produce il risultato equivalente?
Per rispondere a questa domanda sono necessari: una caratterizzazione del comportamento del sistema esistente derivata dall'effettiva esecuzione in produzione (non dalla documentazione, non solo dal codice sorgente), un corpus di test che metta alla prova l'intera gamma di tale comportamento e un framework di confronto in grado di stabilire cosa significhi "equivalente" per output in cui la rappresentazione differisce (EBCDIC vs UTF-8, decimale compresso vs BigDecimal, file batch vs record di database).
Nessuno di questi aspetti è offerto dagli strumenti di traduzione basati sull'IA. La valutazione di IBM è chiara: la traduzione non coglie quasi per nulla la reale complessità della modernizzazione. Il lavoro di equivalenza comportamentale, l'esecuzione in parallelo, il quadro di riconciliazione, l'approvazione normativa: è qui che si concentrano i costi e i rischi, ed è qui che l'IA incide meno sul costo totale del programma. L'IA comprime la fase iniziale del progetto di modernizzazione: la comprensione e la traduzione iniziale. Non comprime la fase finale: la verifica, i test di equivalenza e la convalida in parallelo.
Il modello corretto: fondamenti di analisi statica, livello semantico di intelligenza artificiale
La capacità di comprensione più efficace dell'IA non è data dall'IA stessa, ma dall'IA che opera su una base strutturale fornita dall'analisi statica. I limiti della comprensione dell'IA (limiti della finestra di contesto, incertezze sulla logica complessa tra programmi, analisi probabilistica anziché deterministica) vengono superati dall'analisi statica. I limiti dell'analisi statica (produce fatti strutturali ma non descrizioni semantiche) vengono superati dall'IA.
La giusta divisione del lavoro: l'analisi statica fornisce certezza strutturale (deterministica, completa, senza allucinazioni). L'intelligenza artificiale fornisce ricchezza semantica (descrizioni in linguaggio naturale, riconoscimento di modelli, generazione di test). Nessuna delle due da sola è sufficiente. Insieme coprono l'intero requisito di comprensione.
Le basi strutturali fornite dall'analisi statica:
Inventario completo dei programmi. Ogni programma nel portfolio, inclusi quelli non presenti nella documentazione e quelli che la finestra di contesto dell'IA non potrebbe mai gestire simultaneamente. L'analisi statica elabora l'intero portfolio senza limitazioni di contesto.
Grafico delle dipendenze accurato. Ogni relazione CALL, ogni relazione COPY, ogni flusso di dati tra programmi, derivato in modo deterministico dal codice sorgente, non probabilisticamente dai dati di addestramento. Quando uno strumento di comprensione basato sull'IA descrive le dipendenze di un programma, tale descrizione dovrebbe essere fondata su un grafico delle dipendenze prodotto da un'analisi statica, non sulla capacità dell'IA di ricordare in modo probabilistico da cosa dipendono tipicamente i programmi.
Identificazione del codice morto. I programmi irraggiungibili da qualsiasi percorso di esecuzione in produzione non rientrano nell'ambito della modernizzazione. L'analisi statica li identifica con certezza; l'IA non può farlo, perché non dispone delle tracce di esecuzione in tempo reale necessarie per distinguere il codice attivo dal codice morto tramite la sola analisi statica.
Inventario degli schemi dati. Ogni voce FD, ogni copybook, ogni campo COMP-3 con la relativa specifica di precisione, estratto dagli artefatti sorgente anziché ricostruito dalla memoria dei dati di addestramento dell'IA su come appaiono tipicamente le definizioni dei campi COBOL.
Su questa base strutturale, la comprensione basata sull'IA aggiunge il livello semantico: le descrizioni in linguaggio naturale di ciò che fa ciascun programma, la documentazione delle regole aziendali, la narrazione dei flussi di dati tra i programmi e il riconoscimento di pattern che raggruppa programmi simili. Questa combinazione, l'accuratezza strutturale deterministica derivante dall'analisi statica e la ricchezza semantica in linguaggio naturale fornita dall'IA, è il modello che produce risultati di comprensione su cui un team di modernizzazione può effettivamente fare affidamento.
Cosa significa questo per il tuo programma di modernizzazione
Allocazione pratica degli investimenti in IA sulla base di questa analisi:
Investite nella comprensione dell'IA. Generazione di documentazione, estrazione di regole aziendali, analisi delle dipendenze, generazione di casi di test a partire da comportamenti documentati: questi sono utilizzi dell'IA ad alto valore e a basso rischio che comprimono la fase più costosa e tradizionalmente manuale della modernizzazione. Eseguite prima questi passaggi, prima della traduzione, perché la comprensione influenza ogni decisione successiva.
Utilizzate la traduzione automatica tramite IA come generatore di bozze, non come strumento di finalizzazione. La traduzione automatica produce un punto di partenza in Java o Python che uno sviluppatore deve rivedere, correggere e convalidare, non un codice pronto per la produzione che può essere distribuito senza revisione umana. Trattare l'output della traduzione automatica come una bozza riduce i costi di traduzione, mantenendo al contempo la responsabilità umana necessaria per la convalida dell'equivalenza.
Non bisogna conteggiare i risparmi derivanti dalla traduzione automatica tramite IA nei costi di verifica. L'IA riduce i tempi di produzione di un programma tradotto, ma non quelli necessari per dimostrare che il programma tradotto è equivalente all'originale. È opportuno pianificare la fase di verifica indipendentemente dai risparmi derivanti dalla traduzione automatica tramite IA, poiché l'ambito della verifica non si riduce con l'aumentare della velocità di traduzione.
Prima di tutto, è fondamentale costruire le fondamenta strutturali. Gli strumenti di comprensione basati sull'IA che non dispongono di una solida base strutturale, di un grafico delle dipendenze accurato, di un inventario completo dei programmi e di uno schema dati esaustivo, producono una comprensione incompleta laddove il codice è più complesso. I programmi che necessitano maggiormente della comprensione da parte dell'IA sono in genere i più complessi, quelli con maggiori dipendenze tra programmi diversi e quelli che più probabilmente superano le capacità di analisi accurate dell'IA a partire dal solo codice sorgente.
Come SMART TS XL Supporta la comprensione COBOL potenziata dall'intelligenza artificiale
SMART TS XL Fornisce le basi di analisi strutturale che rendono la comprensione da parte dell'IA dei portfolio COBOL accurata anziché probabilistica.
La capacità di analisi statica del codice produce i dati strutturali a livello di programma necessari agli strumenti di comprensione dell'IA: ogni condizione EVALUATE enumerata, ogni formula COMPUTE estratta, ogni schema di accesso ai dati caratterizzato. Quando gli strumenti di documentazione basati sull'IA operano sul codice sorgente con questi dati strutturali come contesto, producono descrizioni basate su ciò che il codice effettivamente contiene, piuttosto che su ciò che programmi dall'aspetto simile fanno tipicamente.
La mappatura delle dipendenze tra applicazioni fornisce il contesto inter-programma che le finestre di contesto dell'IA non possono gestire simultaneamente. Un grafico delle dipendenze che mostra i 14 chiamanti di CUSTPROC, i suoi 47 condivisioni di copybook e i suoi 3 output di flusso di dati offre agli strumenti di comprensione dell'IA un quadro completo del ruolo di un programma nel portfolio, senza richiedere che ogni programma dipendente si trovi nella stessa finestra di contesto contemporaneamente.
L' analisi di modernizzazione dei sistemi legacy produce l'inventario del codice obsoleto e la distribuzione della complessità che la comprensione basata sull'IA da sola non può produrre in modo affidabile: quali programmi sono irraggiungibili dall'ambiente di produzione (esclusi dall'ambito di applicazione), quali programmi presentano la complessità più elevata (dove gli errori di comprensione sono più costosi) e come si presenta l'ambito della migrazione dei dati derivato dalle effettive voci delle dipendenze funzionali anziché dalla documentazione.
La funzionalità di ricerca aziendale rende l'inventario strutturale interrogabile a supporto della comprensione assistita dall'IA: trova ogni programma che implementa uno schema specifico, ogni blocco EVALUATE con più di N condizioni, ogni programma che accede a un dataset specifico, query che basano la comprensione dell'IA su evidenze strutturali piuttosto che sulla probabilità dei dati di addestramento.
Per le organizzazioni in cui l'IA è ormai parte della catena di strumenti di modernizzazione, SMART TS XLL'analisi strutturale è lo strato che rende accurata la comprensione dell'IA su scala di portfolio, affrontando il limite della finestra di contesto, il rischio di allucinazione sulla logica inter-programma e il divario di determinismo che separa l'analisi strutturale dalla generazione probabilistica.
L'intelligenza artificiale ha cambiato il costo della comprensione, non il costo della dimostrazione.
Ciò che è cambiato nel 2026 è il costo della comprensione. L'intelligenza artificiale ha reso drasticamente più economico e veloce capire cosa fa un programma COBOL, documentarne le regole aziendali, caratterizzarne il comportamento e descriverne il ruolo nel portfolio. Questo rappresenta un contributo reale e sostanziale all'economia della modernizzazione. Per i programmi per i quali la fase di comprensione richiedeva in precedenza settimane di lavoro specialistico, l'IA può produrre una bozza di comprensione in poche ore, che gli specialisti possono poi rivedere e perfezionare, anziché doverla costruire da zero.
Ciò che non è cambiato è il costo della dimostrazione. La convalida dell'equivalenza comportamentale, l'esecuzione in parallelo, l'approvazione normativa, la verifica della migrazione dei dati, rimangono invariate rispetto a prima dell'IA, consumando dal 40 al 50 percento del budget di modernizzazione, indipendentemente dalla velocità con cui si completano le fasi di comprensione e traduzione. IBM aveva ragione il 23 febbraio 2026: la traduzione non coglie quasi per nulla la reale complessità. La vera complessità risiede nella verifica dell'equivalenza comportamentale, e tale complessità non si riduce con l'aumentare della velocità di traduzione.
Le organizzazioni che utilizzano efficacemente l'IA nella modernizzazione del COBOL sono quelle che investono nella comprensione basata sull'IA, laddove l'IA eccelle davvero, e considerano la traduzione automatica come un punto di partenza per la revisione umana, piuttosto che come un prodotto finito pronto per l'implementazione. Comprendono che ridurre i costi nella fase iniziale del progetto non significa ridurre i costi nella fase finale. E costruiscono le solide basi di analisi strutturale necessarie affinché la comprensione basata sull'IA sia accurata a livello di portfolio, dove si svolge il lavoro di comprensione più importante.
