IBM -10% dopo l’annuncio: il punto non è “COBOL è morto”

Un titolo che scende del 10% in un giorno fa rumore, ma il segnale interessante non è “IBM perde perché arriva l’AI”. Il segnale è: il mercato sta prezzando un possibile spostamento di potere nella modernizzazione del mainframe.

Le notizie circolate su più testate indicano che Anthropic ha posizionato Claude Code come strumento particolarmente adatto a lavorare su codice legacy, incluso COBOL. Nella narrazione: un assistente AI capace di leggere, spiegare, refactorare e supportare migrazioni/modernizzazioni dove oggi molte aziende dipendono da consulenze costose, skill rare e processi lenti.

Se hai sistemi COBOL in produzione (banche, assicurazioni, PA, retail, logistica), la domanda reale è molto più pragmatica: l’AI può ridurre tempi e rischio su attività che oggi bloccano roadmap e budget? E se sì, chi cattura quel valore: chi vende infrastruttura (IBM), chi vende tool AI (Anthropic), o chi integra e governa la trasformazione (system integrator / team interno)?

Perché un tool AI per COBOL può spaventare IBM (ma non per i motivi “da social”)

IBM non “vive di COBOL” in senso stretto. Vive di ecosistemi: mainframe, licensing, servizi, strumenti enterprise, partnership. Il COBOL è uno dei pilastri culturali e operativi che tengono in vita enormi installazioni. Quando un attore esterno dice: “posso abbassare drasticamente la barriera di ingresso sul legacy”, sta attaccando tre leve:

Riduzione del lock-in operativo

Se un team riesce a:

  • capire meglio il codice,
  • scrivere test,
  • documentare automaticamente,
  • trasformare moduli in servizi,
  • migrare incrementale,

…il costo di cambiare piattaforma (o almeno di rinegoziare contratti) può scendere. Anche solo la percezione di questo rischio basta a muovere i mercati.

Compressione dei margini su servizi e consulenza

Molta spesa “legacy” è lavoro umano: analisi di impatto, reverse engineering, remediation, test plan. Se l’AI automatizza anche solo il 20–30% delle attività ripetitive, il valore si sposta verso chi controlla la pipeline e i dati (prompt, policy, modelli), non necessariamente verso chi controlla l’hardware.

Cambio di narrativa: dal “mainframe come fortezza” al “mainframe come codice trasformabile”

Il mainframe è spesso percepito come solido ma opaco. Un assistente AI che rende leggibile e manipolabile quel codice riduce l’opacità. E quando l’opacità diminuisce, aumenta la competizione.

La realtà tecnica del COBOL + AI: dove funziona e dove no

Se ti aspetti “premi un bottone e migri tutto in Java”, stai impostando il progetto per fallire. Un assistente AI può aiutare tantissimo, ma solo se lo metti dentro un processo.

Dove l’AI rende subito

  1. Spiegazione e onboarding: comprendere moduli, copybook, flow e dipendenze.
  2. Documentazione: generare descrizioni funzionali, diagrammi, data flow, glossari.
  3. Refactoring sicuro (micro): rinominare, isolare routine, estrarre funzioni.
  4. Test scaffolding: creare harness, casi di test, dataset sintetici (con attenzione).
  5. Analisi impatto: “se tocco X, quali programmi / file / job potrebbero rompersi?”

Dove devi alzare le difese

  1. Logica di business implicita: regole non documentate, eccezioni “storiche”.
  2. Dipendenze batch/JCL e scheduling: flussi notturni, finestre, rollback.
  3. Dati e formati: EBCDIC/ASCII, packed decimal, record fixed-length, file VSAM.
  4. Compliance e segreti: non puoi “mandare al modello” dati sensibili senza governance.

In pratica: l’AI accelera, ma non sostituisce l’ingegneria del rischio.

Se hai COBOL in azienda: una strategia pratica in 4 fasi

1) Inventario e classificazione (prima di “fare prompt”)

Devi sapere cosa hai:

  • programmi e chiamate,
  • copybook e definizioni record,
  • batch job e dipendenze,
  • accesso a DB/file,
  • criticità (core banking? billing? reporting?).

Obiettivo: una mappa, non perfetta, ma sufficiente per decidere dove intervenire.

2) Mettere l’AI in una pipeline controllata

L’errore tipico è usare l’assistente come “chat”. Quello che serve è una pipeline che:

  • recuperi contesto (RAG) dai repository interni,
  • applichi policy (redaction, allowlist, log),
  • produca output verificabili (diff, test, report).

Esempio minimale di approccio “tool-driven”: indicizza sorgenti e copybook, poi chiedi all’AI di generare un report di impatto e un set di test.

3) Migrazione/modernizzazione incrementale

