How to deliver high-quality software with AI-native development

Two years ago the question from most engineering leaders was whether AI could write production code. That is settled. The questions we get now are harder and more practical: our engineers are releasing three times as much code, our incident count is up, our review queue never empties, and nobody can say whether the codebase is in better or worse condition than it was in January. What do we change.

This guide is the answer we give. It is a step-by-step delivery method, written for the person responsible for the result rather than for the person writing the code. It assumes AI writes most of your code and that this is fine. What it does not assume is that the process you had before still works.

The one fact that explains most of the problems

DORA's 2025 study of nearly 5,000 technology professionals found that 90 percent use AI at work, more than 80 percent believe it has increased their productivity, and 30 percent report little or no trust in the code it generates. In the same report, AI adoption had a positive relationship with software delivery throughput and product performance, and a negative relationship with delivery stability [1]. Google's own summary states the cause directly: faster code writing exposes weak points in the steps that come after it, and without strong automated testing, mature version control and fast feedback, more change volume produces more instability [1].

Read that as a sentence about your team rather than about the industry. Whatever was weak in your delivery process before AI is now the thing that breaks. A test suite that failed at random, which people re-ran twice and then ignored, did little harm at ten pull requests a week. At eighty a week it does real damage. A staging environment that never fully matched production was a nuisance. Now it is the reason a bad change reaches customers.

The uncomfortable version of this: nothing in your process was designed for the current rate of change, and the parts that depended, without anyone saying so, on a human having time are the parts already failing.

AI speeds up some work more than other work, and the evidence is mixed

It is worth comparing two findings, because leaders who only know one of them make predictable mistakes.

The first is the DORA result above: across thousands of respondents, AI is associated with more throughput [1]. The second is METR's randomised controlled trial from July 2025, which took 16 experienced open-source developers and 246 real issues in repositories they already knew well, and found they took 19 percent longer with AI tools than without. The same developers estimated afterwards that AI had sped them up by 20 percent, and had forecast a 24 percent speed-up before starting [2]. METR is careful about what this does and does not show: it is 16 developers on mature codebases they know deeply, and the authors explicitly say it is not evidence that AI fails to speed up most developers [2].

Both can be true, and in our experience both are. AI code writing helps most on unfamiliar work or on new projects started from nothing. It helps less, and sometimes slows people down, on a codebase someone has known in detail for four years. The practical consequence for a leader is that you cannot manage this from single stories or from vendor claims. You need your own delivery numbers, which is why measuring delivery rather than generated output is a full page in this guide rather than a short note.

The second consequence is that self-reported speed is unreliable in both directions. In METR's study the developers were wrong about their own experience by 39 percentage points [2]. Do not base a delivery process on how fast the work feels.

The four things that actually break

Across the teams we work with, the failures fall into four groups, and this guide is organised around them.

The work was never specified well enough to check. An agent will readily build something that satisfies your prompt and fails your intent, then give it to you with confidence and a passing test run. This is not a model problem, it is a specification problem, and it shows up as rework rather than as an error. Fixing it starts with agreeing what done means before anyone generates anything and with breaking work into pieces an agent can finish and you can check.

The gates depend on a human having time. Code review was always the main quality step in most teams. It kept up because the amount of code grew with the number of engineers. It cannot keep up when one engineer can open eight pull requests before lunch. Stack Overflow's 2025 survey of developers describes the problem clearly: the top frustration, reported by 66 percent, is AI output that is almost right but not quite, and 45.2 percent say debugging AI-generated code takes more time than expected [3]. Almost right is the expensive case, because a quick read does not catch it. The response is not more reading. It is gates that block a merge automatically.

The release was treated as the end of the work. When change volume triples, the probability that any given change is the bad one goes up, and the cost of finding out slowly goes up with it. Progressive delivery (releasing to a small share of users first), real measurement of the running system, and a practised rollback stop being signs of an advanced team and start being the difference between a five-minute incident and a five-hour one. That is the third group of pages here, from progressive delivery through to incident response when nobody remembers writing the code.

The codebase grew inconsistent faster than anyone noticed. Six agents working in six sessions will produce six reasonable ways to do the same thing, none of them wrong, all of them different. A year of that is a codebase nobody can understand as a whole, which is exactly the condition under which the next AI-assisted change gets harder rather than easier. Keeping it easy to work in is deliberate work, covered from consistency through refactoring without changing behaviour.

One habit matters most: checking the work

If you take one operating principle from this guide, take this one: never accept work you cannot check, and give the thing doing the work a way to check itself. Anthropic's own guidance for Claude Code says it plainly. Give the model a check it can run, and "always provide verification (tests, scripts, screenshots). If you can't verify it, don't ship it." [8]

That principle has a leadership version. Every unit of work you hand to an agent should arrive with the question already answered: what will prove this is done. If nobody can answer that in one sentence before the work starts, the work is not ready to start, and no model, however capable, will fix it. The full argument for building those checks deliberately, with automated checks written from the specification, is the companion guide on eval-driven development. This guide assumes you are doing that and covers everything around it.

Software supply chain: the risk that came with AI-written code

One risk in this list is new rather than amplified, and leaders consistently underrate it because it does not look like a code quality problem.

Code-generating models invent package names. Researchers at the University of Texas at San Antonio, the University of Oklahoma and Virginia Tech generated 576,000 code samples across 16 models and found references to invented packages in at least 5.2 percent of commercial model output and 21.7 percent of open-source model output, producing 205,474 distinct fake package names [4]. An attacker can register a name that a model often invents. Your agents will then install the attacker's package for you.

