A Caribbean retailer had one developer keeping a core system running. He understood it well enough to operate and change it safely. No one else did. So the company kept pushing his retirement back, year after year, because losing him meant losing the only person who knew how the system actually worked.
That's the story Sai Gurrapu, co-founder and CEO of Hypercubic, uses to explain why his company exists. It's also a good summary of the real problem with COBOL modernization: it's not really about the code. It's about everything the code depends on that never got written down.
Hypercubic just closed a $5.3 million seed round from CIV, Y Combinator, and Afore to build multi-agent tooling aimed at COBOL modernization, the kind of legacy mainframe work most AI coding tools steer clear of. I talked with Gurrapu about why that gap exists, how the company's agents actually work, and what it takes to trust an AI-generated rewrite of code that's been running for decades.
The problem isn't the code
Ask Gurrapu why AI tooling avoids COBOL, and he doesn't point to the language itself. Modern models can read COBOL fine, he says. The hard part is everything around it.
A real mainframe application isn't just COBOL. It's copybooks, JCL, CICS transactions, files, databases, schedulers, terminal interactions, and integrations with other systems, often built up over decades. The behavior that matters is scattered across all of it. And there's barely any infrastructure for an agent to test and iterate against that world quickly, unlike a modern dev environment where you can spin up a test suite in minutes.
Then there's the mainframe's own set of quirks: numeric representations, fixed-width records, packed decimals, character encodings, implicit state. Small details, but the kind that break things in production if you get them wrong.
That's why Gurrapu doesn't think of this as a translation problem. He calls it a verification and reliability problem, which is why Hypercubic has built custom compilers, runtimes, simulators, and mainframe-operating tools alongside its models, rather than relying on an LLM alone.
Four systems, not one big agent
It's tempting to picture "multi-agent COBOL modernization" as a swarm of bots rewriting code in parallel. Gurrapu describes it differently: four core products, each agentic internally, each doing a distinct job.
HyperDocs reconstructs the legacy application's business rules, dependencies, and overall blueprint. HyperTwin captures what the people who understand the system know and turns it into something queryable. Hopper lets engineers and agents operate directly on the mainframe: running programs, inspecting datasets, interacting with the live system. HyperLoop handles the actual modernization: breaking the application apart, building the modern version incrementally, and verifying it against the original.
Inside those four products, agents handle code analysis, knowledge extraction, test generation, and implementation work.
Why this isn't just LLM translation
An LLM can turn COBOL into Java today. Gurrapu calls that the easy part, and increasingly a commodity. The catch is what comes out the other side: code he calls "JOBOL," Java that's syntactically fine but unreadable and unmaintainable.
The actual difficulty is understanding what a decades-old application does, rebuilding it into something maintainable, and proving the new version preserves the behavior the business actually depends on, across tens of thousands of programs and, in some cases, billions of lines of code, with the people who understood the original decisions long since retired. Right now, that process is almost entirely manual. Gurrapu's bet is that it can become software-driven instead.
Verification is the actual product
This is where Hypercubic spends most of its engineering effort, and it's worth walking through in some detail.
At the center is Isomorphic, a high-fidelity behavioral simulator that reproduces a mainframe application's behavior on commodity hardware. Instead of validating a change by pushing it to a mainframe and waiting, HyperLoop can run the relevant behavior locally, generate edge cases, and compare results against what the original system actually does. When a proposed rewrite diverges, the system surfaces the counterexample and traces it back to the underlying logic.
Every business rule the system extracts comes with provenance: citations to source code, execution traces, and the evidence used to derive it, not just an LLM's description of what the code seems to do. That gives Hypercubic a behavioral specification to continuously test against. If an agent's rewrite changes the underlying logic, the new implementation should diverge from that specification, giving the team a concrete problem to investigate rather than a line of code to trust blindly.
Gurrapu is upfront that human review still matters for genuine ambiguity or intentional business changes. But the core safeguard, in his framing, is automated and evidence-backed rather than a person reading every generated line.
What's still unproven
Worth noting plainly: when I asked whether verification had caught anything close to a real production issue, Gurrapu said Hypercubic's engagements are all still active, and he didn't want to claim a production outcome that hasn't happened yet. Details on the Latin American bank engagement are off-limits under NDA, and the company isn't sharing engagement timelines. That's a reasonable amount of caution for an early-stage company to have, but it also means the verification architecture above is currently a description of the approach, not a track record.
Where it fits next to everyone else
Hypercubic isn't the only company working on COBOL modernization. Larger systems integrators and other startups are in the space too. Gurrapu draws the distinction in two places: business model, since Hypercubic works on an outcomes-based structure rather than the traditional services-led approach, and where the hard problem actually is, which he argues is verification and testing rather than code generation.
On IBM specifically, he doesn't see competition. IBM's tooling, including the recently released Bob, focuses on the developer coding workflow. Hypercubic operates a level up, covering the full modernization program from understanding the legacy system through rebuilding and verification, and Gurrapu says HyperLoop is built to work with coding agents underneath it, including Claude Code, Codex, OpenCode, and IBM's own tools.
Whether that verification-first bet pays off will show up in engagement results Hypercubic isn't ready to share yet. For now, the pitch is straightforward: the code was never really the hard part. Trusting it was.
