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.
Now imagine thousands of these rules, each running payrolls, processing claims, or reconciling accounts, spread across millions of lines of code written over 40+ years. HyperDocs ingests that code and reconstructs it into readable, living documentation that shows how the black box system works.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.
jclay•1h ago
I 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.
sai18•1h ago
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.