Analysis ·

COBOL Modernization with AI: What Anthropic’s Model Writing 60-Year-Old Code Really Changes

AI now reads and writes legacy COBOL. The impact is economic and architectural, not code replacement. Where it helps and where risk lives.

Mario Noioso
A printed code listing with an amber reading beam from a model turning lines amber

Illustration by the author.

For decades, COBOL modernisation has been one of the most expensive and fragile transformation programmes in enterprise IT. Not because COBOL is mysterious, and not because the code is unreadable, but because business logic is fossilised inside millions of lines of production code that still run banks, insurers, governments and payment rails. Anthropic’s latest move changes part of this equation. Not all of it, and the distinction matters. The new generation of AI coding systems can generate COBOL, explain legacy programs, assist in translating them to modern languages and accelerate the documentation of flows nobody remembers. That is real progress. It is not magic.

Why COBOL modernisation has always been hard

Enterprises rarely struggle with syntax. They struggle with semantic archaeology. A typical mainframe estate contains decades of incremental patches, undocumented business rules, batch dependencies, hidden data contracts and copybooks reused across hundreds of programs. COBOL systems are not codebases; they are living business organisms. Any modernisation effort must answer three questions: what does the code do, what business rule does it implement, and what can safely change. AI helps primarily with the first, partially with the second and very little with the third. That boundary is the one most headlines ignore.

What actually changed

The breakthrough is not that AI can write COBOL; that has been technically possible for a while. The shift is that modern models can parse large legacy files coherently, maintain context across copybooks, generate structurally valid COBOL, produce readable explanations of batch logic and assist in refactoring loops and file handling. In practical terms this reduces time-to-understanding, which has always been the most expensive phase of modernisation. We are moving from human archaeology to machine-assisted archaeology. The ruins are still there; the brush is just faster.

Consider a simplified legacy snippet:

IDENTIFICATION DIVISION.
PROGRAM-ID. CALC-PREMIUM.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-AGE            PIC 9(03).
01 WS-PREMIUM        PIC 9(05)V99.

PROCEDURE DIVISION.
    IF WS-AGE > 60
        COMPUTE WS-PREMIUM = WS-PREMIUM * 1.20
    END-IF.

A junior engineer who has never seen COBOL may stall here. A modern model explains it immediately: the input is the customer’s age, the business rule is a senior surcharge, the output is the adjusted premium. Multiplied across a large estate, that alone cuts weeks from discovery. The same model can carry the logic into a modern service:

function calculatePremium(age, premium) {
  if (age > 60) {
    return premium * 1.2;
  }
  return premium;
}

What the model is really doing is three cognitive steps: pattern recognition, identifying the conditional surcharge; semantic mapping, understanding the numeric manipulation and its intent; and target-language synthesis, rebuilding the logic in a new runtime model. That pipeline is the real engine of AI-driven modernisation.

AI-assisted COBOL modernisation

The misconception moving markets

Recent market reactions suggest a narrative in which AI replaces COBOL overnight. That is optimistic. In real enterprise environments the hardest problems are batch window dependencies, JCL orchestration, VSAM data coupling, transaction integrity, regulatory validation and decades of edge cases. AI accelerates code comprehension. It does not automatically solve system migration risk, and enterprises that confuse the two will pay for it later.

The near-term return is nonetheless real, and strongest in four areas. Legacy documentation, because many COBOL estates have near-zero documentation and AI can reconstruct it quickly. Impact analysis, understanding which programs touch which data fields. Test case generation, building regression suites from legacy flows. And developer onboarding, lowering the cognitive barrier for engineers who were born after the code was written. These are not small wins: they attack the most expensive phases of a modernisation programme.

Where caution is still required

Even the best models today struggle with deeply stateful batch ecosystems, cross-program side effects, copybook explosion, performance parity validation and regulatory-grade equivalence. In regulated sectors such as banking and public administration, functional equivalence is not enough. You need deterministic validation, auditability, reproducibility and lineage tracking. AI has to operate inside a governed modernisation factory, not as a free-form translator.

The winning pattern for enterprise architects is therefore emerging clearly, and it is not “AI replaces COBOL”. It is “AI compresses the discovery and translation phases of legacy modernisation”. The organisations that move fastest will combine AI-assisted code understanding with incremental strangler patterns, event-driven decomposition, modern data platforms and strong data lineage. In that architecture AI is an accelerator embedded in the factory, not the factory itself.

