You do not need an AI-native project to start working with agents

Most writing about coding agents is written for projects that started last month. Clean stack, no history, a team that agreed the rules before the first commit. The systems we are asked to work on look nothing like that. They are four, seven, twelve years old. Test coverage is uneven. The documentation describes a version of the product that shipped two rewrites ago. Somewhere in there is a module nobody wants to touch, and the person who wrote it left in 2022.

The board asks why the team is not using AI yet. The team knows that pointing agents at this codebase will produce a lot of code quickly, and that somebody will have to review all of it.

Both sides are right. The way through is to change how work is specified before changing who writes it, one feature at a time.

Why does dropping an agent into an existing system go wrong?

Because the bottleneck moves instead of disappearing.

METR ran a randomised controlled trial with 16 experienced open-source developers on 246 real issues from their own repositories, codebases averaging over a million lines and 22,000 stars. Developers forecast that AI tools would speed them up by 24%. Afterwards they believed they had been sped up by 20%. The measurement showed they took 19% longer with the tools than without [1].

That headline has since moved, and it is worth saying so rather than quoting the number that suits the argument. METR ran the study again on late-2025 tooling, across 57 developers, 143 repositories and more than 800 tasks, and this time measured a speedup: 18% for the developers who had taken part before, 4% for the newly recruited ones. They also called the result very weak evidence and are redesigning the experiment, because developers increasingly declined to take part rather than work without AI, and avoided submitting the tasks where they expected AI to help most [2]. The direction reversed. The confidence did not improve.

What survives both rounds is the gap between what the developers believed and what was measured, in whichever direction it ran. That gap is the thing to design around.

DORA's research on AI-assisted development points at the same problem from a different direction. Higher AI adoption correlates with higher delivery throughput and higher delivery instability together: more change failures, more rework. Around 30% of developers report little or no trust in code generated by AI, while more than 80% believe it made them more productive [3]. DORA's framing is that AI amplifies what an organisation already has [4]. Teams with a solid internal platform, clear workflows and real testing get a collaborator. Teams with fragmented tooling and fragile infrastructure generate technical debt faster. Time saved writing the code is spent again auditing it.

There is a third signal, from a vendor with unusual data. GitClear, which sells code analysis, published telemetry showing copy-pasted lines rising from 8.3% of changes in 2021 to 12.3% in 2024, while the share of changed lines associated with refactoring fell from 25% to under 10% across the same period [5]. The interpretation is theirs, and they sell a product that addresses the problem they describe. We see the same thing in review. An agent will add a new block where a human would have gone looking for the function that already does the job, because the agent cannot hold the whole system in view at once.

The evidence supports a narrow claim: the value shows up when somebody can tell, cheaply, whether the output matches what was asked for. On a system with no written rules and no stated intent, that check is manual, slow, and the first thing to be skipped when a release is due.

Step one: write down the rules your code already follows

The constraints come first, then the feature.

The artefact that matters first is a short document setting out the project's principles: what this codebase does and does not do, how it is structured, what has to be true of any change. Testing expectations, accessibility requirements, branching and review rules. The important part is that you are mostly transcribing, not deciding. A system running in production has already made these decisions. They live in the heads of two or three people and in the shape of the code.

Two things make this harder than it sounds.

The first is that an existing codebase is full of patterns you do not want repeated. An agent reads what is there as the house style, including the module nobody wants to touch. So the principles have to name explicitly what is off the table, alongside what is expected.

The second is ambition. In one of our internal sessions, a colleague demonstrating this workflow wrote a principle into the constitution requiring WCAG compliance, then watched the agent start pulling in the entire standard. He spotted it live and stopped the run. A rule written as an ideal costs more than no rule at all, because the agent will try to satisfy it fully on a task that never needed it. Principles have to be checkable and bounded, and where you knowingly break one, the exception belongs in writing with its reason.

This step takes the longest. It is also the only part you do once.

Step two: specify the next feature, not the system

You start specifying with the next piece of work. Code that already works stays as it is.

