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

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

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.

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)

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

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

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.

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

https://youtu.be/RM7Q7u0pZyQ?si=zpP6mP7SYxLbuHqJ

Maybe 50-year-old COBOL programs are the original neural networks.