Beyond the Hype: What AI Can (and Cannot) Do for Modernization
The fuzz is finally slowing down, by which I mean the noise of commentators reacting to Anthropic’s announcement that Claude Code can radically accelerate COBOL modernization. (And yes, I realize the irony of adding to that noise with this article.)
The narrative spread fast: AI has made COBOL obsolete, mainframe expertise is dead, and “the migration problem” is solved. But reality is far more nuanced.
What AI can actually do
Tools like Claude Code, Project Bob, and GitHub Copilot are undeniably useful — and not just for legacy code. I have recently seen them used equally for Java, Ansible playbooks, Python, and Groovy, for use cases best suited for these programming languages.
When applied to the right use cases, these AI tools can map dependencies across massive codebases, document workflows that exist only in the code, identify risks, and dramatically accelerate the analysis phase of a modernization project.
When vendors promise these tools help modernize codebases “in quarters instead of years,” they are referring specifically to this analysis and discovery phase. That is a legitimate, valuable improvement. But it is not the same as saying the modernization itself is finished.
What AI cannot do
Understanding and translating code is not modernization.
Beyond its syntax, a production application comprises infrastructure, data models, complex integrations, specific transaction-processing behaviours, security architecture, operational processes, and decades of accumulated business logic. Much of this context is completely invisible in the raw code itself.
Every modernization programme requires deep domain expertise. You need people who understand what the system does, not just what the code says. AI can read the code, but it cannot tell you whether the behaviour it describes is still correct, intentional, or safe to change.
Furthermore, AI tools are only as good as the questions we ask them. Programmers will not be replaced; instead, their roles will shift from nitty-gritty syntax writers to integrators and domain experts. They will be the ones guiding the process and making the judgment calls AI cannot. Faster change may very well require more people who can guide it well, rather than fewer.
The decision AI cannot make
Should you migrate at all? And if so, why?
Migration should never be driven by technology preferences, but by realistic business benefits. If you do proceed, you still have to answer: what, when, and to what?
These are fundamental business and architecture decisions. They require a deep understanding of the platform’s position within your IT landscape, the actual cost-versus-value of the applications, migration risks, and realistic alternatives. AI changes the cost of one part of the execution — it does not change the validity of the decision.
Organisations that treat better tooling as an excuse to skip the decision-making process are making a classic mistake: acting on technological enthusiasm (“gear acquisition syndrome,” as I like to call it) rather than business judgement.
Modern infrastructure is hybrid by default
The headlines fall into a predictable trap: they see the word “COBOL” and immediately frame it as an outdated mainframe story. This completely misses the reality of modern enterprise architecture. COBOL is a language that runs across distributed systems worldwide, while the mainframe is a versatile platform built for massive throughput. Conflating the language with the hardware oversimplifies a complex architectural reality into a cheap headline.
More broadly, the cloud-versus-on-premises debate — and by extension, the mainframe-versus-everything-else debate — is increasingly a rearguard action. Modern infrastructure is hybrid by default. In fact, the mainframe is arguably the most hybrid platform in existence. Looking at IBM’s recent strategic partnership with Arm, which I interpret as a move toward dual-architecture hardware, this is a clear signal that the future is about running diverse software ecosystems natively, where the data lives.
The question is no longer which platform “wins,” but which applications belong where and how they connect safely and efficiently. And “where they belong” is no longer just a technical question of latency or cost; it is increasingly a question of control. Organisations must balance cloud agility with the strict requirements of regulatory compliance, operational resilience, and long-term control over their core data infrastructure.
The real question is whether your applications — wherever they happen to run — are well-designed, well-maintained, and fit for purpose.
The real impact of LLMs? We don’t know yet.
A final word on the apocalyptic predictions from AI tech leaders and market commentators: these inflated timelines seem primarily intended to justify valuations and raise more capital.
The reality is that we don’t yet know how deep the long-term structural impact of LLMs will truly go. For IT specifically, programming seems to be a discipline precise and verifiable enough to be offloaded to AI to a significant extent. But as we have seen, coding is only a fraction of the challenge when building or maintaining software-intensive systems. For basically every other practice outside the programming area, the impact of AI is still entirely up in the air.
What this means in practice
Use AI tools for what they excel at: accelerating analysis, improving documentation, and reducing the cost of exploration. But never mistake a better tool for a better decision.
The code is merely the starting point, not the destination.
Architecture, modernisation strategy, and how to make truly informed decisions about the mainframe are covered in Don’t Be Afraid of the Mainframe: The Missing Introduction for IT Leaders and Professionals. Available at Amazon, Barnes & Noble, and other bookstores.