The specification covers behaviour in the language of whoever asked for the feature: user scenarios, edge cases, what counts as done, and an explicit statement of assumptions. The assumption that matters here is the one people skip: this feature is part of a system that already exists, most of which was written by humans, and it has to fit that system rather than replace it. Say so in the document. The agent has no other way to know.

The technical decisions go in a separate document from the behaviour. Stack, storage, testing approach, structure. Keeping them apart is what lets the person who requested the feature read the first document and say yes or no to it. That is the whole point.

Then the work breaks into ordered tasks, each tied back to a story, with the ones that can run in parallel marked as parallel. Nothing about this requires the rest of your system to be specified. Next month's feature gets its own set, in its own directory.

Step three: close the loop before the change is merged

Three checks earn their place on an inherited codebase.

Before planning, a clarification pass reads the specification back to you and asks about the gaps and contradictions you did not notice writing. Once the tasks exist and before implementation starts, a consistency pass checks the documents against each other. Afterwards, a convergence pass compares what was built against what was asked for, and that is where you find the requirement that quietly did not make it.

Alongside those, one discipline from ordinary engineering carries more weight than it used to: keep the change small. A change of fifty files does not get reviewed, it gets approved. Phase by phase, story by story, with a commit and a pull request per unit of work, is what keeps human review possible. The code is yours, whoever typed it, and review is how it stays yours. That responsibility sits with you even when a supplier writes the code, which is worth settling in writing before the project starts. We have written elsewhere about who does what when you work with an agency.

What do you have after a year of this?

A record of intent, which is the documentation nobody ever gets to write.

Each feature leaves its specification, its plan and its task list in the repository, dated, alongside the commits. Leave them as they were written, untouched by later edits. They answer the question that costs the most time on a long-lived system: why does this work the way it does, and what were we trying to achieve when we built it.

On a system with staff turnover and several suppliers over its life, that record is worth having even on the days the agents are unhelpful. If you have ever tried to map an ecosystem before integrating into it, you already know what its absence costs.

When is this not worth doing?

On a small change, this costs more than it returns, because writing the specification takes longer than writing the code and you feel that on the first attempt. The threshold is scope: several people, several moving parts, more than one repository, work that would otherwise need a meeting to align on.

Two other things are worth knowing before you start. The default task templates in these toolkits treat test tasks as optional unless the specification asks for them, so if testing matters to you, say it in the principles and again in the specification. Review also stays where it is: every generated artefact gets read before the next step runs on top of it, and the implementation gets reviewed like any other pull request. The teams that get value here treat the generated documents as drafts by a fast junior colleague rather than as finished work.

What we intend to do with this

We have run this end to end once already: one epic for a telecom client, across three applications, split into five or six tickets that people picked up separately and implemented with agents against a shared set of documents. The documentation was heavier than that job needed. It also left very little room for the agents to invent things, and it made it possible for several people to work in parallel without stepping on each other.

Our intention now is to pick one existing client system, one where the configuration rules are involved enough to repay the cost of writing them down, and run the next feature through this process rather than the whole backlog. If it holds, it becomes how we work on systems we inherit.

The toolkit we used for the demonstration is GitHub's Spec Kit, which is open source [6], and the sequence it enforces is the part worth copying: principles, behaviour, technical plan, ordered tasks, then implementation with a check at the end. Several other toolkits arrange the same steps differently.

Frequently asked questions

Is spec-driven development just waterfall with new names?

No, because you specify one feature at a time rather than the whole system upfront. Each feature gets its own directory and its own documents, and the earlier ones stay in the repository as a record rather than as a plan you are still bound by.

Do we have to document our existing system first?

No. You write down the principles the code already follows, which is a short document, and then specify only the next feature with an explicit assumption that the system already exists.

What happens when we change the AI model or tool?

The rules and specifications live in your repository, so they carry over. That is the practical argument for keeping this layer in version control rather than in a vendor's chat interface.

Does this remove the need for code review?

No. It changes what review covers. Every generated document is read before the next step runs on it, and the implementation is reviewed like any other pull request.