[HN Gopher] Launch HN: Hypercubic (YC F25) - AI for COBOL and Ma...
___________________________________________________________________
Launch HN: Hypercubic (YC F25) - AI for COBOL and Mainframes
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 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.
Author : sai18
Score : 67 points
Date : 2025-11-10 16:23 UTC (6 hours ago)
| jclay wrote:
| Exciting work! I've often wondered if an LLM with the right
| harness could restore and optimize an aging C/C++ codebase. It
| would be quite compelling to get an old game engine running again
| on a modern system.
|
| 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 wrote:
| Thank you!
|
| 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.
| ciaranmca wrote:
| In terms of training your own models, is there enough COBOL
| available for training or are you going to have to convince
| your customers to let you train on their data (do you think
| banks would push back against that?)
| sai18 wrote:
| There isn't enough COBOL data available to reach human-
| level performance yet.
|
| That's exactly the opportunity we have in front us to make
| it possible through our own frontier models and infra.
| fock wrote:
| > 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).
|
| 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.
| mkoubaa wrote:
| I'm excited for you but nervous about the kinds of bugs that
| might get caused
| sai18 wrote:
| 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.
| zurfer wrote:
| 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.
| aayn wrote:
| 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.
| mvh wrote:
| Sort of related to what bloop is trying to do too right?
| makestuff wrote:
| 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.
| mkoubaa wrote:
| 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.
| 1970-01-01 wrote:
| This is weird. Mainframes are the dinosaurs of tech. Never would
| I think, 'let's add some AI' to a mainframe. It would be like
| adding opposable thumbs to dinosaurs. You are still solving the
| wrong problem, but it sure will be interesting watching the
| systems cope.
| koolba wrote:
| IIUC, what's being solved here is not the mainframe, it's the
| lack of knowledge transfer of what the heck that software is
| doing and how it works. Anything that drives down the cost of
| answering those types of questions, whether for debugging or
| replacing, is going to be worth a lot to the dinosaurs running
| these systems.
| sai18 wrote:
| 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.
| koolba wrote:
| Neat stuff. For more esoteric environments that could use this
| type of automated leg up, check out MUMPS:
| https://en.wikipedia.org/wiki/MUMPS
|
| 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.
| sai18 wrote:
| Thanks for sharing. It seems MUMPS is just as old and legacy as
| some of the COBOL systems!
| gregsadetsky wrote:
| 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!
|
| [0] https://news.ycombinator.com/item?id=45644205
| Muromec wrote:
| 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
| tapland wrote:
| 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.
| hobofan wrote:
| 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
| fock wrote:
| 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.
| le-mark wrote:
| I've witnessed two legacy migration projects, both failed. One
| was a source translation to Java, this one failed because they
| didn't have the expertise to manage production Java applications
| and pulled the plug. The other was a rewrite that went over
| budget and was cancelled.
|
| > 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.
| cess11 wrote:
| All I can think about when reading this presentation is that
| Glamorous Toolkit pretty much has this and more.
| sai18 wrote:
| Reminds me of this comment on the Dropbox HN launch thread:
| https://news.ycombinator.com/item?id=9224
|
| 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.
| vector_spaces wrote:
| > 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.
|
| 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.
| huevosabio wrote:
| Cool! I think this is a great use of LLMs.
|
| The only other player I've seen is Mechanical Orchard
| sai18 wrote:
| 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.
| iepathos wrote:
| I can tell they're using MkDocs for the HyperDocs static site gen
| based on the screenshot. I'm working on an open source solution
| to generating docs with AI for codebases and maintaining them for
| documentation drift. I wrote a bit about it initially here
| https://entropicdrift.com/blog/prodigy-docs-automation/ for
| anyone who is interested. I'm currently using mdbook instead of
| mkdocs, may add support for a mkdocs workflow to produce similar
| doc sites for just the cost of the LLM tokens. I didn't realize
| COBOL had such a large market for documentation with code as the
| source of truth. I'll have to try generating docs on an open
| source COBOL codebase to see how it fairs. Would be nice if
| hypercubic had actual live doc examples for what hyperdocs
| generates instead of just a screenshot, hard to judge how good or
| bad it is with just a single screenshot.
| sai18 wrote:
| There's a live playground you can try out here:
| https://hyperdocs-public.onrender.com/ -- built just for the HN
| crowd.
| 29athrowaway wrote:
| There is a large graveyard of people trying to escape the
| mainframe, replace COBOL, etc.
| tapland wrote:
| I've seen a few, 9 figure projects to replace essentially 6
| devs and three sysadmins.
|
| Another proposed replacement about to fail now, after half the
| COBOL devs were laid off.
|
| So if anyone needs a remote openvms/hp nonstop or junior z/os
| dev :D
| sai18 wrote:
| Curious why the COBOL devs were laid off if they're in the
| middle of a modernization or some sort of replacement
| project?
| sai18 wrote:
| 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.
| 29athrowaway wrote:
| IMO, not the best use case for LLMs.
|
| COBOL projects have millions of lines of code. Any
| prompt/reasoning will rapidly fill the context window of any
| model.
|
| And you'll probably have a better luck if you had
| tokenization understands COBOL keywords.
|
| You probably have better luck implementing a data miner that
| slowly digests all the code and requirements into a
| proprietary information retrieval solution or ontology that
| can help answer questions...
|
| What an engineer tells you can be inaccurate, incomplete,
| outdated, etc.
| cool-RR wrote:
| > What's left behind are opaque, black box systems with almost no
| one who understands how they work.
|
| Maybe 50-year-old COBOL programs are the original neural
| networks.
| brightball wrote:
| Really good money in it for people who want to learn COBOL
| though.
| mkoubaa wrote:
| Good money elsewhere for people capable of (a) learning COBOL
| (b) being effective in a legacy codebase and (c) operating in
| a large organization in a political savvy way.
| sai18 wrote:
| 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.
| brightball wrote:
| In case you're interested in learning more about COBOL, there was
| a great talk on it at Carolina Code Conference this year.
|
| https://youtu.be/RM7Q7u0pZyQ?si=zpP6mP7SYxLbuHqJ
| wiz21c wrote:
| > The goal is to build digital "twins" of the experts on how they
| debug, architect, and maintain these systems in practice.
|
| 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)
| learner007 wrote:
| very cool!
| martyheyman wrote:
| Mainframe COBOL to POSIX native machine language or Java is
| largely a solved problem. 40 year old code that hasn't been
| touched in 30 years "ain't broke" and likely doesn't need fixing
| IMHO. Our take is get it to POSIX/Java so you can sort out all
| the OTHER STUFF and then rewrite/re-architect at your leisure.
| {disclosure: we're the GCC COBOL team}.
| didgeoridoo wrote:
| > rapidly increasing
|
| Surely not at a rate faster than one year per year?
___________________________________________________________________
(page generated 2025-11-10 23:00 UTC)