There’s a familiar storyline making the rounds right now: point an AI coding assistant at a legacy application, translate the COBOL (or FORTRAN, or PL/I, or SAS, or VB 6.0), and watch a modern system emerge on the other side.
It’s a comforting idea because it frames modernization as a language problem. And language problems are the kind of problems we’re used to solving with tools.
But most modernization programs don’t fail because the engineers can’t learn the syntax. They fail because the organization can’t recover the intent.
In this post, I want to make a simple case: AI-assisted coding can absolutely accelerate modernization, but it doesn’t remove the hard parts of modernization. Those hard parts live upstream and downstream from “write code”: the “why,” the evidence, the governance, and the operational reality of running real systems under real constraints.
What we keep pretending modernization is
When people talk about “AI-driven modernization,” the mental model often sounds like this:
- Legacy code is hard to read.
- AI can read it.
- Therefore, AI can rewrite it.
That’s not wrong so much as incomplete.
Legacy languages aren’t mystical. Most competent engineers can get to “I understand what this is doing” in weeks. The bottleneck isn’t that the code is written in COBOL. The bottleneck is that the code is doing something for a reason that rarely lives in the source file.
Sometimes that reason is a business rule. Sometimes it’s a long-forgotten regulatory interpretation. Sometimes it’s a workaround for a system that no longer exists. Sometimes it’s simply scar tissue from production incidents that happened before the current team was hired.
Syntax is the easy part. Semantics are the work. Intent is the risk.
Legacy code is not a specification, it’s a fossil record
If you’ve spent time inside legacy business systems, you know the pattern:
- The code is full of exceptions.
- The exceptions exist because the real world is full of exceptions.
- The reasons for the exceptions are scattered across history: past data migrations, reorganizations, vendor constraints, compliance interpretations, outages, mergers, unwritten operational practices.
When a modernization effort says, “We’ll just rebuild it so it works like the old one,” what it’s really saying is, “We’ll treat emergent behavior as a requirement.”
That doesn’t scale.
“It works like the old one” is not a requirement; it’s an outcome statement. Outcomes matter, but outcomes don’t tell you what’s essential, what’s accidental, and what’s actively harmful but tolerated because nobody wants to touch it.
Modernization requires separating these:
- Business intent: what the system must accomplish.
- Operational constraints: what must be true for it to run safely and predictably.
- Historical artifacts: what the system does today because of long-past decisions.
AI can help you summarize code. AI can help you map flows. AI can even suggest refactors and translations. In many cases, AI can even translate the behavior of your code to a complete set of requirements. But none of that answers the key question: why is this behavior here, and do we still need it?
If your goal is to reduce risk, “Why?” is the risk surface.
The real modernization job is proving, not building
This is where modernization gets uncomfortable, because it forces you to treat software not as a pile of functions, but as a regulated, audited, operational process.
Even in organizations without formal regulatory oversight, mature teams still have to answer:
- What are the requirements, and how do we know we met them?
- What does “correct” mean—especially across edge cases?
- Can we reproduce historical runs?
- Can we run old and new systems in parallel without creating chaos?
- What happens when something goes wrong at 2 a.m.?
For many systems—especially safety-related or financially material ones—you don’t get to wave those questions away because “AI wrote it.” The laws of man (regulation, audit, contracts) and the laws of physics (systems fail, inputs are messy, humans make mistakes) don’t take time off.
If you operate in medical devices, for example, the FDA’s guidance on software validation is explicit about validation principles and the connection between requirements, verification, and documented evidence. That’s not an “AI exception” domain. It’s an evidence domain.
Aviation is even more direct: the FAA’s guidance recognizes established frameworks (including RTCA DO-178C) as an acceptable means of showing compliance for airborne software assurance. Again: proof, traceability, rigor.
You don’t modernize these systems by translating syntax. You modernize them by building a chain of evidence that the new system is correct, safe, and controllable—often while preserving the ability to reproduce the past.
That’s why parallel runs are so common in serious modernization. Not because teams love running two systems, but because you need a controlled way to compare behavior, reconcile differences, and build confidence before cutover.
And when “the same behavior” is required—think billing, payroll, claims adjudication, risk scoring—the most difficult part is frequently not producing the new answer. It’s being able to explain, consistently, why the new answer matches (or intentionally diverges from) the old answer.
AI can accelerate the build. It cannot replace the proof.
“Where is this call taking me?” is not a minor detail
Legacy systems are often monoliths, but they’re monoliths with known boundaries. Modern systems can be modular in ways that are operationally elegant and security-wise terrifying. A small change in dependency resolution, a transitive package update, or a shift in runtime configuration can change behavior far from the code you touched.
So when someone says, “We’ll modernize it into microservices” or “We’ll rewrite it into a modern stack,” a responsible follow-up question is:
Do we understand the dependency graph well enough to control it?
This is exactly why secure development guidance increasingly treats supply chain risk as a first-class concern. NIST’s Secure Software Development Framework (SSDF) is designed to be integrated into any SDLC, emphasizing security practices as part of “how we build” rather than something bolted on at the end.
AI-generated code can be clean. It can also be confidently wrong, subtly insecure, or operationally unbounded. And in a modern dependency ecosystem, “a little helper library” can bring an entire hidden surface area with it.
Modernization isn’t just “rewrite the code.” It’s “reconstruct the system,” including its interfaces, dependencies, data flows, and the controls that keep it safe.
AI is still valuable—when you aim it at the right work
None of this is an argument against AI-assisted coding. It’s an argument against treating AI-assisted coding as the modernization strategy.
Used well, AI tools can be an amplifier:
- They can speed up codebase comprehension, especially when you’re dealing with unfamiliar patterns or sprawling, poorly documented flows.
- They can help generate first-pass documentation that a domain expert can correct and enrich.
- They can assist in creating test scaffolding, test data ideas, and refactoring plans.
- They can help teams draft interfaces and adapters that make it easier to isolate and replace components incrementally.
But the key is governance: AI is most powerful when it accelerates the parts of the work that are slow, repetitive, or mechanically complex—while humans remain accountable for intent, requirements, and acceptance criteria.
If your organization is thinking about AI-driven modernization, it’s worth framing AI through a risk lens, not a novelty lens. That’s also the spirit of the NIST AI Risk Management Framework: it’s a lifecycle-focused approach to understanding and managing AI-related risks to improve trustworthiness.
AI can help you move faster. It can also help you get to the wrong destination faster.
The teams that succeed will be the ones that use AI to compress cycle time without collapsing rigor.
What modernization actually demands
Here’s the uncomfortable truth that modernization programs eventually rediscover:
You still need requirements.
You still need tests.
You still need traceability.
You still need parallel operations.
You still need auditability and reproducibility when the business depends on it.
AI doesn’t remove those needs. If anything, it raises the bar on how clearly you define them—because when code becomes easier to generate, the differentiator becomes how well you specify, validate, and operate what you generate.
Or said another way:
When writing code gets cheaper, knowing what code should exist becomes the expensive part.
Closing: Don’t modernize the syntax—modernize the understanding
Let’s land where we started.
Legacy modernization was never primarily about syntax. COBOL and FORTRAN and PL/I aren’t the final bosses. The final boss is organizational memory: the reasons behind the rules, the operational reality behind the edge cases, and the evidence you need to trust a new system in production.
AI-assisted coding is real leverage—especially for comprehension and acceleration. But modernization is still a full development process, not a translation exercise. The winners will treat AI as an accelerator inside a disciplined lifecycle, not as a substitute for one.
If you’re leading modernization work, the question to bring into every AI conversation is simple:
Are we speeding up the parts that were slow, or are we skipping the parts that were hard?
