Read the old, design the new: what makes AI-assisted legacy modernization credible?

I've sat in enough legacy modernization kickoffs to know how they start. Someone asks whether we understand what the system in front of us does anymore. For most of my career, the honest answer was "not without months of digging." That part has changed. Our own AI-driven modernization model, which combines static analysis with AI, is already running 40–60% faster on current-state analysis in live customer projects than the manual process it replaces. AI-assisted analysis turns months of reverse engineering into a bounded process of extraction and review. What hasn't changed is what happens right after you get the answer, and that's where most of the "AI modernization" story on the market quietly stops. 

AI-native modernization is the practice of using AI to analyse legacy systems and drive delivery — extracting business rules, mapping dependencies, generating code — while people keep the design decisions and stay accountable for the outcome. 

Understanding legacy code is not the same as designing what replaces it 

The output of AI-powered code analysis is a structured view of what a system does: business rules, dependencies, edge cases, risk hotspots. That's genuinely valuable. It is not, however, a blueprint for what the new system should be. Treat it as one, and you inherit the old assumptions, the old limitations, and the old architecture right along with the old logic. Read the old. Design the new. Those are two different jobs, and conflating them is how "modernization" quietly becomes "expensive re-typing." 

It also won't be complete on the first pass. A peer-reviewed IBM Research study on COBOL business-rule extraction found 74% recall against ground truth. This means that a quarter of the rules in the code went unrecalled by the tool, surfacing only once a pilot slice ran into behavior nobody had documented. That's not a failure of the method. It's why specifications need to stay a living layer that improves with every cycle, not a document you file away after discovery week. 

Why large-batch AI delivery fails in legacy modernization 

The same logic that argues against big-bang migrations argues against big-batch AI delivery. The probability of a correct outcome drops as the step size grows. This is true whether a person or an agent is doing the work. Therefore, we keep changes small: reviewable, testable, and reversible. We put people back in the loop between the stages, not because agents can't move fast, but because a human checkpoint breaks the error chain before it compounds. That's the difference between an agent that looks fast and a workflow that's actually dependable. Tests can confirm old and new behavior matches. They can't confirm if the intent was right. That call stays human. 

Why AI-assisted modernization teams get smaller, not less accountable 

What we've watched shift on real engagements is team shape. A modernization core team used to run seven or eight specialists. Ours now runs three or four, working alongside agents. That is not necessarily a smaller commitment, but the roles and responsibilities are different. Someone still has to hold the intent, decide what gets delegated and what doesn't, and judge whether the value actually landed. Agents draft, generate, and execute. People decide, direct, and stay accountable for the outcome. 

The 2025 DORA report State of AI-assisted Software Development, published by Google Cloud, puts it plainly: AI acts as an amplifier, magnifying the strengths of high-performing organizations and the dysfunctions of struggling ones. The tooling helps, but the discipline around it is the differentiator. 

That's the practice I lay out in Chapter 3 of our new guidebook, alongside what changes operationally once teams take this seriously and where organizational readiness fits into the picture. 

Read Chapter 3 in full in our guidebook, AI-native modernization: the new economics of enterprise reinvention.  Download the guidebook →