Does AI make software teams faster?

On throughput, the 2025 DORA report found a positive relationship between AI adoption and both delivery throughput and product performance, across nearly 5,000 respondents. The same report found AI adoption still has a negative relationship with delivery stability, so more work is released and more of it breaks unless a later check finds the problems.

What does it mean that AI is an amplifier?

AI increases the effect of whatever practice a team already has rather than replacing it. A team with strong automated checks and fast feedback gets faster and stays stable, and a team without them releases its existing problems at a higher rate. A team that used to merge six unverified pull requests a week can find itself merging forty, with the same one reviewer still the only check on what reaches customers.

Why does AI adoption hurt delivery stability?

AI adoption hurts delivery stability because AI writing the code raises the amount of change without raising the team's ability to check it. DORA's own explanation is that without control systems such as strong automated testing, mature version control, and fast feedback loops, an increase in change volume leads to instability. The problem is the control system around the generated code: it did not grow to match the new volume.

Can code review keep up with AI-generated code?

Not on its own, because human review capacity is fixed by hours and attention while generated volume is not. Review is still valuable for decisions that need judgment, but using it as the only check means a person is working out in their head what unverified code does, at a rate no one can sustain.

What is an eval and how is it different from a normal test?

An eval is an automated check written from the specification, before the implementation exists, that proves a stated requirement holds. A test written after the code often encodes what the code already does, which means it can pass while the requirement is unmet. Because an eval is derived from what you said you wanted rather than from the code, it still applies after the code is restructured, and the code must meet a requirement that was set before the code existed.

Why write the check before the code when a model can write both?

If one pass produces the implementation and its tests together, a passing build proves only that the two agree with each other; whether either matches the requirement is still unknown. Writing the check first from the requirement means the code has to meet a requirement set before the code existed. It is the practice behind [adding eval tests was the best decision we made](/insights/adding-eval-tests-was-our-best-decision), and it moves the hard thinking to the start of the work, where changes cost less.

How do I tell if a development partner's speed is safe?

Ask what has to pass before a change reaches your main branch, who wrote that check, and whether it was written before or after the implementation. A specific answer describes a real check; a vague answer about a senior team describes only a hope. A team with a real practice answers in specifics without needing to think about it, since which tools everyone uses tells you nothing anymore.

Can developers tell whether AI is speeding them up?

The evidence says no. In METR's randomized trial with experienced open-source developers, participants were 19% slower with AI tools while estimating afterwards that they had been 20% faster, which is a difference between belief and result large enough that no judgment based on feeling can be trusted. That was true of skilled engineers working in code they knew well, so the only defensible claim about speed is one a team can measure and show the calculation for.

Is the METR slowdown result still accurate?

METR labels those early-2025 results as historical and no longer representative of current tools. A 2026 continuation estimates a speedup for the original group of developers, but with a wide confidence interval and a known problem with which tasks were included, so the lasting lesson is about measurement rather than the specific number.

Does more test coverage solve the stability problem?

More test coverage does not solve the stability problem on its own, because coverage measures lines executed rather than requirements protected, so a high number can exist alongside unverified behaviour. What matters is whether each requirement that would hurt you if broken has a check that fails when it breaks, derived from the specification rather than from the code that already exists.

What should we fix first if our delivery is unstable?

Fix the check before a merge first, and only then raise the volume, because raising output through a weak control system makes the instability worse. Pick the few behaviours that would cost you most if they broke, write checks for those from the requirement, and make them block a merge.

Does any of this mean we should slow down?

None of this means a team should slow down. It means speed has to come from good checks, and the team should keep its stability while getting it. Once each change is checked automatically against checks written from the specification, moving faster stops adding risk, which is the only kind of speed worth paying for. The new tools raised the top speed of every team at once; each team still has to build its own minimum level of quality.

AI is an amplifier, not a fix: Reveneau

Every supplier you talk to this year will tell you that AI makes them faster. It is a true statement and a useless one, because it is now true of everybody. The 2025 DORA report, which surveyed nearly 5,000 technology professionals, found that 90% of respondents use AI at work. Speed is no longer a differentiator between teams. What separates them is which checks the work must pass before it reaches production.

The same report has two findings that people tend to quote separately, and they should be read together.

The first: "Unlike last year, we observe a positive relationship between AI adoption on both software delivery throughput and product performance." The second, in the next sentence: "However, AI adoption does continue to have a negative relationship with software delivery stability."

Read that as one sentence. Teams using AI release more, and more of what they release breaks. Both are happening at once, to the same teams, right now.

1. Amplifier is the right word

DORA's own framing is that AI acts as an amplifier, making the strengths of a strong organization and the weaknesses of a struggling one larger. That conclusion is the most practically useful thing in the report, because it tells you where to look.

If a team had a habit of merging changes nobody had verified, AI does not introduce that habit. It just runs it at a rate the old process was never designed for. A team that used to open six pull requests a week now opens forty, and the same one reviewer is still the only check before the code reaches the customer. Nothing about that person changed. Their workload went up by a factor of six.

