AI Coding Agents on Legacy Code: What Actually Works

When a mathematician of Terry Tao's caliber writes about using coding agents on both old and new software, it's worth paying attention — not because of who he is, but because of what he observed.

The short version: modern AI coding agents are genuinely useful on legacy codebases, not just fresh ones. That's a meaningful shift in how operators and engineering leaders should be thinking about where these tools apply.

The Greenfield Bias Is a Real Problem

Most of the demos you've seen for AI coding agents start from a blank file. "Watch me build a full-stack app in 12 minutes." That's great for marketing. It's not representative of the work most teams actually face.

The vast majority of valuable software in the world is old software. It has quirks, undocumented decisions, and dependencies that made sense in 2014. The assumption has been that AI agents struggle with this — that context windows fill up, that the model hallucinates APIs that no longer exist, that it can't hold the shape of a large legacy system in its head.

That assumption is getting stale.

What Coding Agents Are Getting Right on Old Code

Current-generation coding agents — the ones built on models like Claude Sonnet or GPT-4o with large context windows and tool-use — are meaningfully better at legacy work than their predecessors for a few concrete reasons.

First, they can read before they write. A well-prompted agent will grep the repo, trace call paths, and read related files before touching anything. This reduces the "confident but wrong" failure mode that plagued earlier attempts.

Second, they handle narrow, bounded tasks well. "Refactor this one function to add retry logic" is a task a coding agent handles reliably. "Modernize the entire auth system" is not — at least not in one shot. The operators getting value here are breaking work down, not handing over the whole repo.

Third, evals are easier on legacy code. If the existing tests pass and the behavior matches, the agent did its job. Legacy code often has more test coverage than people assume (or more observable behavior to check against), which makes it easier to verify agent output.

Where It Still Breaks Down

Being honest about the failure modes matters more than the hype.

Coding agents still struggle with implicit organizational knowledge. Why is this function doing three things at once? Because of a decision made in 2019 to avoid a database migration that would have taken two weeks. The agent doesn't know that. It will clean up the function and introduce the bug you were avoiding.

They also struggle with large surface area changes. If a refactor touches 40 files, the agent's coherence degrades. Drift between files, inconsistent naming, partial migrations — these are real outputs you'll get if you push scope too far.

And they struggle with test-free zones. If there's no way to verify correctness, you're flying blind. The agent will produce confident, plausible, wrong code with no signal that anything is broken.

The Practical Framework: Old Code, New Tasks

The framing that's actually useful for operators isn't "AI for new apps" vs "AI for old apps." It's: what is the task, how bounded is it, and how verifiable is the output?

A coding agent adding a new webhook endpoint to a five-year-old Rails app is a well-bounded task with a verifiable output. That's a good candidate. A coding agent rewriting the billing logic because it's "messy" is neither bounded nor easily verifiable. That's not.

Before you point an agent at your codebase, it's worth mapping which parts of your software carry real automation opportunity. Our free AI Opportunity Audit can help surface the highest-impact starting points from just your existing setup — useful if you're not sure where to start.

What This Means for Your Stack

If you've been waiting to apply AI agents to your software until you have a greenfield project, you're waiting for something that may never come. The more productive question is: which tasks in your existing systems are bounded enough, verifiable enough, and high-enough-value to be worth running through an agent workflow?

The tools are ready for that conversation. The gap now is mostly in how teams frame the problem.

Start narrow. Verify everything. Expand scope only after you trust the output on smaller tasks. That's the playbook that's actually working in production.

Want This Built for Your Team?

If you want to figure out where AI agents fit your existing software stack, book a call. We work through what's actually worth automating before writing a line of code.