Launch HN: Hypercubic (YC F25) – AI for COBOL and Mainframes
Hypercubic is an AI platform that helps Fortune 500 companies understand, preserve, and modernize their mainframe systems. These are the systems that run COBOL from the 1960s that still quietly power banking, insurance, airlines, and governments today.
70% of the Fortune 500 still run on mainframes, but the engineers who built and maintained them are retiring. Today, the average age of a COBOL/mainframe engineer is about 55 and rapidly increasing. What’s left behind are opaque, black box systems with almost no one who understands how they work. Modernization projects often fail, documentation is decades out of date, and critical institutional knowledge lives only in the minds of a few senior subject matter experts who are now leaving the workforce.
Current “AI for code” tools focus on codebases and repositories, so they miss the unwritten rules, historical context, and architectural reasoning that live in human minds. In the COBOL/mainframe world, that institutional knowledge is the key missing piece.
What we heard from modernization leaders is that the hard part is not the code analysis. The challenge is the institutional knowledge that never made it into code or documentation and has walked out the door. Modernization projects fail not because no one can parse COBOL, but because no one can answer “why was this billing edge case added in 1995 and what breaks if we remove it.”
Hypercubic is building an AI-native maintenance and modernization platform that learns how legacy mainframe systems actually work and captures the human reasoning behind operating them. We’re doing this with two initial tools, HyperDocs and HyperTwin.
HyperDocs ingests COBOL, JCL, and PL/I codebases to generate documentation, architecture diagrams, and dependency graphs. Enterprises currently spend months or years hiring contractors to reverse-engineer these systems; HyperDocs compresses that work to take much less time.
COBOL was designed to resemble English and business prose, making it a good fit for LLMs today. Mainframes have decades of consistent patterns (COBOL, JCL, CICS, batch jobs) and a finite set of recurring tasks (such as payroll, transaction processing, billing).
For example, here’s a billing fragment that would be run nightly in production at large insurance companies for moving money, closing accounts, and triggering downstream reports:
EVALUATE TRUE
WHEN PAYMENT-DUE AND NOT PAID
PERFORM CALCULATE-LATE-FEE
PERFORM GENERATE-NOTICE
WHEN PAYMENT-RECEIVED AND BALANCE-DUE = 0
MOVE "ACCOUNT CLEAR" TO STATUS
PERFORM ARCHIVE-STATEMENT
WHEN OTHER
PERFORM LOG-ANOMALY
END-EVALUATE.
Our other tool, HyperTwin, tackles the “tribal knowledge” problem. It learns directly from subject-matter experts, observing workflows, analyzing screen interactions, and conducting AI-driven interviews to capture how they debug and reason about their systems. The goal is to build digital “twins” of the experts on how they debug, architect, and maintain these systems in practice.
Together, HyperDocs and HyperTwin form a knowledge graph of legacy systems linking code, systems, and human reasoning.
Here’s a demo video of our HyperTwin product: https://www.youtube.com/watch?v=C-tNtl9Z_jY
You can explore our documentation platform, including examples from the AWS Card Demo (a widely used COBOL codebase example) and a dummy insurance project here:...
26 comments
[ 2.5 ms ] story [ 54.6 ms ] threadI would expect most of these systems come with very carefully guarded access controls. It also strikes me as a uniquely difficult challenge to track down the decision maker who is willing to take the risk on revamping these systems (AI or not). Curious to hear more about what you’ve learned here.
Also curious to hear how LLMs perform on a language like COBOL that likely doesn’t have many quality samples in the training data.
here that person is a manager which got demoted from ~500 reports to ~40 and then convinced his new boss that it's good to reuse his team for his personal AI strategy which will make him great again.
2 you do a "line by line" reimplementation in Java (well banks like it).
3 you run the test suite and track your progress
4 when you get to 100 percent, you send the same traffic to both systems and shadow run the new implementation. Depending on how that goes you either give up, go back to work implementation or finally switch to the new system
This obviously is super expensive and slow to minimize any sort of risks for systems that usually handle billions or trillions of dollars.
There's a bunch of mainly legacy hospital and government (primarily VA) systems that run on it. And where there's big government systems, there's big government dollars.
I was curious to ask you, as domain experts, if you could talk more to the "70% of the Fortune 500 still run on mainframes" stat you mentioned.
Where do these numbers come from? And also, does it mean that those 70% of Fortune 500s literally run/maintain 1k-1M+ LoC of COBOL? Or do these companies depend on a few downstream specialized providers (financial, aviation/logistics, etc.) which do rely on COBOL?
Like, is it COBOL all the way down, or is everything built in different ways, but basically on top of 3 companies, and those 3 companies are mostly doing COBOL?
Thanks!
[0] https://news.ycombinator.com/item?id=45644205
We also sublease our mainframes to at least 3 other ventures; one of which is very outspoken they have left the mainframe behind. I guess that's true if you view outsourcing as (literally) leaving it behind with the competitor of your new system... It seems to be the same for most banks, none of which are having mainframes anymore publicly, but for weird reasons they still hire people for it offshore.
Given that our (and IBM's!) services are not cheap I think either a) our customers are horribly dysfunctional in anything but earning money slow and steady (...) and b) they actually might depend on those mainframe jobs. So if you are IBM or a startup adding AI to IBM I guess the numbers might add up to the claims.
> HyperDocs ingests COBOL, JCL, and PL/I codebases to generate documentation, architecture diagrams, and dependency graphs.
Lots of tools available that do this already without AI.
> The goal is to build digital “twins” of the experts on how they debug, architect, and maintain these systems in practice.
That will be a neat trick, will the output be more than sparsely populated wiki?
My experience is there’s not a lot of Will or money to follow these things through.
Edit to add there was a lot of work around business rule extraction, automatic documentation, and static analysis of mainframe systems in 90s leading up to Y2K, but it all fizzled out after that. You all should search the literature if you haven’t.
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.
How do you consolidate this knowledge across disparate teams and organizational silos? How will you identify and reconcile subtle differences in terminology used across the organization?
Perhaps I misunderstood, but on your website you primarily identify technical implementors as SMEs. IME modernizing legacy data systems in high-stakes environments, the devil is more on the business side -- e.g. disparate teams using the same term to refer to different concepts (and having that reflected in code), or the exact stakeholders of reports or data systems being unknown and unknowable, and discerning between rules that are critical to a particular team or workflow that are opaque to you because e.g. you don't know who all relies on this data or are missing business context, or because the rule is not actually used anymore, or because the implementation of the rule itself is wrong.
Besides, both technical and non-technical stakeholders and SMEs lean heavily on heuristics to decision with the data they are looking at, but often struggle to explicitly articulate them. They don't think to mention certain conditions or filters because for them those are baked into the terminology, or it doesn't occur to them that the organization deals with broader data than what they interact with in their day-to-day.
And unfortunately in these settings, you don't get many chances to get it wrong -- trust is absolutely critical.
I am skeptical that what you will end up with at the end of the day will be a product, at least if your intent is to provide meaningful value to people who rely on these systems and solve the problems that keep them up at night. My feeling is that you will end up as primarily a consultancy, which makes sense given that the problem you are solving isn't primarily technical in nature, it just has technical components.
The only other player I've seen is Mechanical Orchard
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.
Maybe 50-year-old COBOL programs are the original neural networks.
https://youtu.be/RM7Q7u0pZyQ?si=zpP6mP7SYxLbuHqJ
Sounds great but... I have migrated a big cobol codebase several years ago. Knowledge stored in the experts is 1/ very wide 2/ full of special cases that pop up only a few times in a year 3/ are usually complex cases involving analysing data, files which are on paper, etc. I strongly doubt an AI will be able to spot that.
The knowledge that usually misses the most is not "how is that done", because spending a few hours on COBOL code is frankly not that hard. What misses is: "why". And that is usually stored in laws, sub-sub-laws, etc. You'll have to ingest the code and the law and pray the AI can match them.
So in the end the AI will make probably 50% of the effort but then you'll need 150% to understand the AI job... So not sure it balances well.
But if it works, well, that's cool because re-writing cobol code is not exactly funny: devs don't want to do it, customers do it because they have to (and not because it'll bring additional value) and the best outcome possible is the customer saysing to you "okay, we paid you 2mio and the new system does the same things as before we started" (the most likely outcome, which I faced, is "you rewrote the system and its worse than before). So if an I can do it, well, cool.
(but then it means you'll fire the team who does the migration which, althgouhg is not funny and not rocket science, requires real expertise; it's not grunt work at all)
Surely not at a rate faster than one year per year?
The goal is to replace people to 'save money'. And I'm always amused at startup founders who so obviously never worked with real people in real environments (outside of the startup bubble) that they think people are too stupid to see this for what it is. I look forward to their explanation to their investors as to why their product didn't meet expectations because after taking 5-6 seconds to figure out what this new 'tool' was intended to do, the users spent all of their time figuring out how to feed it garbage so it didn't become their besty twin replacement.
We’re curious to hear your thoughts and feedback, especially from anyone who’s worked with mainframes or tried to modernize legacy systems.
Lol.