Se gestisci sistemi legacy, la notizia che L’AI di Anthropic scrive software in COBOL non è una curiosità folkloristica. È un segnale concreto per banche, assicurazioni, pubblica amministrazione e grandi aziende che ancora dipendono da applicazioni centrali scritte decenni fa, spesso stabili ma difficili da mantenere perché i profili esperti sono pochi, costosi e vicini alla pensione.
Il punto non è se il COBOL sia “vecchio”. Il punto è che continua a far girare processi critici: contabilità, pagamenti, gestione polizze, pensioni, anagrafiche, reportistica batch. Quando un modello AI inizia a produrre codice in questo linguaggio con un livello utile, la domanda giusta diventa un’altra: dove può davvero aiutare e dove invece rischia di fare danni invisibili fino al momento peggiore?
Perché il COBOL conta ancora davvero
Per molti utenti il COBOL appartiene ai musei dell’informatica. Per molti reparti IT enterprise, invece, è ancora produzione viva. Non perché manchino alternative moderne, ma perché riscrivere da zero un sistema core è costoso, lungo e ad alto rischio. In diversi casi il software legacy incorpora decenni di regole di business che non sono documentate bene altrove.
Qui entra in gioco il valore potenziale dell’AI. Se un modello riesce a leggere programmi COBOL, spiegarli, proporre modifiche mirate e generare porzioni di codice coerenti, può ridurre uno dei problemi più seri del legacy: la dipendenza da poche persone che conoscono davvero il sistema. Non sostituisce l’analista esperto, ma può alleggerire attività che oggi richiedono molto tempo, come orientarsi tra file copybook, procedure batch, mappe dati e integrazioni con database o mainframe.
Cosa significa che l’AI di Anthropic scrive software in COBOL
La formulazione va letta con precisione. Non significa che l’AI può prendere in carico da sola una piattaforma bancaria e rilasciare in produzione senza supervisione. Significa, più realisticamente, che un modello moderno è in grado di generare, trasformare e spiegare codice COBOL abbastanza bene da diventare uno strumento operativo in certi flussi di lavoro.
Questo cambia il quadro in almeno tre aree. La prima è la manutenzione correttiva: bugfix circoscritti, soprattutto se il contesto applicativo è ben descritto. La seconda è la manutenzione evolutiva: adeguare report, campi, controlli e regole semplici. La terza è la documentazione tecnica, che spesso nei sistemi legacy è il collo di bottiglia più grave. Un assistente AI può descrivere moduli, individuare dipendenze e rendere più leggibile codice che oggi capiscono in pochi.
Per un responsabile IT, però, la vera notizia non è “sa scrivere COBOL”. La vera notizia è che il costo cognitivo del legacy potrebbe abbassarsi. E questo incide su tempi, rischio operativo e continuità del servizio.
Dove può aiutare sul serio
Il caso d’uso più credibile non è la generazione di interi sistemi da zero. È il supporto controllato alle attività ripetitive e ad alta frizione. Per esempio, l’AI può accelerare la lettura di programmi lunghi, evidenziare variabili chiave, suggerire l’effetto di una modifica su sezioni correlate e proporre casi di test da validare.
In ambienti dove il COBOL convive con JCL, CICS, DB2 o file system storici, il vantaggio maggiore è spesso nella fase di analisi, non nella scrittura pura. Se un team può chiedere: “quali moduli usano questo campo?” oppure “cosa succede se allarghiamo questa struttura dati?”, ottiene una prima risposta in minuti invece che in ore. Questo non elimina la verifica manuale, ma migliora la produttività in modo concreto.
C’è poi un’altra utilità meno vistosa ma molto importante: l’onboarding. Un tecnico esperto di Java, Python o SQL che deve mettere mano a un sistema COBOL può usare l’AI come supporto interpretativo. In pratica, il modello diventa un traduttore tra stili di programmazione e paradigmi lontani. Per le PMI e per i team con personale misto, questo può fare la differenza.
I limiti che non vanno ignorati
Il rischio più pericoloso non è l’errore evidente. È il codice plausibile ma sbagliato. Nei linguaggi legacy questo problema pesa di più perché molte applicazioni hanno logiche implicite, naming incoerente e dipendenze esterne non documentate. Un modello può generare COBOL sintatticamente corretto ma incompatibile con standard interni, convenzioni locali o flussi batch specifici.
C’è poi il tema del contesto incompleto. Se l’AI vede solo un programma ma non i copybook, le strutture dati condivise, il job scheduler o i vincoli di produzione, le sue proposte possono essere fuorvianti. Il rischio aumenta ancora quando si lavora su sistemi con requisiti normativi, audit trail, controlli di quadratura o integrazioni finanziarie.
Per questo l’uso utile dell’AI non è “scrivi e distribuisci”, ma “proponi, spiega, confronta, documenta e fai validare”. In un ambiente serio, qualsiasi output deve passare per code review, test funzionali, test di regressione e controlli di conformità. Se manca questa disciplina, l’AI accorcia i tempi all’inizio e li moltiplica dopo.
Anthropic, COBOL e manutenzione legacy: cosa cambia per i team IT
Se guardiamo oltre il titolo, la novità è culturale prima ancora che tecnica. Per anni il discorso sul legacy è stato binario: o tieni in vita il vecchio sistema, o finanzi una migrazione enorme. L’arrivo di strumenti AI più capaci apre una terza strada: migliorare la gestibilità del legacy mentre si pianifica con più calma la modernizzazione.
Questo approccio è utile soprattutto dove i sistemi non possono essere fermati. Un team può usare l’AI per mappare il patrimonio applicativo, ridurre la dipendenza dalla memoria individuale e preparare una roadmap di refactoring o di estrazione graduale delle funzioni. In altre parole, il COBOL non smette di essere legacy, ma diventa meno opaco.
Per chi lavora nel supporto tecnico o nella governance IT, questo significa anche un cambiamento nelle competenze richieste. Non serve solo conoscere il linguaggio. Serve saper porre domande corrette al modello, delimitare il contesto, verificare output e riconoscere quando la risposta è elegante ma pericolosa. È una forma di supervisione tecnica, non un semplice uso passivo dello strumento.
Quando conviene usarla e quando no
Conviene usarla se hai un perimetro chiaro, test disponibili e una persona che conosce il dominio di business. Conviene anche nelle attività di analisi impattate da carenza di competenze interne, o quando devi produrre documentazione tecnica per sistemi che nessuno ha mai spiegato bene.
Conviene molto meno se il sistema è scarsamente testabile, se contiene eccezioni operative non formalizzate oppure se il contesto applicativo è così frammentato da rendere ogni modifica imprevedibile. In questi casi l’AI può dare una falsa sensazione di controllo. E nel software che gestisce denaro, identità o processi pubblici, la falsa sicurezza è un problema serio.
Un altro punto pratico riguarda i dati. Caricare codice sorgente o documentazione sensibile in strumenti AI senza una policy chiara è un errore. Prima di adottare soluzioni di questo tipo servono regole su riservatezza, segregazione degli ambienti, retention dei prompt e trattamento dei dati. La convenienza tecnica non può scavalcare sicurezza e compliance.
Cosa deve fare un’azienda prima di provarla
La tentazione è iniziare subito chiedendo al modello di “migliorare” un programma storico. È il modo meno utile per partire. La strada migliore è scegliere un caso circoscritto: un report batch, una procedura non critica, un modulo ben compreso dal team. Da lì si misura la qualità dell’output, il tempo risparmiato e il numero di correzioni necessarie.
Vale anche la pena definire un processo semplice ma rigoroso. Prompt standardizzati, revisione umana obbligatoria, confronto con il codice esistente, test su ambiente isolato e tracciamento delle modifiche. Se questi passaggi sembrano eccessivi, probabilmente il contesto non è pronto per usare bene l’AI su software legacy.
Per molte organizzazioni il primo guadagno non arriverà nemmeno dalla generazione di codice. Arriverà dalla capacità di spiegare il codice che già esiste. Ed è già un risultato notevole, perché riduce il rischio di dipendenza da singoli specialisti e rende più ordinata qualsiasi futura migrazione.
Quello che conta davvero per chi segue il tema
L’AI di Anthropic scrive software in COBOL, sì, ma il valore reale non sta nell’effetto sorpresa. Sta nel fatto che il software storico, per anni trattato come un blocco impenetrabile, inizia a diventare più leggibile, interrogabile e forse più gestibile. Questo interessa meno chi cerca l’ennesima demo spettacolare e molto di più chi deve tenere accesi sistemi critici ogni giorno.
Per gli utenti business la ricaduta pratica può essere indiretta ma importante: tempi di manutenzione più brevi, meno colli di bottiglia su competenze rare, migliore continuità operativa. Per i team tecnici, invece, il messaggio è più sobrio: l’AI può aiutare molto, ma solo dentro un processo disciplinato. Sul legacy, l’entusiasmo senza verifica costa più del ritardo nell’adozione.
Chi lavora con sistemi storici non ha bisogno di slogan. Ha bisogno di strumenti che riducano il rischio senza creare nuovi problemi. Se questa tecnologia manterrà la promessa, il vero progresso non sarà “far scrivere COBOL a un modello”, ma restituire controllo a chi oggi gestisce infrastrutture troppo importanti per essere capite da troppo poche persone.
