Legacy Code Is the Killer App for Coding Agents

Every coding-agent demo you've seen looks the same: a fresh repo, a greenfield app, a working prototype in twenty minutes. Impressive. Also almost perfectly misleading about where the money is.

Your engineering budget isn't bleeding on greenfield. It's bleeding on the fifteen-year-old services nobody wants to touch, the framework three major versions behind, the module whose author left in 2019, the migration that's been "next quarter" for four years. That's where coding agents earn their keep — and it's the use case most adoption programs never get around to, because it doesn't demo well.

Why the economics finally flipped

Legacy modernization has always died in the same place: discovery. Before you can migrate anything, someone has to read the old system — map dependencies, extract the business rules buried in the code, document what actually happens versus what the wiki claims. That phase is brutally expensive, requires your most senior people, produces no shippable output, and is why so many modernization projects never start. The code that needed rewriting stayed put not because rewriting was impossible but because understanding was unaffordable.

Agents attack exactly that phase. Reading a sprawling codebase, tracing call paths, summarizing what a module does, flagging dead code, generating documentation for the undocumented — this is tedious, parallelizable comprehension work, and it's precisely what agents are disproportionately good at. Anthropic made this the centerpiece of its Code Modernization Playbook for COBOL systems: automate the discovery and documentation that used to require armies of consultants, and keep humans on the judgment calls. Their phased outline — two weeks of discovery, two weeks of proof of concept, a first migration by week eight — would have been fantasy pricing for mainframe work a few years ago.

And the broader numbers, for what they're worth, point the same direction: McKinsey has estimated generative AI can accelerate modernization timelines by 40–50%, and industry surveys show most enterprises now fold AI into their modernization strategy. Take any single vendor stat with salt — but the direction of travel is consistent with what I see on the ground.

What this looks like in practice

Concretely, the legacy plays that work, in ascending order of ambition:

Documentation backfill. Point an agent at the scariest undocumented service you own and have it produce architecture notes, data-flow descriptions, and an inventory of external dependencies. Then have the closest thing you have to an owner spend a day correcting it. This is the cheapest possible win: pure comprehension, zero production risk, and it de-risks everything else on this list.

Test scaffolding before touching anything. The classic legacy trap is code you can't change because nothing verifies it. Agents are excellent at generating characterization tests — tests that pin down what the system currently does, correct or not. Once behavior is pinned, refactoring stops being terrifying. This is also the step that converts "untouchable" code into code an agent can safely work on later; the test suite you build here becomes the autonomy dial.

Mechanical migrations at scale. Framework upgrades, language-version bumps, API deprecations, lift-and-shift codemods across hundreds of call sites. Bounded, verifiable, mind-numbing for humans — ideal agent work. Run it file-by-file with tests gating every change, not as one heroic big-bang PR.

Actual rewrites — with humans owning the semantics. COBOL to Java, Perl to Python, the monolith seam you've wanted to cut for years. Agents draft translations and surface the buried business rules; your engineers own the decision of which rules are load-bearing and which are fossilized bugs. The failure mode here is well documented: AI can migrate the code, but someone still has to validate the business still works. Budget the validation like it's half the project, because it is.

Why leaders keep missing this

Three reasons, all fixable. First, demos anchor expectations — vendors show greenfield because it's flashy, so pilots get scoped as greenfield, so the ROI conversation never touches the debt ledger. Second, legacy work has no natural champion; nobody volunteers to own the haunted service, so nobody proposes it as the pilot. Third, the wins are unglamorous — "we upgraded the framework and backfilled 400 tests" doesn't make a keynote, even though it might be worth more than any feature you shipped that quarter.

So flip your pilot selection. When you're choosing where to prove out coding agents, don't pick the friendly modern repo where success is easy and teaches you nothing. Pick a contained piece of the codebase everyone avoids. If agents deliver there, you've validated the tool against your hardest terrain and retired real risk. If they struggle, you've learned the actual boundary of the technology — on work you were going to have to do anyway.

The takeaway

The pragmatic question was never "can AI build new things fast?" It's "can AI make the code I already own cheaper to change?" That's where the compounding costs live, and it's where agents are quietly delivering the best returns. Greenfield demos sell the tools. Legacy debt is where they pay for themselves.