AI code generation solved the speed problem in COBOL to Java migrations. It did not solve the problem that actually determines whether a modernization project finishes: getting a qualified engineer to certify that the generated Java is safe to run in production. A lead architect, a risk officer, or another authorizing official still has to sign that certification before a core banking system, a claims engine, or a benefits platform comes off the mainframe. That signature is the real finish line, and it is the step most COBOL to Java projects are not built to reach.

COBOL to Java code review sign-off is the certification an authorizing official gives once migrated Java code has been shown to preserve the behavior of the original COBOL. Reaching that certification depends on a bounded, line-bound review with proof of functional equivalence back to the source, not a manual read of every generated line. Without that proof, a reviewer has no practical way to certify millions of lines of generated code in any usable timeframe.

That gap, between code that has been generated and code that has been signed off, is where large modernization budgets currently stall out.

The COBOL to Java Code Review Sign-Off Problem

A large language model can turn a COBOL program into readable, idiomatic Java in a matter of minutes, and for a modernization team under budget pressure, that speed is genuinely useful. But the deployment gate for a core system does not move just because the code arrived faster. Someone with the authority to accept the system still has to answer for what changed, and an LLM's own self-assessment does not count as that answer, because the model has no execution log tying any given output line back to a specific rule in the source. It optimized for a plausible next token, not for a verifiable claim about behavior.

At small scale, a team can absorb that gap by reading the code carefully and testing thoroughly. At the scale most core banking and government systems actually run, hundreds of thousands to millions of lines, exhaustive manual review is not a discipline problem a stricter process fixes. It is a bounded-hours problem. There are only so many engineering hours available, and a genuinely unbounded review, where every line theoretically needs independent verification because nothing points back to why it looks the way it does, consumes those hours faster than any team can supply them. Projects don't fail because engineers get lazy. They stall because the review scope was never actually bounded in the first place.

Why Millions of Lines Break Human Review

The root cause is structural, not behavioral. Deterministic systems produce the same output from the same input every time, and that repeatability is what makes an output checkable: a reviewer can trace forward from cause to effect and backward from effect to cause. A large language model is probabilistic. Run the same COBOL program through the same model twice and the resulting Java may differ in ways that have nothing to do with the underlying business logic, which means a reviewer has no fixed causal chain to audit. The model's confidence in its own output is not evidence, and self-reported test passes are not proof of behavior, because the model wrote both the code and the tests from the same underlying uncertainty.

This is not a hypothetical problem for teams doing this work today. Regulated-industry engineers managing large COBOL estates routinely note that no COBOL equivalent of a modern regression-testing framework exists in consistent use, which leaves multi-year parallel runs (running the old and new systems side by side and comparing output line for line) as the closest thing to a trusted proof method still in general use for finance, banking, and insurance workloads. That is not a sign of an industry being slow to adopt tooling. It is a rational response to legacy code review fatigue in AI-driven migration: when nothing else offers durable evidence, running both systems for years and comparing results by hand is the only method teams have found they can actually trust.

Independent research backs up why this breaks down faster than most vendors admit. Published benchmark results on repository-level code modernization show agent pass rates falling from 91.3 percent on codebases under 10,000 lines to 15.3 percent above 50,000 lines.1 COBOL migrations of any real size sit well past that threshold before the project even starts. The tools that look impressive in a demo are being evaluated on a scale that has almost nothing to do with the scale a bank, an insurer, or a federal agency actually runs.

Plausible Output vs. Provable Output

The practical difference between generated code and reviewable code comes down to what a reviewer can check without reading every line by hand.

That last row is the whole argument. Automated COBOL to Java functional equivalence is not a claim a vendor gets to assert about its own output. It has to be demonstrated against a record a reviewer can independently check, line by line, against the source that produced it.

What a Bounded, Explicit Review Actually Requires

This is where deterministic COBOL migration governance stops being an abstraction and becomes a specific set of artifacts a reviewer can use directly. CodeIntent, Holonic's platform, works as the source-derived record of software intent, used to understand and govern change: for every piece of the original COBOL, it establishes what the code was actually doing, what the equivalent Java does, and whether the two match. CodeIntent Studio, the evidence workspace built on top of that record, is where an engineer or auditor traces any line of code back to its source, its stated intent, and the evidence supporting it.

Concretely, a bounded code review in legacy modernization needs to hand a reviewer four things for every piece of the system, whether that piece is a CICS transaction, a JCL batch job, a VSAM file definition, or a copybook shared across a dozen programs:

• The original source rule, cited specifically, not paraphrased from memory.

• The intent the migration was trying to preserve, change, or replace.

• The resulting target code, with a clear link back to the rule it implements.

• A recorded evidence artifact showing why that mapping holds, so the disposition itself is checkable rather than asserted.

When that structure is in place, most of a large COBOL codebase turns out to be unchanged behavior carried forward, or clearly deliberate, rule-governed changes an architect approved on purpose. What is left (real ambiguity in the original source, undocumented edge-case logic, control flow nobody fully wrote down) gets flagged explicitly and routed to a human. That is the entire mechanism behind bounded review: instead of asking a reviewer to independently verify everything, it narrows the review to the small fraction of cases where a machine genuinely cannot resolve the question on its own, and it says so out loud rather than silently guessing. A system that fails explicitly, that flags what it cannot verify instead of silently passing it through, is actually easier to trust than one that claims a clean result on a codebase too large for anyone to have checked.

The Audit Trail Risk Officers Will Ask For

None of this exists in a regulatory vacuum, and CROs on the buying committee know it better than anyone else in the room. The Federal Reserve's supervisory guidance on model risk management, updated in April 2026, states plainly that generative and agentic AI models are novel and rapidly evolving, and that they are not within the scope of that guidance.2 Banking's existing model-risk framework has an open gap for exactly the category of tool now generating production code, and it will likely stay open for some time.

That gap does not mean the risk goes away. It means the burden of proof shifts back onto the modernization team, which is precisely what a mainframe modernization audit trail is built to carry. A federal audit of legacy IT modernization reached a similar conclusion from the government side: agencies that document their modernization plans and evidence face a lower likelihood of the cost overruns, schedule delays, and outright project failures that undocumented efforts tend to produce.3 Whatever direction formal AI-specific guidance eventually takes, a record that shows exactly what changed, what was preserved, and what evidence supports each decision gives a risk function something concrete to evaluate today, not a promise to evaluate later.

What This Means for Your Next Migration

Generation speed was never the constraint that mattered most. The constraint was always whether someone with the authority to accept the system could actually do so, on a timeline the business could sustain. A COBOL to Java code review sign-off process built around bounded, source-traced evidence gives an architect or a risk officer a review they can finish, instead of a codebase they can only take on faith.

Learn more about Holonic's approach to deterministic verification.