Coding agents on a fifteen-year-old codebase
The objection surfaces in the first meeting, every time: our codebase is fifteen years old, half-tested, full of tribal knowledge, running a framework two generations behind. Surely AI agents on a legacy codebase is a bad idea; the demos all show pristine greenfield repos. The intuition sounds right and points exactly backwards. Legacy systems are where we have seen coding agents deliver some of their highest returns, precisely because legacy work is the work nobody wants and everybody defers.
What a legacy codebase changes is which tasks you hand agents first, and how strong the rails need to be.
Why a legacy codebase is high-leverage territory for agents
On a greenfield project, an agent competes with motivated humans doing pleasant work. On a legacy system, it does the opposite: absorbs the unpleasant, unglamorous work that has been rational to postpone for a decade. Reading ten thousand lines of undocumented code to map what actually happens is soul-crushing for an engineer and cheap for an agent. Writing the four hundred tests a module never had is a quarter’s worth of grind for a team and a supervised week for an agent. The economics of drudgery flipped, and nowhere is there more accumulated drudgery than in an old codebase.
There is a second, less obvious reason. The constraint on legacy work was never typing speed; it was that every hour spent on it was an hour taken from the roadmap. Agents relax exactly that constraint, which is why the refactors and migrations nobody ever staffed are suddenly getting done at all.
Start with characterization tests
The first delegation on any legacy system should be characterization tests: tests that pin down what the code currently does, bugs and quirks included, without judging what it should do. This is the classic move from Michael Feathers’s Working Effectively with Legacy Code, and it used to be prohibitively boring. Now an agent drafts them by the hundred, and your engineers review assertions instead of writing them.
It is the ideal first task for three reasons. It is safe: characterization tests observe behavior, so a bad one cannot break production. It is verifiable: the tests either pass against current behavior or they do not. And it compounds: every other thing you want agents to do on this codebase needs a harness to keep it honest, and this builds the harness. More generally, tests are the first thing worth delegating on any codebase; on a legacy one they are also the prerequisite for everything else.
Documentation archaeology
The tribal knowledge problem inverts nicely too. Instead of asking your veterans to finally write the documentation (they will not, they have not for fifteen years, and they are not wrong about their priorities), have an agent read the code and draft it: module maps, data flows, the inventory of jobs and endpoints, the "why would this table have two owners" notes. Then the veterans correct drafts instead of authoring from scratch, which is an order of magnitude less effort and actually happens.
Route the output somewhere useful: the best of it becomes the context files agents read before touching your code, so every future session starts already knowing what the archaeology uncovered. On systems where the people who wrote the core are approaching retirement, we would rank this extraction work above any feature as a use of agent capacity.
Small migrations, incremental modernization
With a harness in place, the modernization backlog opens up: dependency upgrades, incremental type coverage, dead code removal, translating the last stored procedures, strangler-pattern extractions. The selection rule is that agent-shaped work is mechanical, repetitive and verifiable. A thousand nearly identical changes with tests to confirm each batch is the perfect shape. A big-bang architectural rewrite is the opposite of the shape, with or without AI.
The rails, because legacy punishes confidence
Old systems are old because they encode years of undocumented decisions, and they punish confident changes. Agents are nothing if not confident. So the rails are non-negotiable: characterization tests before any behavior change, small diffs reviewed by someone who knows the system, no schema or data migrations without a human driving, CI as the hard gate. Most of this is generic hygiene, and making a codebase agent-ready takes about a week even when the codebase predates the practices involved.
If your engineering strategy has a "modernize the legacy platform" line that has rolled over for three consecutive years, agents are the first thing that changes its economics. We scope that work, build the rails and run the first supervised weeks; the fifteen-year-old codebase is, honestly, our favorite place to start.