Hi HN, we’re Sai and Aayush, and we’re building Hypercubic (https://www.hypercubic.ai/), bringing AI tools to the mainframe and COBOL world. (We did a Launch HN last year: https://news.ycombinator.com/item?id=45877517.) Today we’re launching Hopper, an agentic development environment for mainframes.
You can download it here: https://www.hypercubic.ai/hopper, and you can also request access and immediately get a mainframe user account to play with.
There's also a video runthrough at https://www.youtube.com/watch?v=q81L5DcfBvE.
Mainframes still run a surprising amount of critical infrastructure: banking, payments, insurance, airlines, government programs, logistics, and core operations at large institutions. Many of these systems are decades old, but they continue to process enormous transaction volumes because they are reliable, secure, and deeply embedded into business operations.
A lot of that software is written in COBOL and runs on IBM z/OS. The development environment looks very different from modern cloud or Unix-style development. Instead of GitHub, shell commands, package managers, and CI pipelines, developers often work through TN3270 terminal sessions, ISPF panels, partitioned datasets, JCL, JES queues, spool output, return codes, VSAM files, CICS transactions, and shop-specific conventions.
TN3270 is the terminal interface used to interact with many IBM mainframe systems. ISPF is the menu and panel system developers use inside that terminal to browse datasets, edit source, submit jobs, and inspect output. It is powerful and reliable, but it was designed for expert humans navigating screens, function keys, and fixed-width workflows, not AI agents.
A simple COBOL change might require finding the right source member, checking copybooks, locating compile JCL, submitting a job, reading JES/SYSPRINT output, interpreting condition codes, patching fixed-width source, and resubmitting.
Much of this work is so well-defined and repetitive that it's a good fit for agentic AI. To get that working, however, a chatbot next to a terminal is not enough. The agent needs to operate inside the mainframe environment.
Hopper combines three things: (1) A real TN3270 terminal, (2) Mainframe-aware panels for datasets, members, jobs, and spool output, and (3) An AI agent that can operate across those z/OS surfaces.
For example, here is a tiny version of the kind of thing Hopper can help debug:
COBOL:
IDENTIFICATION DIVISION.
PROGRAM-ID. PAYCALC.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 CUSTOMER-BALANCE PIC 9(7)V99.
PROCEDURE DIVISION.
ADD 100.00 TO CUSTOMER-BALNCE
DISPLAY "UPDATED BALANCE: " CUSTOMER-BALANCE
STOP RUN.
JCL:
//PAYCOMP JOB (ACCT),'COMPILE',CLASS=A,MSGCLASS=X
//COBOL EXEC IGYWCL
[//COBOL.SYSIN](https://cobol.sysin/) DD DSN=USER1.APP.COBOL(PAYCALC),DISP=SHR
[//LKED.SYSLMOD](https://lked.syslmod/) DD DSN=USER1.APP.LOAD(PAYCALC),DISP=SHR
Hopper is not trying to hide the mainframe behind a generic abstraction, and it's not a chatbot. The design principle is simple: preserve the fidelity of the mainframe environment, but make it accessible to AI agents.
Sensitive operations require approval, and the terminal remains visible at all times.
Once agents can operate inside the mainframe environment, new workflows become possible: faster job debugging, automated documentation, safer code changes, test generation, migration planning, traffic replay, and modernization verification.
We’re curious to hear your thoughts! especially from anyone who has worked with mainframes, COBOL or has done legacy enterprise modernization.
Built by leading minds behind the world's most advanced AI and technology - Our team unites top researchers, engineers, and strategists from pioneering companies and institutions [...]
https://www.hypercubic.ai/company
Please consider adding more background of the executive and heads of department on the about page to help us understand who these top researchers, engineers, and strategists are.
There are currently no names on the about page, not even the co-founders, however this claim that "our team unites top researchers, engineers, and strategists from pioneering companies and institutions" appears on multiple pages on the website.
It seems:
* Sai was a machine learning engineer for 19 months, then a lead machine learning engineer for 17 months at Apple.
* Aayush was a software engineer for 3 years, then a senior software engineer for 8 months at Apple.
Hi! I agree we should have a profile page on website.
Btw, this is Aayush and I was at Apple for almost four years and Sai was there for three. And we have Kevin as our founding engineer who has almost a decade of experience and has worked at Cognition and Windsurf.
If it ain't broke, don't fix it. So letting an LLM loose on a mainframe is like letting a fox into a henhouse. :)
The problem here is that people who understand these systems are all retiring. Majority of the devs are over 60 and there's simply not enough new talent coming in to replace them.
So the real challenge companies are facing is will there be enough people to safely maintain these systems in the next decade. If they do not, it means failures in credit card systems, airline reservations, insurance claims and more.
Correct, they are retiring, for sure.
The last thing I’d ever put into mission-critical systems is an LLM.
So let’s hope it’s a mainframe sandbox so future COBOL programmers can learn on it. :)
In any case, COBOL systems work precisely because no one is constantly tinkering with them to “add a new framework”.
The last time I saw, someone made a “Hello World” app in Electron, and it was 220 MB.
Howgh.
It sounds like they will still need to hire and train human talent who can understand the code, and evaluate and integrate outputs of AI systems that conform to the specific compliance and data retention requirements of these industries. And also people who can enforce said compliance, and a lot of other things. Sounds like a complex problem without a neat off-the-shelf solution
What was the training data? While there are open source projects for mainframes, most high-quality and battle-tested COBOL code bases are likely proprietary.
Also, will it be trained on the code base it sees? Most companies would be opposed to sharing their IP.
Edit: according to the website, the model won't be trained with your data.
US banks and creditors desperately need this yesterday.
That’s what we’ve seen with our customers. Some have only one or two COBOL developers left in some teams, and they are often the only people with the operational knowledge needed to keep these systems running.
They are either past retirement or about to retire in the coming years.
and now they moved to microservices chaos and need it more than ever.
Hopefully Llm while it may not allow immediately for like 100% ready to go financial services code
Maybe it gives us good tests ?
That alone for something on cobol might be worthwhile
Is this available to install on Hercules emulator for hobbyists? For people unfamiliar with Mainframes, check out the moshix youtube channel.
We don't currently support Hercules, but we are providing free access to a mainframe for people to try out.