The Anthropic code modernisation debate is an oversimplification

The AI modernisation debate has been loud recently with Anthropic’s claims that Claude Code can fundamentally change the way organisations modernise COBOL. A flurry of analysis has followed, including a thoughtful governance-focused piece from Holonic. Enterprise buyers are now asking questions about AI’s potential use cases and – more importantly – limitations in modernisation programmes.

Those are exactly the right questions. But the current debate is happening in the wrong place.

The COBOL debate is a distraction from a harder problem

AI-assisted COBOL modernisation is real and increasingly tractable. COBOL is a language. Its runtime is thin, well-understood and extensively documented. The translation challenge is significant at scale, but it is fundamentally a language translation problem, which is something LLMs are genuinely good at with the right governance architecture around them.

But the legacy modernisation market is not just COBOL. Organisations around the world are running mission-critical applications built on low-code and no-code platforms from the 1980s and 1990s: Gen, CA Telon, SUPRA, MANTIS, NATURAL/ADABAS, and others. These platforms sit at the core of financial services, insurance, healthcare and government systems. They are expensive to support, increasingly difficult to staff, yet remain operationally critical.

For these platforms, the AI modernisation debate is almost entirely beside the point, because the fundamental challenge is not language translation. It is runtime substitution. That is a different problem entirely.

What a runtime dependency actually means

Every one of these platforms generated application code that depended on a proprietary runtime. That runtime managed capabilities such as data population, database currency tracking, transaction boundaries, error state propagation, screen and dialog management and platform-specific arithmetic. Today, modern application stacks typically require these capabilities to be assembled, configured, or governed explicitly by developers.

Take Gen as an example. It is a model-based CASE tool with source code generation to multiple targets. A Gen application appears to be code – COBOL, C, or Java depending on the version – but what that code does is inseparable from the Gen runtime. Here is the critical constraint: runtime semantics, such as view population and mapping or packed decimal arithmetic that financial regulators demand is preserved, are not encoded in the generated source code. They are also not encoded in the Gen model or Encyclopaedia, the metadata repository that defines the application.

Semantics live in the runtime itself, in the interaction between constructs that no formal specification fully captures, and in the accumulated knowledge of the small number of specialists who have worked deeply with the platform for decades.

Pointing an LLM at the generated code will not surface semantics. The information needed to perform a correct conversion does not exist in either artefact that AI tooling could be directed at. What looks like a translation problem is a runtime substitution problem. And runtime substitution requires explicit, engineered rules. Not inference. As with other model-based tools, the runtime substitution is only the tip of the iceberg. Much of the information about the system is hidden in the tool itself, in the models, components and diagrams that describe the system. This information is invaluable in system conversions.

The same constraint applies, in varying degrees, across the broader low-code legacy landscape. CA Telon, SUPRA, MANTIS, NATURAL all generate code with runtime dependencies that cannot be inferred from the output alone. The specifics differ, but the fundamental constraint is the same.

Licensing adds a further barrier

For Gen specifically, there is a legal constraint on top of technical barriers. The Broadcom Software Product Description restricts use of Generated Objects. This prevents migration to a competitor product by prohibiting de-compilation or reverse engineering of generated source code or the Encyclopaedia. Any modernisation approach that processes Gen-generated code or the Encyclopaedia directly – including directing an LLM at either – carries licence risk that procurement and legal teams at regulated clients are now actively scrutinising.

This wider IP issue is not a technicality. It is a material constraint that eliminates the possibility of AI-first modernisation approaches for Gen, regardless of their technical quality.

What governed modernisation actually requires?

Our MigrationWorks product was built to solve this specific problem, not as a design philosophy, but because there was no other way to solve it correctly. The pipeline operates via Broadcom’s published Gen Model API, producing TXP’s own derived representations. It does not process Generated Objects or generated source. The conversion is deterministic. So, unlike LLMs, the same inputs produce the same reliable, consistent outputs on every run. The runtime substitution logic is encoded as explicit, inspectable, versioned rules, not embedded in model weights.

This architecture matters for a reason that goes beyond compliance. Gen estates are overwhelmingly in regulated industries. Under regulations such as UK Senior Managers & Certification Regime (SM&CR), the individual signing off a migration carries personal regulatory exposure. Auditors and regulators require organisations to demonstrate exactly what transformation was applied and why. A deterministic pipeline produces that evidence mechanically. Whereas a probabilistic pipeline created by an LLM turns establishing the same provenance into an investigative exercise.

When you’re talking about scouring potentially millions of lines of code, you can see the issues that arise. Recent independent analysis – including Holonic’s governance framework – reinforces that this distinction dominates modernisation programme outcomes at scale, regardless of how fast the initial translation runs. The level of scrutiny required after AI has generated code completely negates any efficiencies on the back end.

Where AI does and will add value

However, none of these factors mean there isn’t a role for AI in low-code legacy modernisation. But the COBOL debate is an oversimplification, and AI’s use cases in transformation are quite different from those being discussed.

Discovery and documentation, understanding what an estate contains, how components relate, what business logic is embedded, is a genuine and exciting AI opportunity. An estate that has been running for thirty years, maintained by developers who have since retired, is often poorly documented. AI can accelerate the process of making that estate legible without needing to solve the runtime substitution problem.

Testing and assurance are another application. Generating test cases from documented business logic, identifying coverage gaps, flagging behavioural divergence are all tasks where AI augments a deterministic pipeline, rather than replacing it.

The right way to frame the use of AI is ‘accelerated and deterministically governed modernisation’. This means using AI to undertake real work in discovery, documentation, and assurance – making specialists faster and programmes more thorough. Not using AI as the conversion engine.

The window is open, but not indefinitely

The organisations running Gen, Telon, SUPRA, and MANTIS estates should not wait for AI to solve their problem, because it can’t – not yet at least. Licence pressure, talent scarcity, and operational resilience requirements are forcing modernisation decisions now. The question is not whether to exit, but how to do it safely.

For this platform class, the answer is specialist tooling with deterministic pipelines, runtime substitution logic built from deep platform knowledge, and a governance architecture that satisfies regulators and auditors. That approach exists today. The AI tools that might eventually change this calculus do not – and building them would require access to platform knowledge that neither the generated code nor the model possess.