Hi HN, we’re Sai and Aayush and we’re building Hypercubic (https://www.hypercubic.ai/)!
Hypercubic is an AI platform that helps Fortune 500 companies understand, preserve, and modernize their mainframe systems. These are the sy...
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: https://hyperdocs-public.onrender.com/.
e.g. Developer perspective docs - High level system architecture of credit card management: https://hyperdocs-public.onrender.com/docs/aws-carddemo-with...
We’re curious to hear your thoughts and feedback, especially from anyone who’s worked with mainframes or tried to modernize legacy systems.
Comments
I heard the story once on how you migrate these old systems: 1 you get a super extensive test suite of input - output pairs
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.
I have been part of a few migration projects like this. There is another issue apart from tests not existing. Business/Product still want new high priority features so developers keep adding new logic to the old system because they cannot be supported by the new system yet.
By mkoubaa 2025-11-1020:12 The secret sauce is being able to operate below your maximum effectiveness while still seeming impressive enough. That is, if you want to play the long game and get a lot done over a 5 year horizon.
Yeah, we've heard the same "big bang" story a bunch of times as well. However, step 1 (extensive test suite) is often missing and is something you'd have to do as part of the modernization effort as well. Overall, it is a pretty hairy and difficult problem.
By iammrpayments 2025-11-1111:14 You’re absolutely right, here’s the corrected code to prevent users from receiving 4 quadrillion dollars in their savings account
By gregsadetsky 2025-11-1018:213 reply I submitted this [0] story a few weeks ago, which led to some discussion and then being flagged since (I think) people were unsure of how verifiable the stats around COBOL were (the submitted page had more than a tinge of self-promotional language).
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!
By fock 2025-11-1021:15 I work at a shop (a specialized provider for finance in your eyes) which still has the "transaction" workload on IBM z/OS (IMS/DB2). The parts we manage (in Openshift) interface with that (as well as other systems) and I have heard of people/seen the commits moving PL/I to Cobol. In 2021. Given Cobol's nature, those apps have more than 1k LoC easily.
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.
Rule of thumb — if a bank already was there and dealing with things 30 years ago, it likely has some cobol left.
Generalizing — if the company had enough need for it 30 years ago, was big enough to but a mainframe and the thing they used it for barely changes — chances are it’s still there, if the company is still there.
Banks absolutely do have it in house, in a dedicated secure site with a fence and a moat
By tapland 2025-11-1019:18 And insurance, and there are telcos still having boxes spinning. And places dealing with inventories or airlines and whatever, or healthcare. If databases helped and it was around before 1992 it might still be running some cobol.
By sai18 2025-11-111:50 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.
By hobofan 2025-11-1019:49 One quick data point (might be not the most accurate, but I just looked into it a bit and thought I might as well share it): According to a quick look up with Sumble[0], ~120 out of Fortune 500 companies show any interest in COBOL.
Out of those it looks like about ~60 of those are actually using COBOL in-house, while most job postings from the rest are mostly "has experience with dealing with legacy COBOL systems". The top ~40 users are the ones you would expect (big banks, insurances, telco).
Of course this is a very LinkedIn/job postings lens on it, but in terms of gauging how big the addressable market for such a solution may be, I think it should do a decent job.
[0]: https://sumble.com - Not affiliated, I just quite like their product
