Using AI on an existing codebase without handing over ownership
AI agents can do real work on an old codebase. One way to get the benefit without losing control is small but fast changes, read by a person.
Owners of established software products are hearing that AI can transform how their code gets written. The serious version of that promise gives the agents a great deal of autonomy, held in check by tight guardrails, automated tests and a governance loop that tells the tools what they’re getting right and what they’re getting wrong. Done well, it can work. It’s also hard, complex, and asks for a lot of trust up front. For a product that has paid the bills for twenty years, where the code was written carefully and the people who understood it may have gone, that’s a big step to take in one go.
There’s a less dramatic route that still delivers a large productivity gain. AI agents take on much of the work while a person keeps hold of every decision. It has a second benefit that matters just as much for an ageing product. Newer developers can make changes they’d previously have shied away from, and learn how the system works as they go. What follows is the way of working that made that true on a recent engagement, moving a twenty-year-old .NET product with no automated tests and no original developers from a single server onto managed cloud hosting. The wider story of that client is in Planning the modernisation of a safety-critical SaaS product.
Small, fast changes, read by a person
The whole method rests on one rule. Every change is small enough that a person can read every line before it’s accepted. Small changes are also fast changes. The agent makes one in minutes, the review takes minutes, and the next one starts straight after. Over a day that adds up to a lot of reviewed, finished work. The productivity gain comes from the rate of small changes rather than the size of any one of them.
A real cost of this rate is the strain on the person doing the reviewing. Each change is small, but reading them carefully all day is tiring in a way that writing code isn’t. The wider effects of AI-assisted coding on developers are still being studied. The fatigue I can vouch for personally, and I’ve read and spoken to plenty of others who feel the same.
An agent can be asked to make a change of any size, and it’ll happily attempt the whole migration in one go. The result would be hundreds of altered files and no honest way to say what had changed or why. So the work starts with the agents reading the codebase and flagging what needs attention, and that becomes a written plan, broken into phases and sub-tasks with a narrow brief for each. The plan sits in the repository beside the code, so the record of what was done and why remains beside it.
At the end of each phase the changes are reviewed in git, the tool that keeps a record of the codebase. Git shows a view of exactly which lines were added, removed or altered. This view is called a diff. If the diff is too big to read properly, the phase was too big. The change is reverted, the phase is split further, and the agent runs it again. Because each change is small, throwing one away costs very little, which is what makes the discipline easy to keep. Resisting the urge to accept a large change because it looks plausible is the discipline the whole approach depends on.
The agent will sometimes do more than it was asked. On this engagement it would tidy neighbouring code or refactor something it judged untidy. Some of that was probably an improvement, but it was reverted anyway and guidelines were tightened. The idea is to keep the changes small, atomic, understandable, and auditable.
Tests on their own aren’t enough
The high-autonomy approach rests on the idea that reading each change becomes unnecessary once the automated tests and guardrails are tight enough. That may hold for a new codebase built with tests from the first day. An established product is different. Twenty years of carefully written code can carry behaviour that no test describes, and in this case there were no automated tests at all to begin with.
Agentic coding is a spectrum, from full review at one end to full trust in the tooling at the other, and the right place on it depends on the codebase. An old one sits at the review end. A small test suite, added early and run on every change, catches the obvious breakages. Tests added over time build confidence in the automation, and as they prove themselves the dial can move. It doesn’t replace the person reading the diff.
The knowledge stays with the business
The deeper concern for an owner is ownership. As the original developers leave, their understanding of the system and its quirks leaves with them. Handing the code to a tool doesn’t solve that. It makes it worse, because now nobody understands the system.
AI can help with the understanding, within limits. Agents made onboarding onto the codebase much quicker, mapping how things fit together. The learning still had to be done by a person, reading the code, asking the retiring developers and writing down what was found. That learning is what makes the diffs reviewable.
Where a change raised a question the code alone couldn’t answer, it was set aside with a note, and those notes became decisions for the business. Each decision was written up as a short record in the repository, with the options considered and the reasoning. Those records are there for whoever works on the system next, and the agents read them too, so the context they start each task with grows as the work goes on.
What an owner should know
The agent wrote most of the code on this engagement. A person decided every change, could explain every line that shipped, and threw away everything that couldn’t be explained. The business ended up understanding its product better than it did at the start.
That’s a standard any owner can hold AI-assisted work to, and it only takes a few questions. How big are the changes? Who reads them before they’re accepted? What happens when the tool does more than it was asked? Where are the decisions written down? Who understands the system now, and who will next year?
The general case for staging this kind of work is in Modernising legacy SaaS without a big-bang rewrite. For a product in a similar position, a short exploratory conversation is a sensible first step.