COBOL is not disappearing tomorrow; the installed base is too large and too critical. What is changing is the economics of understanding it. Anthropic’s move matters because it lowers one of the highest historical barriers, the human cost of legacy comprehension. But modernisation remains a systems problem, not just a coding problem. The enterprises that succeed in the next decade will treat AI as a precision instrument inside a disciplined transformation strategy. Everyone else risks generating very modern, very wrong systems, and legacy, as history keeps reminding us, is extremely unforgiving.

The practical questions, answered

These are the questions architects and CIOs actually ask once the headline fades. Short answers, from someone who has sat on the mainframe side of the table.

Can AI write COBOL code?

Yes, and it has been able to for a while. Current frontier models generate syntactically valid COBOL, respect divisions and PICTURE clauses, handle copybooks and produce code that compiles on IBM Enterprise COBOL or GnuCOBOL with minor fixes. What they cannot do is know your batch windows, your VSAM layouts or the undocumented rule a developer added in 1997 to satisfy an auditor. Writing new COBOL is the easy part; the value is in reading the old COBOL, and that is where the models have become useful.

How can AI help us understand decades-old COBOL and CICS applications before modernization?

Four concrete jobs, in the order I would run them. Program-level explanation: feed each program with its copybooks and get a plain-language description of inputs, outputs and business rules, then have a domain expert correct it; the corrected version becomes your documentation. Dependency mapping: extract which programs read and write which files, DB2 tables and CICS transactions, so you can see the real coupling instead of the one on the 2009 architecture diagram. Business-rule extraction: isolate the conditional logic that encodes policy (surcharges, eligibility, rounding) into a rules inventory that the business can validate. Test harvesting: derive regression cases from existing batch inputs and outputs before anything is touched. None of this changes production. All of it changes how much you know before you do.

What are the best AI tools for COBOL modernization?

There are three families and most serious programmes use two of them. General coding agents built on frontier models, such as Claude Code, which excel at explanation, documentation and translation of individual programs and can be pointed at a whole repository. Mainframe-vendor assistants, such as IBM watsonx Code Assistant for Z, which understand z/OS context, JCL and COBOL-to-Java refactoring inside the IBM toolchain. Migration platforms from cloud and ISV vendors, such as AWS Mainframe Modernization and the Rocket Software toolchain, which handle the industrial side: replatforming, data migration, dual-run testing. Evaluate them on one question: does the tool produce artifacts your auditors can read, not just code that runs.

How much does AI-assisted COBOL modernization cost, and where does it save?

Model usage is a rounding error in a modernisation budget. The saving is in people-time during discovery and documentation, historically the largest and least predictable cost driver, because nobody knows how long it takes to understand a system nobody understands. AI compresses that phase and makes it estimable. It does not reduce the cost of testing, cut-over, data migration or regulatory validation, and anyone pricing a programme as if it did is pricing the easy half. A fair model is: discovery and documentation shrink materially, translation shrinks somewhat, everything after translation costs what it always cost.

Can we run AI COBOL modernization in-house, privately, without sending code to a public API?

Yes, and for banks, insurers and public administrations it is usually the only acceptable option, because COBOL source is a map of the business and often of personal data structures. The patterns are the same ones used for sovereign AI elsewhere: models hosted in a private cloud or on-premises under the organisation’s jurisdiction, no training on customer prompts, code and copybooks never leaving the controlled perimeter, and a governed pipeline where every AI output is reviewed and logged before it enters a repository. The capability gap between a privately hosted model and the public frontier is real but shrinking, and for explanation and documentation tasks it is already small enough not to matter.

AI agents versus human developers for COBOL modernization: who does what?

Agents read, explain, draft and translate at a speed no team can match. Humans decide what the system must keep doing, validate equivalence, own the cut-over and sign the risk. The mistake is to staff the programme as if the agent were a cheaper developer; it is a faster analyst. The teams getting results pair one experienced mainframe engineer with agent tooling and a modern-platform engineer, and measure the agent on documented programs per week and defects found in review, not on lines of code generated.

Where does the data go when the COBOL leaves?

This is the question the AI headlines skip and the one that decides whether the programme succeeds. COBOL logic is inseparable from its record layouts: fixed-width copybooks, redefines, occurs clauses, packed decimals. Translating the code and leaving the data model as it was produces modern services that think like a 1980s batch job. The modernisation that lasts rebuilds the data layer around business entities, with the hierarchical structure the copybooks were always trying to express, which is why I argue elsewhere that COBOL modernization should skip the relational trap. AI gets you to that decision faster. It does not make it for you.

Newsletter

Get the next essay before it goes out anywhere else.

New essays and each new field guide, by email. Free, no ads, one-click unsubscribe.

Field guides only? Choose your list.

Read more

Suggested Reading