AI-Assisted Refactoring of Legacy Code

AI-assisted refactoring of legacy code changes modernization economics because it lowers the cost of understanding old systems. Its strongest role is in code archaeology, mechanical changes, and behavioral testing. Human engineers still decide which behavior to keep, which architecture should replace it, and whether the result is ready for production.

Why legacy modernization gets chronically deprioritized — and what actually makes it expensive

Months of archaeology often precede the first useful modernization decision. Senior engineers spend weeks reading undocumented procedures, tracing dependencies, and reconstructing business logic before they can safely propose a change. Age alone does not make software legacy. A two-year-old service with no tests, no documentation, and one person who understands it can be harder to change than a well-maintained decade-old library. The defining property is the cost and risk of alteration.

That risk comes partly from the history embedded in the system. Software that has processed insurance claims or compliance workflows for two decades contains rules that were never recorded in external specifications. Tax routines, grandfathered pricing, and handshake-era agreements survive as executable behavior. The code is often the only surviving specification. Before replacing it, engineers must work out which details remain obligations and which are remnants of conditions that no longer apply.

Meanwhile, deferral raises maintenance costs, leaves dependencies unpatched, and makes experienced staff harder to find. New features still compete for the same engineers. Their scope can be easier to explain than an investigation whose first deliverable is simply understanding what already exists. Modernization therefore loses priority primarily because the prerequisite knowledge costs so much to recover.

What AI actually changes — and what it does not

AI reduces that prerequisite cost by making unfamiliar code easier to inspect and explain. IBM watsonx Code Assistant for Z delivered a 79% reduction in the time developers needed to understand complex applications at the National Organisation for Social Insurance (NOSI) in Egypt, a comprehension gain that leaves AI’s capacity for independent system redesign unproven. The distinction is central to resource planning.

Neither developer replacement nor “glorified autocomplete” describes this role adequately. AI can handle large amounts of work that follows patterns while people keep control over architecture, compliance, and business intent. An assistant can reproduce a rule faithfully while preserving the bug that the rule was quietly working around.

At the same time, a pattern that looks awkward may guard against a costly production failure. Source code can show what that pattern does without showing why it is there. AI cannot reliably recover unwritten intent or distinguish deliberate exceptions from accidental complexity. Teams therefore need to identify where they can accelerate comprehension and execution while retaining control over decisions that require context outside the code.

The three phases where AI genuinely compresses modernization timelines

The first phase is code archaeology and comprehension. Agents can explain tangled functions, trace call graphs, and expose business rules that are difficult to see through procedural detail. Repository analysis can reduce the time needed to produce dependency graphs, cyclomatic complexity scores, code-smell reports, and hotspot maps from weeks to hours. Hidden coupling becomes easier to inspect. Components that seem separate may share global state or a database, and functions and modules that are no longer used can be considered for removal before translation begins.

NOSI used the assistant to explore, document, and comprehend intricate COBOL applications. Some investigations that previously took a full day or more became possible in a fraction of that time. The resulting map also gives subsequent changes a defined scope, rather than leaving an agent to optimize isolated fragments.

The second phase applies mechanical refactoring to that understood scope. Renaming, restructuring, updating deprecated APIs, and porting patterns across files are repetitive changes that agents can assemble into reviewable batches. Google’s internal DIDACT methodology supported an integer ID migration across its monorepo, with most modifications AI-authored and an estimated 50% reduction in total migration time. A migration between versions of a testing framework changed thousands of files and more than a hundred thousand lines in three months. The large majority of generated code was committed without alteration.

AWS Transform provides another production example through Toyota’s COBOL-to-Java modernization across tens of millions of lines. AWS reported reduced overall effort and substantially less discovery and planning time. Those claims have not been independently audited. The claims show how large a structured migration could be, though they do not give a productivity rate that applies everywhere.

The third phase, test generation, makes the preceding work verifiable. Its place in the framework is not an instruction to delay testing until after refactoring. Before changes begin, generated tests capture how the code now behaves to help catch silent regressions.

The tool landscape teams are actually using in mid-2026

Integration model and codebase type divide the mid-2026 tool landscape more usefully than headline benchmarks. GitHub Copilot fits into the IDE and GitHub workflow, offering block-level improvements and a diff before changes are applied. It can identify repeated logic for extraction and split large functions into smaller ones. Claude Code instead operates through a CLI or API and benefits from access to repositories, test environments, and CI.

With that setup, Claude Code can read a repository, plan coordinated multi-file changes, and verify them automatically. Cursor emphasizes project-wide indexing inside VS Code, with Agent Mode and Background/Cloud Agents supporting broader execution. But access to a repository alone does not tell the story behind the code. Incident records, on-call notes, architecture decision records, pull request discussions, and observability signals help reduce the risk of breaking implicit rules.

SonarQube with AI extensions, Sourcegraph Cody, CAST Highlight, and Snyk Code form part of the analysis layer used to prioritize modernization. OpenRewrite provides open-source, type-aware refactoring recipes for Java and JVM codebases, while Moderne runs those recipes fleet-wide. Sourcegraph also supports code search and batch changes.

