Teamday
← Back

Blitzy Mapped a 35M-Line Mainframe in 4 Days With Neo4j

AI Engineer
agentsenterpriseautomationcodingbusiness

Why Blitzy Puts a Knowledge Graph Under Its Modernization Agents

Stephen Chin is VP of Developer Relations at Neo4j and, 30 years ago, a Java developer migrating COBOL off mainframes in multi-year projects that often failed. Neeraj Deshmukh leads engineering and research at Blitzy, the autonomous software development platform. Their AI Engineer talk uses the AWS CardDemo mainframe application to show why asking an AI to "change that formula from COBOL to Java" fails: it converts the formula and misses the record precision, the account updates, the transaction output and the batch contract. "The failure here is not that AI can't write the code. It's that AI doesn't know the 14 other places where that logic, that code is being used."

Context windows don't fix it: Chin's point is that bigger models haven't solved this class of problem. Vector databases give similarity search, relational databases over MCP give single-hop lookups, and advertised million-token windows deliver 200K or less of usable context. The speakers put usable context at "about, like, 20 to 30 percent, which means about, like, 200,000 to 300,000 lines of code. If your software is bigger than that, too bad." A graph gives multi-hop, accurate context: program, job, copybooks and outputs as nodes and relationships, each edge keeping its repo, revision, symbols and source span as evidence, updated on every merge.

Infinite code context, per agent: Each Blitzy agent receives a task context packet: the task, its place in the graph, the relevant source slice, constraints, available evidence and open questions. Blitzy reverse-engineers the whole software estate into business logic, workflows and hidden dependencies, takes the user's requirements, and produces an agent action plan that a domain expert must approve before thousands of agents share it. "We actually spend more computes on testing than we do on code gen."

Parity is proven, not promised: Preserving behavior means matching money, precision, rounding, balances, transaction records and error outcomes between the baseline and the modern system. "You can't take it as an assumption or as a promise." The example is a one-cent interest difference: Java's default rounding differs from COBOL's, the modern code compiled and looked right, and only a parity test caught it. Across a million transactions that cent is a real problem. For a Fortune 100 insurer, the transpiled job's output was byte-identical to the mainframe's golden baseline.

The results: A tier-one bank's trade posting monolith with stored procedures and cross-database writes became six capability modules in PostgreSQL, Java, TypeScript and Python with full parity in 18 days against a plan of 18 engineer-weeks, with more than 4,000 tests and modern code less than half the size. A 35-million-line mainframe that a systems integrator had spent about eight months and several million dollars failing to map was reverse-engineered in four days; the customer's words were "They have been in a dark room with a pencil light inspecting each individual module. Blitzy feels like flipping on the overhead light, seeing the whole room at once." A 25-million-line policy administration platform was modernized nine times faster than IDE-based agentic tools, with 85% of the code completed autonomously and almost 90% of that reaching production.

5 Lessons from Blitzy and Neo4j on Modernizing Legacy Code With Agents

  • Map the whole system before changing it - "As long as you understand the whole system, before you change it using AI, you're good." The cost of a missed dependency in finance is money, not a failed build.
  • Give each agent a packet, not the repo - Right information, right time, right place beats stuffing a context window that degrades past 20 to 30 percent fill.
  • Keep evidence on every edge - Repo, revision, symbols and source span on each graph relationship make the agent's context auditable and let the graph invalidate stale facts on merge.
  • Test more than you generate - Unit tests, compiled builds, runtime integration, data parity on every write and identical end-to-end workflows, layered into generation rather than run at the end.
  • Humans lead the decisions that matter - The plan is approved by a domain expert and defects become explicit decisions; the agents own the typing and the validation.

What Graph-Backed Agents Mean for Enterprise Software Estates

Deshmukh frames modernization as the entry point, not the product: once the knowledge layer, governance rules and test suite exist, adding a promotional interest rate, running DORA compliance across the estate or producing audit evidence gets cheaper each time. This is context engineering built on a knowledge graph instead of a vector store, with a human in the loop at the plan and the merge. For the opposite failure, an agent with full context and no guardrails, see how a coding agent deleted a production database.