AI-assisted COBOL modernization depends on verification, not generation

At a glance

What this is: This is an analysis of why AI is changing COBOL modernization and why verification, not code generation, is the limiting control.

Why it matters: It matters to IAM and security teams because legacy code modernization increasingly depends on trusted automation, and identity, access, and change governance must account for machine-generated changes in critical systems.

👉 Read Sonar's analysis of AI-assisted COBOL modernization and verification

Context

AI is now being applied to legacy codebases because the human expertise needed to maintain them is thinning out, not because the code suddenly became more modern. COBOL modernization exposes a governance gap that most change programmes still underestimate: if automated tools can generate or translate code faster than experts can review it, the weak point becomes verification, not syntax.

That matters beyond software engineering because critical systems often sit behind identity, access, and operational control processes that cannot tolerate silent behavioural drift. In practice, the article is about the control problem created when AI starts touching load-bearing systems that still encode payroll, settlement, claims, and benefit logic.

Key questions

Q: What breaks when AI-generated COBOL is not independently verified?

A: The failure mode is behavioural drift. Code can compile, deploy, and even pass superficial tests while silently changing branching, exception handling, or embedded business rules. In COBOL, that can translate into wrong payments, incorrect eligibility decisions, or settlement errors. Independent verification is what separates a useful draft from a release candidate.

Q: Why does COBOL modernization create a verification problem instead of just a translation problem?

A: Because the hardest part of legacy modernization is preserving intent, not converting syntax. The original business rules often sit in undocumented routines and in the heads of retiring experts. AI can accelerate translation, but without a trusted review layer it also accelerates the release of subtle mistakes into systems that cannot tolerate them.

Q: How do organisations know whether AI-assisted code remediation is actually safe?

A: They know it is safe only when every automated fix is reviewed, tested, and traceable back to the original finding. Look for evidence that the suggestion preserved behaviour, passed validation, and did not expand attack surface. If those checks are missing, the tool is accelerating change without improving assurance.

Q: Who is accountable when an AI system changes infrastructure configuration?

A: Accountability should sit with the programme owner responsible for the AI system and the change governance process that approved its operating scope. If the system can alter configuration, then the access model, logging model, and change approval model all need explicit ownership, otherwise responsibility becomes distributed until no one can defend the outcome.

Technical breakdown

Why AI accelerates COBOL understanding more than replacement

AI is most useful with COBOL when it turns opaque code into readable business logic. Large language models can summarise procedural flows, extract rules from long paragraphs, and produce translation drafts into modern languages. That helps with the retirement cliff, because the scarce resource is not just developers who can write COBOL, but people who can explain what old routines are supposed to do. The main limitation is that AI does not know which legacy behaviours are intentional, undocumented, or unsafe. It produces plausible output, not validated equivalence.

Practical implication: treat AI as an accelerator for comprehension and drafting, not as an authority on production-ready modernization.

Verification is the control that legacy modernization actually depends on

Deterministic analysis matters because AI-generated code can look correct while changing edge-case behaviour. In COBOL, that risk is amplified by embedded logic in DB2 and CICS statements, where business impact is tied to control flow rather than flashy syntax. Static analysis and quality gates provide a consistent second review layer that does not depend on a shrinking expert workforce. This is the same governance logic that underpins code security in broader DevSecOps programmes: trust should be earned through repeatable checks, not inferred from model confidence.

Practical implication: require machine-generated COBOL to pass the same quality gates and policy checks as human-authored code.

Agent-centric development shifts trust from the author to the gate

The article’s broader point is that software development is moving toward a pattern where agents generate and independent systems verify. That changes the control plane for modernisation programmes, because provenance alone is no longer enough to establish trust. A shrinking population of subject-matter experts cannot be the only safety mechanism when code volume increases. In regulated or economically critical environments, the deciding factor is whether every change can be checked for reliability, security, and maintainability before promotion.

Practical implication: design modernization workflows so that approval is based on verified output, not on who or what produced it.

Threat narrative

Attacker objective: The practical objective is not always theft but uncontrolled behavioural change in critical systems, which can create financial, operational, or compliance damage without an overt breach.

1. Entry occurs when AI tools are used to generate or translate legacy COBOL without a strong verification layer, allowing plausible but unreviewed changes into the pipeline.
2. Escalation happens when subtle logic errors, missing branches, or unsafe reproductions of legacy patterns move from draft code into systems that control payroll, claims, or settlement workflows.
3. Impact is silent business corruption rather than obvious compromise, because the code still runs while producing incorrect outcomes at economic scale.