Mainframe tools introduce another integration choice. IBM’s Bob Premium Package for Z, announced at Think 2026 and generally available June 24, 2026, succeeds the earlier assistant and gives the model a queryable static-analysis repository. AWS Transform also serves COBOL modernization, including Toyota’s migration. Deployment constraints can decide which approach is viable. Internal proxies, limits on cloud access, and rules that require on-premise execution affect which tools teams can choose, whatever the tools can do.

The perception-reality gap in AI productivity — and what explains it

METR’s July 2025 randomized controlled trial provides a strong counterweight to successful migration reports. It studied experienced open-source developers working on real issues in large, mature repositories they regularly contributed to, averaging 5 years of prior experience on each. Developers predicted that frontier models would make them faster. They were instead measured as slower. After finishing, they still estimated that AI had accelerated their work.

That result challenges the use of perceived speed as evidence of productivity. Clean, isolated benchmark tasks do not reproduce the ambiguity and implicit context of mature repositories. The comparison also involves a different starting point from unfamiliar-code archaeology. An experienced contributor already possesses knowledge that an assistant must reconstruct. A comprehension gain in one setting does not establish an execution gain in another.

The structured migrations described earlier show why teams need to choose tasks, integrate tools, and set rules for their use as well as adopt them. GitClear’s data shows refactoring falling from roughly a quarter to under a tenth of changed lines as AI adoption increased. Code growth is not necessarily code improvement. When senior engineers spend their time reviewing generated boilerplate and debugging AI-traced issues, the opportunity cost includes architectural work they can no longer undertake.

Where AI-generated code creates new risks in legacy modernization

Hallucinated dependencies create a supply-chain risk when generated code refers to packages that do not exist. Attackers can register those names through slop-squatting, so a suggestion that looks sound can lead to a malicious dependency. Legacy modernization adds this risk to an already difficult dependency review. A translation that appears to replace old syntax may also introduce new assumptions about external packages. Code that compiles does not prove that those assumptions are safe.

A subtler failure is code that appears complete while security, persistence, business logic, or test depth remains missing. Passing tests cannot reveal behavior that they do not cover. In legacy systems, the omitted behavior may be a jurisdiction-specific billing exception or a defensive response to an old production incident. Early adopters of COBOL modernization report substantial expert review requirements, particularly for complex data structures and embedded SQL.

IBM’s Rob Thomas framed the broader distinction as translation versus enterprise modernization. The language is not the source of mainframe value. The platform is. Even after COBOL is changed into modern syntax, teams still have to decide how the application should be built and run.

A practical framework for where human judgment remains non-negotiable

The practical boundary should follow the type of decision. AI can explain code, generate documentation, map dependencies, identify outdated patterns, and apply well-understood transformations. It can also generate tests intended to verify behavioral equivalence. These tasks produce evidence or execute a defined rule. These tasks leave the rule’s continued appropriateness unresolved.

Human engineers should decide which modules to modernize first and which to leave alone. That choice requires business context. Compliance specialists and domain experts must work out how regulatory exceptions apply, while engineers check timing dependencies that show up at peak load. Target architecture also remains a human decision. Choosing between refactoring and rebuilding changes the system’s future.

To make that division operational, teams should use risk-tiered autonomy. Simple mechanical refactors can get a lighter review, while changes that are complex or touch compliance need senior-engineer sign-off. The senior role shifts toward defining constraints, validating diffs, reviewing integration points, and interpreting test results. Responsibility stays with the engineering organization. In Paciolan’s work with FullStack, its full engineering organization was using an AI-native framework by March 2026 as it modernized a core platform with roughly 250 interdependent screens.

The program should begin with AI-assisted discovery that produces a plain-language business logic map and dependency graph. Teams should then add behavioral test coverage before they do any refactoring. Changes should then proceed incrementally, with rigorous validation at each step. Different parts of the estate can justify different treatments, including rehosting to buy time, refactoring, rebuilding a failing core, or retiring unused software. The governing skill is triage, with human review planned into the work.

How AI changes the economics of modernization decisions at the portfolio level

Lower discovery costs can speed up approved projects and change which other projects are worth taking on. A modernization proposal that was turned down because understanding the system took too much engineering time may now be affordable. The comparison with new feature work changes. Planning can shift from whether modernization is affordable to which systems should move first, using a documented view of dependencies and business behavior.

The staffing benefit extends beyond the migration itself. Plain-language explanations make unfamiliar systems more accessible to incoming engineers and reduce dependence on the few people who understand the old code. That addresses an organizational risk as well as a delivery cost. Meanwhile, planned modernization can begin earlier, before rising maintenance expense, security exposure, and hiring difficulty force a crisis. AI can move the break-even point forward.

Portfolio planning should thus pay for ways to review the work, risk-tiered autonomy, and checks by people as part of delivering modernization. Architectural judgment and regulatory interpretation remain deliberate allocations of expert time. With the archaeology bottleneck now addressable, organizations can bring previously uneconomical projects into a sequenced modernization program and put senior engineering effort toward deciding what their systems should become.