Le strade realistiche sono tre:

  • Encapsulation: esponi funzioni COBOL via API (senza riscrivere subito).
  • Strangler pattern: sostituisci pezzi uno alla volta.
  • Replatform: sposti runtime/compilazione altrove (più delicato, spesso vendor-specific).

Scegli in base a rischio e ROI, non in base alla moda del momento.

4) Verifica: test, test, test (e ancora test)

Se l’AI produce codice, la domanda non è “è elegante?” ma “è equivalente?”.

Servono:

  • golden files,
  • test di regressione su dataset reali (anonimizzati),
  • confronti output batch,
  • monitoraggio in produzione (canary, shadow run).

Un esempio concreto: usare l’AI per spiegare un modulo COBOL e generare test

Sotto trovi un esempio “scheletro” che mostra come orchestrare:

1) recupero del contesto dal repo, 2) richiesta strutturata al modello, 3) generazione di output verificabile.

Orchestrazione (Node.js) con prompt strutturato

import fs from "node:fs";
import path from "node:path";

function loadCobolModule(modulePath) {
  const code = fs.readFileSync(modulePath, "utf8");
  return code;
}

function buildPrompt({ code, copybooks }) {
  return `Sei un assistente per modernizzazione COBOL.

OBIETTIVO:
1) Spiega cosa fa il programma in linguaggio funzionale.
2) Elenca input/output (file, record, campi chiave) e side effects.
3) Evidenzia regole di business e punti a rischio.
4) Proponi una suite di test (almeno 10 casi) con dati di esempio.

VINCOLI:
- Non inventare dipendenze non presenti.
- Se mancano informazioni, elenca cosa serve.
- Output in JSON con chiavi: summary, io, rules, risks, tests.

CODICE COBOL:
${code}

COPYBOOKS (se presenti):
${copybooks.join("\n\n")}
`;
}

// Demo: in reale sostituisci questa funzione con la chiamata al provider (Anthropic/OpenAI/on-prem)
async function callModel(prompt) {
  // return await anthropic.messages.create(...)
  throw new Error("Implementa la chiamata al tuo modello qui");
}

async function main() {
  const code = loadCobolModule(path.resolve("./src/LEGACY01.cbl"));
  const copybooks = [
    fs.readFileSync(path.resolve("./copybooks/CUSTREC.cpy"), "utf8")
  ];

  const prompt = buildPrompt({ code, copybooks });
  const result = await callModel(prompt);
  console.log(result);
}

main().catch(console.error);

Punti chiave:

  • Output JSON: costringe il modello a essere verificabile e “diffabile”.
  • Copybook incluso: senza definizioni record, l’AI improvvisa.
  • Non è magia: il valore sta nell’automazione ripetibile e auditabile.

Impatto per team e clienti: cosa fare nelle prossime 2–4 settimane

Se lavori in un’azienda con sistemi legacy, l’azione utile non è “scegliere subito un vendor”. È creare un esperimento a basso rischio che risponde a tre domande.

1) L’AI migliora la comprensione del codice?

Metriche pratiche:

  • tempo per onboarding su un modulo,
  • numero di bug “da incomprensione” ridotto,
  • qualità della documentazione generata (review da senior).

2) L’AI riduce il lead time su change request?

Prova su un task reale:

  • change piccolo (es. nuova regola tariffaria),
  • con test e confronto output,
  • misurando ore/uomo prima e dopo.

3) La governance è sostenibile?

Checklist minima:

  • dove finiscono i sorgenti e i dati (cloud vs on-prem),
  • logging e audit,
  • policy per segreti e PII,
  • diritto d’autore/licenze su codice e output.

Cosa significa il “caso IBM” per chi sviluppa e per chi compra software

Non è una sentenza sul mainframe. È un promemoria:

  • Il vantaggio competitivo non è “avere COBOL”, è saperlo cambiare senza rompere.
  • L’AI sposta valore verso chi controlla tooling, processi e test.
  • Chi investe in modernizzazione incrementale (API, osservabilità, test harness) si mette in posizione di forza, indipendentemente dal vendor.

Takeaway pratici

  • Se hai COBOL: parti da inventario + test prima di pensare alla migrazione.
  • Usa l’AI come acceleratore di comprensione, documentazione e scaffolding, non come sostituto dell’analisi.
  • Progetta output verificabili (JSON, diff, golden tests), altrimenti stai solo “chattando”.
  • Valuta i vendor su governance e integrazione: sicurezza, audit, integrazione CI/CD, gestione contesto.

Il -10% di IBM è una storia di percezione e di potere nella toolchain. Per chi costruisce software, è soprattutto un invito a rendere il legacy meno misterioso e più testabile: è lì che l’AI dà valore reale.