NHI Mgmt Group analysis

Verification debt is the real modernization risk. AI lowers the cost of understanding and rewriting old code, but it also increases the volume of changes that require independent checking. When review capacity shrinks faster than change volume grows, organisations accumulate verification debt. That debt is more dangerous than technical debt in load-bearing systems because it delays the discovery of behavioural drift until it is already in production. The practitioner conclusion is straightforward: if you cannot verify at the rate you generate, you cannot safely modernize.

COBOL modernization exposes a trust gap, not a language problem. The language is old, but the control failure is current. Most programmes talk about translation quality, yet the deeper issue is whether automated output preserves business intent when the original intent lives in retiring engineers' heads. That makes modernization a governance exercise as much as a technical one. The practitioner conclusion is to treat legacy knowledge capture and verification as one control loop, not two separate workstreams.

Agent-centric development needs deterministic gates because model confidence is not evidence. AI can draft code, but it cannot certify that edge cases, fall-through logic, and embedded business rules behave exactly as intended. This is especially true where mainframe logic is entwined with operational identity and entitlement flows in downstream systems. The practitioner conclusion is to enforce non-negotiable quality gates before code reaches systems of record.

Modernization programmes should assume expert scarcity will persist. The retiring COBOL workforce is not a temporary staffing problem that will normalize next quarter. That means organisations should stop treating human review as the only compensating control and start building durable verification into the pipeline. For identity and governance teams, the lesson is that machine-produced change still needs accountable ownership, traceability, and approval boundaries. The practitioner conclusion is to redesign controls around persistent scarcity, not hope.

What this signals

AI-assisted modernization will force governance teams to distinguish between code generation speed and release confidence. The organisations that succeed will build verification into the pipeline early, because review capacity will not keep pace with agent output if they rely on manual inspection alone.

Verification debt: this is the accumulation of unreviewed or under-reviewed machine-generated change across critical systems. As AI use expands, programmes will need to treat deterministic analysis, traceability, and release gating as core controls rather than optional engineering hygiene.

For readers responsible for identity-adjacent controls, the parallel is clear. When automation can produce change faster than humans can authorise or validate it, the control boundary has to move closer to the gate, not farther away.

For practitioners

• Implement deterministic quality gates Require AI-generated COBOL and human-authored COBOL to pass the same static analysis, policy checks, and fail conditions before promotion to production.
• Capture business rules before retirement Document critical COBOL logic while subject-matter experts are still available, then validate AI translations against those preserved business rules.
• Separate draft generation from release authority Allow agents to produce first drafts and refactor candidates, but keep release authority with a controlled review step that can block behavioural drift.
• Expand verification to embedded logic paths Scan not only COBOL source but also embedded DB2 SQL and CICS statements, because that is where many production behaviours actually live.

Key takeaways

• AI makes COBOL modernization faster, but it does not make the output trustworthy.
• The central risk is verification debt, because review capacity cannot scale by assumption.
• Modernization programmes need deterministic gates that validate behaviour, not just code shape.

Key terms

• Security Debt: Accumulated risk that builds when vulnerabilities, unsafe dependencies, and policy gaps are left unresolved across the software lifecycle. In AI-assisted development, security debt grows quickly because more code is produced, more decisions are made automatically, and remediation often lags behind delivery.
• Deterministic program analysis: Deterministic program analysis is code analysis that identifies relevant paths, sinks, and candidate locations through exact rules rather than probabilistic guessing. In a mixed AI workflow, it acts as the coverage engine, feeding the model the code slices it should reason about instead of asking the model to search the whole repository.
• Agent-centric development cycle: A development pattern in which agents generate code while an independent layer verifies it before release. The model shifts trust from the author to the gate, which is especially important in environments where systems of record cannot absorb silent behavioural changes.

What's in the full article

Sonar's full analysis covers the operational detail this post intentionally leaves for the source:

• COBOL analysis coverage across SonarQube Server Enterprise Edition and SonarQube Cloud Enterprise plan
• Nearly 200 rules across 10 COBOL dialects, including embedded DB2 SQL and CICS statements
• How quality gates compare human-written and AI-generated code on the same pass-or-fail criteria
• In-editor feedback through SonarQube for IDE in connected mode for day-to-day development workflows

👉 Sonar's full post covers the COBOL analysis workflow, dialect coverage, and quality gate approach in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle controls. It helps practitioners build accountable control models for systems where automation changes the trust boundary.