This is not theoretical any more. In September 2025 a self-replicating worm spread through the npm registry by stealing maintainer credentials, and CISA issued an alert on 23 September 2025 telling organisations to review dependencies, pin versions to releases produced before 16 September 2025, rotate developer credentials and mandate phishing-resistant multifactor authentication on developer accounts [7]. OWASP's Top 10:2025 added Software Supply Chain Failures as A03, a new category in its own right [5]. Our page on dependency control when an agent picks the packages covers what to actually do about it.

What a team that delivers well looks like

A team delivering well with AI-native development looks ordinary to an outsider, and that is the goal. Work arrives with acceptance criteria a machine can check. Changes are small. The pipeline says yes or no without a person deciding. Releases go out behind a feature flag to a small share of users and are widened when the evidence supports it. The dashboards were written by the person who understood the requirement, not inferred afterwards. When something breaks, the runbook exists and the rollback has been practised. Nobody talks about how many lines were generated.

None of that is new practice. Every one of those habits predates language models by a decade. What changed is that they moved from good practice to essential, because the volume of change they have to control grew several times over while the number of humans reading it did not.

The decisions an agent should never make alone

Not every decision in a delivery process belongs to the same owner, and mixing them up is a common way teams either slow an agent down needlessly or let it make a call it should not.

An agent can decide how to name a variable, which function to extract, and in what order to write a set of similar checks, because those choices are reversible and cheap to redo if wrong. An agent should not decide which database to use for a new service, whether to add a new external dependency the team will maintain for years, or how a breaking change to a public interface gets communicated to the teams depending on it, because those choices are expensive to reverse and often invisible until months later when the cost shows up. The line is not about how hard the decision looks. It runs between what is cheap to undo and what is not.

Drawing that line explicitly, in writing, before an agent starts a piece of work, is what keeps speed from turning into risk in exactly the places speed cannot afford it. The decisions that stay with your engineers covers how to draw it for a real team, including the decisions that look small and are not.

Testing when the same tool wrote the code and the check

A specific failure mode shows up once an agent is asked to write its own tests for its own implementation in the same session: the tests tend to confirm what the code already does rather than what the code was supposed to do. High coverage in that setup measures agreement, not correctness, because both the implementation and the check came from the same understanding of the requirement, including the same misunderstanding if there was one.

The fix is structural, not a matter of asking more carefully. Keep the specification, not the implementation, as the thing the tests are checked against, and get that check from a source independent of whatever wrote the code: a different model run in a fresh context, a human who reviews test cases against the original requirement before looking at the implementation, or both. Test strategy when the AI writes the tests too covers how to structure this so coverage numbers mean what they claim to mean.

Watching a system you did not read line by line

Traditional monitoring assumes the person setting up a dashboard understands the code well enough to guess where it will break. That assumption gets weaker as more of the codebase is generated, because nobody on the team read every line the way they would have if they had typed it themselves.

The practical answer is to instrument around the requirement rather than around the implementation: log and alert on the business outcome the change was supposed to produce, not on the internal function calls that happen to exist in this particular version of the code. A payment flow should have an alert on payment failure rate regardless of which functions the current implementation calls, because that alert survives a refactor that a function-level one would not. What to instrument when nobody typed the code covers what to build before the first incident, not after it.

Documentation that outlives the person who wrote it

A specification and an eval suite tell a reader what the software must do. Neither one explains why a particular approach was chosen over an obvious alternative, and that gap gets wider as more of a codebase is generated across many separate sessions, none of which shares memory with the others.

A short, deliberately kept record of the decisions that would look wrong to someone new, each with its reason and the alternative that was rejected, closes that gap at a fraction of the cost of a full design document nobody reads. It also happens to be exactly what both a new engineer and a future agent need before making a related change, which means writing it once serves two different readers who would otherwise need two different documents. Documentation an agent and a new hire can both use covers what belongs in that record and what does not.

Who owns what, once the typing is not the constraint

Team structure built around who can type the most code stops making sense once typing speed stops being the limit on output. The constraint moves to who can specify a requirement precisely, who reviews for judgment rather than syntax, and who is accountable when a change reaches production and something about it is wrong.

That shift changes what a well-run team's org chart should reward. A team that keeps promoting and structuring around raw output, once output is cheap for everyone to produce, ends up rewarding the wrong skill at exactly the moment a different skill became scarce. Team shape and ownership when agents do the typing covers how ownership and reporting lines should shift alongside the actual bottleneck, rather than staying pointed at where the bottleneck used to be.

What this actually costs, beyond the subscription price

The cost of AI-assisted delivery is the license fee for the tool plus the cost of the checks, the observability, and the incident response capacity that this guide argues have to grow alongside the volume of generated code, or the throughput gain shows up as an incident count instead of as delivered value.

Budgeting for one without the other is how a team ends up with a large tool bill and no corresponding improvement in what actually reaches customers working correctly. Budgeting agent capacity and cost covers what the full cost picture includes, so the number a leader takes to a budget conversation reflects the whole system rather than only the part with a monthly invoice attached to it.

The tool spend itself has its own guides: how to reduce Claude Code token usage for the developer, and what Claude Code costs a team for whoever approves the budget. Both work from Anthropic's own documentation, read on 4 October 2026, and say which figures are Anthropic's.

Where Reveneau fits

This is how we work, so the guide is a description rather than a recommendation. Every line of our code is written by AI, and every change has to pass a large eval suite written from the specification before it is released. The saving from building this way goes into the client's price rather than our margin. If your team is adopting this operating model, or you have already adopted the speed and are now dealing with the consequences, that is a large part of what our AI development and full product build work involves.

If your question is narrower, start with the problem you feel most. Rework and misbuilt features mean you should start with the definition of done. A review queue that never empties means gates. Rising incident counts mean release and operations. A codebase getting harder to change means consistency. And if you want an outside opinion on which of those is actually your problem, talk to us.