What the COBOL Translation Backlash Gets Right — and Wrong

When Anthropic published a blog post last week describing how Claude Code can analyze and translate COBOL, the market rejoiced at yet another proof point of the power of LLMs. Critics also reacted swiftly, noting that translating COBOL is not the same as modernizing a system. After all, a system lives in production: it is shaped by how transactions flow under load, how data moves across components, and how decades of edge cases and operational workarounds have quietly accumulated into the way it works.

The critics aren’t wrong. But their conclusion—that modernization therefore remains too hard to attempt—is incomplete.

In many organizations, mainframe systems have become constraints—blocking the organization from adopting AI, meeting new regulatory demands, or moving at the speed the business now requires. For those, “do not touch” is no longer a conservative position; it’s just a slower way of falling behind.

For those genuinely interested in solving this, a full rewrite remains the cleanest path: re-express the capability in a modern form, and reset the foundation. The problem is that executing this ideal has always been brutally hard. Any credible rewrite must reverse-engineer decades of intertwined business logic. It must reconstruct data structures that encode assumptions nobody wrote down. It must reimplement that logic faithfully. And it must transition from old to new with effectively zero downtime—in systems where downtime is not an option.

AI-assisted modernization is a genuine game-changer. Its ability to discover and analyze what’s written in code can indeed replace months of painstaking, expensive, manual work. That said, any AI-generated code for modernization must demonstrate exact equivalence—not just functionally, but in performance characteristics and integration behavior, across the full range of production scenarios. The liability for anything short of that is severe. So AI raises both the ceiling of what’s possible and the stakes of what can go wrong.

Here is the question that changes everything: what if code isn’t the right starting point?

Instead of attempting to infer intent from source code, capture how the system behaves in production: its inputs, outputs, data flows, observable effects. Done properly, that behavioral record becomes the ground truth for the rewrite. New implementations are validated continuously against it, not in a single high-stakes cutover at the end of a multi-year program, but incrementally, workload by workload.

This converts ambiguity into evidence. Reverse-engineering logic no longer depends solely on documentation or institutional memory; it is grounded in observed behavior. Reimplementation is validated against real production scenarios, including the edge cases that never appear in test suites because nobody remembered to write them down. Even AI-generated code can be verified deterministically when its function, performance, and integrations pass concrete criteria.

The risk calculus changes completely. A rewrite built on a behavioral safety net stops looking like a single, career-defining wager and starts to resemble a controlled transition. Systems that were labeled “do not touch” can be approached with method rather than trepidation.

The critics are right that code translation is insufficient, but that’s not the end of the argument. The obstacle has never been the mainframe itself: it’s been the absence of a modernization method worthy of its complexity. Shifting the starting point of a modernization from code to system behavior means that rewrites can stop being acts of courage and start being engineering problems with a straightforward solution.