Now bringing in AI agents that are incredibly good at software engineering into the modernization lifecycle can completely change the landscape. That's the vision we're building towards at Hypercubic.
Previously you might need 50 engineers and 5+ years to modernize a mainframe application, now with Hypercubic, we can compress that down to 1/5th of those estimates.
> I often wonder why mainframes never had a more modern easier to maintain and manage programming language designed for them.
Although COBOL is one of the primary programming languages for the mainframe, it can also run Java and Python as the others have mentioned. COBOL itself isn't particularly difficult to grasp for modern engineers, it's readable and has an easy to understand English-like syntax.
The challenge here is learning and becoming proficient in the end to end mainframe ecosystem including the intricacies of z/OS. It's a completely closed off ecosystem and is not as accessible to play around with for the average SWE as compared to windows or linux based development.
That is the current landscape today. Mainframe engineers are in high demand and good ones are paid quite well.
I've heard from a global bank, they have one mainframe developer in the team who is past 70. She manages a critical credit card service and gets paid in the upper end of 6 figures to work 20 hrs a week. She's the only one who knows that system. Lots of stories like this.
The problem here is that people who understand these systems are all retiring. Majority of the devs are over 60 and there's simply not enough new talent coming in to replace them.
So the real challenge companies are facing is will there be enough people to safely maintain these systems in the next decade. If they do not, it means failures in credit card systems, airline reservations, insurance claims and more.
That’s what we’ve seen with our customers. Some have only one or two COBOL developers left in some teams, and they are often the only people with the operational knowledge needed to keep these systems running.
They are either past retirement or about to retire in the coming years.
You’re describing the pattern we’re seeing across most companies who are still on COBOL.
The shortage of COBOL engineers is real but the harder problem is enterprise scale system understanding. Most modernization efforts stall not because COBOL is inherently a difficult language, but because of the sheer scale and volume of these enterprise codebases. It's tens of thousands of files, if not millions, spanning 40+ years with a handful of engineers left or no one at all.
We're exploring some of this work at Hypercubic (https://www.hypercubic.ai/, YC-backed) if you're curious to learn more.
With the current reasoning models, we now have the capability to build large scale agentic AI for mainframe system understanding. This is going beyond line-by-line code understanding to reason across end-to-end system behavior and capturing institutional knowledge that’s otherwise lost as SMEs retire.
This is accurate to what we've seen in the market.
If they were large enough to need compute 30-40+ years ago, they certainly have some mainframes running today. Think Walmart, United Airlines, JPMC, Geico, Coca Cola and so on.
Like Bloop, we’re also focused on modernization, but our approach extends beyond code to include the people behind these systems and capturing the institutional knowledge they hold.
Absolutely true, and the challenge is that a large portion of modernization projects fail (around 70%).
The main reasons are the loss of institutional knowledge, the difficulty of untangling 20–30-year-old code that few understand, and, most importantly, ensuring the new system is a true 1:1 functional replica of the original via testing.
Modernization is an incredibly expensive process involving numerous SMEs, moving parts, and massive budgets. Leveraging AI creates an opportunity to make this process far more efficient and successful overall.
There are may be other general-purpose tools out there that overlap in some ways, but our focus is on vertically specializing in the mainframe ecosystem and building AI-native tooling specifically for the problems in this space.
I’d also note that COBOL is only one layer of the stack.
The real complexity lies in also understanding z/OS (mainframe operating systems), CICS, JCL, and the rest of the mainframe runtime, it’s an entirely parallel computing universe compared to the x86 space.
Mechanical Orchard is a major player in this space, though their model is closer to professional services than a true end-to-end AI modernization platform.
Looks like it's already been pointed out. We’re not applying AI to these systems — IBM is already pursuing those initiatives (https://research.ibm.com/blog/spyre-for-z).
Our focus is different: we’re using AI to understand these 40+ year-old black box systems and capture the knowledge of the SMEs who built and maintain them before they retire. There simply aren’t enough engineers left who can fully understand or maintain these systems, let alone modernize them.
The COBOL talent shortage has already been a challenge for many decades now, and it’s only becoming more severe.
Given how far back these systems go, the real challenge isn’t just the code or the lack of documentation, but the tribal knowledge baked into them. A lot of the critical logic lives in conventions, naming patterns, and unwritten rules that only long-time SMEs understand.
Using AI and a few different modalities of information that exist about these systems (existing code, docs, AI-driven interviews, and workflow capture), we can triangulate and extract that tribal knowledge out.
The decision makers we work with are typically modernization leaders and mainframe owners — usually director or VP level and above. There are a few major tailwinds helping us get into these enterprises:
1. The SMEs who understand these systems are retiring, so every year that passes makes the systems more opaque.
2. There’s intense top-down pressure across Fortune 500s to adopt AI initiatives.
3. Many of these companies are paying IBM 7–9 figures annually just to keep their mainframes running.
Modernization has always been a priority, but the perceived risk was enormous. With today’s LLMs, we’re finally able to reduce that risk in a meaningful way and make modernization feasible at scale.
You’re absolutely right about COBOL’s limited presence in training data compared to languages like Java or Python. Given COBOL is highly structured and readable, the current reasoning models get us to an acceptable level of performance where it's now valuable to use them for these tasks. For near-perfect accuracy (95%+), that is where we see an large opportunity to build domain-specific frontier models purpose built for these legacy systems.
What we're attempting was not possible two years or even a year ago.