The report says exactly why this ends the way it does: "AI accelerates software development, but that acceleration can expose weaknesses downstream. Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability."

Note what that sentence does not say. It does not say the generated code is bad. It says the volume is higher and the control system did not grow with it. Those are different problems, and only one of them is fixable by choosing a better model.

2. The check before a merge is the whole answer

So the question worth asking a team, whether it is yours or a supplier's, is not which tools they use. Everyone uses the same three, and the answer tells you nothing.

The question is: what has to pass before a change reaches the main branch, and who wrote it?

There are only a few honest answers.

A person reads it. This is where most teams are, and it is the answer that sounds most responsible while working worst as volume grows. A reviewer looking at a diff that nothing has verified is checking the logic in their head, at volume, under time pressure. It works at six pull requests a week. At forty it stops working, and nobody notices, because what goes wrong is that the reviewer starts saying yes faster.

A test suite runs. Better, and it depends entirely on where those tests came from. A suite written after the implementation tends to encode what the code already does. It will pass on a feature that never matched the requirement, because no step in the process ever checked the requirement.

A suite written from the specification, before the implementation existed. This is the one that changes the problem. The check is derived from what you said you wanted, so the code has to meet a requirement set before the code existed. A change either passes it or is not released, and that decision takes no human time at merge time.

This is the practice we build on, and we have written up what it cost us to adopt in adding eval tests was the best decision we made. The short version is that it moved the hard thinking to the start of the work, where changes cost less, and made the merge itself routine. Routine merges are the goal. A merge that depends on one reviewer's extra effort will one day be done by a tired reviewer at the end of a long week.

If you want a longer explanation, the eval-driven development guide covers how to build a suite, what to check first, and how to stop it from growing into two thousand checks nobody trusts.

3. You cannot feel the difference, so stop trying

Here is the finding that should make everyone cautious about their own judgment.

METR ran a randomized controlled trial with 16 experienced open-source developers across 246 real issues, in their own repositories, which averaged more than 22,000 stars and a million lines of code. Before starting, the developers expected AI tools to speed them up by 24%. After finishing, they estimated they had been sped up by 20%.

They were 19% slower.

Think about the size of that difference. These were experienced engineers, working in code they knew well, and their sense of their own productivity was wrong by roughly forty percentage points, in their own favour.

Two honest caveats, because people often quote the number wrongly. METR itself now labels that result historical and says it no longer reflects current tools. Their 2026 continuation estimates a speedup of 18% for developers from the original study, but with a confidence interval running from -38% to +9%, and they openly name a problem with which tasks were included: between 30% and 50% of developers said they were choosing not to submit tasks they did not want to do without AI.

So do not use this to argue that AI slows people down. Use it for the thing it actually establishes, which no update changes: nobody can feel their own throughput accurately when their tools change. Not the developers, not their manager, and not the supplier telling you they are three times faster now.

Which means the only defensible claim about speed is a measured one. If a team cannot tell you how they know, they do not know. They feel it, and the evidence on feelings here is not good.

What this looks like in practice

If you are running the team, the order matters. Fix the check before a merge, and only then raise the volume. Raising output through a weak control system is how you get the DORA outcome: more released, more broken, and a growing sense that the tools made everything worse when what they did was show what was already weak.

Start small. Take the few behaviours that would genuinely hurt you if they broke, the payment process, the permission check, the data your customers would notice going missing. Write a check for each one from the requirement, not from the code. Make it block a merge. That is a small suite, and a small suite that blocks a merge on the right things is better than a large one that blocks nothing, which is the argument we make at length in how many tests does AI-generated code need.

If you are buying the work, the question for checking a supplier is short enough to ask on a first call. What has to pass before a change reaches our branch? Who wrote that check, and did they write it before or after the implementation? What happens when it fails?

A team with a real practice answers in specifics and does not need to think about it. A team without one will talk about their seniority, their culture, and how careful they are. Carefulness is a personality trait. A control system is a set of checks, and only the checks keep working in a bad quarter.

Our own answer, so you can check that we keep to it: all of our code is generated, every change has to pass an eval suite written from the specification before it reaches your branch, and the checks come from the requirement rather than the implementation. That is the entire reason we can move as fast as AI writes code and still take responsibility for what we release. If you want to test that claim, ask us.

The new tools raised the top speed for everyone at once. Each team still has to build its own minimum level of quality.

Sources

Announcing the 2025 DORA Report, Google Cloud. Survey of nearly 5,000 technology professionals: 90% AI adoption, positive relationship with throughput and product performance, continued negative relationship with delivery stability.
DORA State of AI-assisted Software Development 2025, DORA. The amplifier framing.
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR. 16 developers, 246 issues, 19% slowdown against a forecast 24% speedup and a self-reported 20% speedup.
We are Changing our Developer Productivity Experiment Design, METR. The 2026 continuation, its confidence intervals, and the selection effects the team names.

AI is an amplifier, not a fix