Launch HN: Hypercubic (YC F25) – AI for COBOL and Mainframes

86 points by sai18 a day ago

57 comments

View on Hacker News

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.

zurfer 21 hours ago

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.

Reply View 5 replies
  • makestuff 19 hours ago

    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.

    Reply View 1 reply
    • mkoubaa 18 hours ago

      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.

      Reply View 0 replies
  • aayn 20 hours ago

    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.

    Reply View 2 replies
    • mvh 16 hours ago

      Sort of related to what bloop is trying to do too right?

      Reply View 1 reply
      • sai18 12 hours ago

        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.

        Reply View 0 replies
iammrpayments 3 hours ago

You’re absolutely right, here’s the corrected code to prevent users from receiving 4 quadrillion dollars in their savings account

Reply View 0 replies
gregsadetsky 20 hours ago

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

Reply View 5 replies
  • fock 17 hours ago

    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.

    Reply View 0 replies
  • Muromec 19 hours ago

    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

    Reply View 2 replies
    • tapland 19 hours ago

      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.

      Reply View 0 replies
    • sai18 12 hours ago

      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.

      Reply View 0 replies
  • hobofan 18 hours ago

    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

    Reply View 0 replies
jclay 21 hours ago

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.

Reply View 4 replies
  • sai18 20 hours ago

    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.

    Reply View 2 replies
    • ciaranmca 18 hours ago

      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?)

      Reply View 1 reply
      • sai18 17 hours ago

        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.

        Reply View 0 replies
  • fock 17 hours ago

    > 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.

    Reply View 0 replies
wiz21c 17 hours ago

> 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)

Reply View 0 replies
didgeoridoo 15 hours ago

> rapidly increasing

Surely not at a rate faster than one year per year?

Reply View 0 replies
le-mark 20 hours ago

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.

Reply View 0 replies
koolba 20 hours ago

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.

Reply View 2 replies
  • sai18 20 hours ago

    Thanks for sharing. It seems MUMPS is just as old and legacy as some of the COBOL systems!

    Reply View 1 reply
    • antonvs 6 hours ago

      I was offered a MUMPS job in the 1980s. I took one look at the code and very quickly concluded that life was too short for that.

      Later I got into programming language theory, and took another look at MUMPS from that perspective. As a programming language, it’s truly terrible in ways that languages like COBOL and FORTRAN are not. Just as one example, “local” variables have an indefinite lifetime and are accessible throughout a process, i.e. they’re not scoped to functions. But you can dynamically hide/shadow and delete them. It would be hard to design a less tractable way of managing variables if you tried.

      MUMPS’ value proposition was how it handled persistent data as a built-in part of the language. In that sense it was a precursor to systems like dBASE, which were eventually supplanted by SQL databases. MUMPS was a pretty good persistent data management system coupled with a truly terrible programming language.

      Reply View 0 replies
martyheyman 16 hours ago

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}.

Reply View 3 replies
  • teruakohatu 9 hours ago

    > The challenge is the institutional knowledge that never made it into code or documentation and has walked out the door.

    This is a problem a compiler cannot fix, and is a very real problem.

    Reply View 0 replies
vector_spaces 19 hours ago

> 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.

Reply View 0 replies
huevosabio 19 hours ago

Cool! I think this is a great use of LLMs.

The only other player I've seen is Mechanical Orchard

Reply View 1 reply
  • sai18 17 hours ago

    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.

    Reply View 0 replies
29athrowaway 19 hours ago

There is a large graveyard of people trying to escape the mainframe, replace COBOL, etc.

Reply View 4 replies
  • tapland 19 hours ago

    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

    Reply View 1 reply
    • sai18 17 hours ago

      Curious why the COBOL devs were laid off if they're in the middle of a modernization or some sort of replacement project?

      Reply View 0 replies
  • sai18 17 hours ago

    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.

    Reply View 1 reply
    • 29athrowaway 15 hours ago

      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.

      Reply View 0 replies
1970-01-01 20 hours ago

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.

Reply View 3 replies
  • sai18 20 hours ago

    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.

    Reply View 1 reply
    • spratzt 3 hours ago

      Isn’t strange that this talent shortage never translates itself into decent rates?

      Reply View 0 replies
  • koolba 20 hours ago

    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.

    Reply View 0 replies
iepathos 19 hours ago

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.

Reply View 1 reply
cess11 19 hours ago

All I can think about when reading this presentation is that Glamorous Toolkit pretty much has this and more.

Reply View 2 replies
  • sai18 17 hours ago

    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.

    Reply View 1 reply
    • cess11 6 hours ago

      I'm not sure what "AI-native" would mean but GT has LLM-integrations, support for working in distributed systems and a COBOL-bridge that has been used in managing transitions of legacy systems.

      Here's a talk about it:

      https://www.youtube.com/watch?v=W8TSPED0alY

      If you load the code referenced here, https://book.gtoolkit.com/analyzing-cobol--the-aws-carddemo-... , you can explore the demo used in the talk.

      I'm sure you'll manage to figure out the LLM-integrations.

      Edit: The Feenk folks also have a structured theory for why and how to do these things that they've spent a lot of time and experience on refining, visualising and developing tooling around.

      I think it is a good idea for anyone working with large legacy systems to have such a theoretical foundation for how to communicate, approach problems and evaluate progress. Without it one is highly likely to make expensive decisions based on gut feeling and vague assumptions.

      Reply View 0 replies
cool-RR 19 hours ago

> 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.

Reply View 5 replies
  • brightball 19 hours ago

    Really good money in it for people who want to learn COBOL though.

    Reply View 4 replies
    • le-mark 14 hours ago

      > Really good money in it for people who want to learn COBOL though.

      False, all those jobs were outsource and offshored long ago.

      Reply View 1 reply
      • dragonwriter 14 hours ago

        A lot of them are domestic, either in the public sector directly (so probably not really good money, but usually pretty decent benefits and job security) or with government contractors which require the work to be domestically (so maybe good money.)

        Reply View 0 replies
    • mkoubaa 18 hours ago

      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.

      Reply View 1 reply
      • sai18 17 hours ago

        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.

        Reply View 0 replies
mkoubaa 21 hours ago

I'm excited for you but nervous about the kinds of bugs that might get caused

Reply View 1 reply
  • sai18 20 hours ago

    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.

    Reply View 0 replies