You don’t need fewer engineers. You need a different team.

The pitch every founder has heard by now is that AI means smaller engineering teams. Fewer people, same output, better margins. It is an appealing story and I do not think it is true — or rather, it is true in a way that will cost you if you act on it literally.

What has actually happened is narrower and more interesting. The constraint moved. It used to sit on producing code; now it sits on verifying it. Team design that was correct in 2022 is quietly wrong in 2026, and most of the damage shows up somewhere other than where it was caused.

The numbers are not ambiguous

Roughly 90% of developers now use AI tools, and about 41% of committed code is AI-generated. Everyone knows that part. What gets less attention is what it has done to delivery.

DORA’s 2025 research found AI adoption improved throughput by an estimated 2–18% — real, but far short of the marketing — while making delivery measurably less stable. Change failure rates went up. Median time in code review rose by 441%. And 31% more pull requests merged with no review at all.

A team can feel faster at the keyboard while getting slower as a delivery system. That gap is the defining management problem of the next few years.

Read those two review numbers together, because they describe one behaviour. Review time went up because the queue got longer, and then some of the queue stopped being reviewed at all — not by policy, but because a human being looked at a 900-line diff at five o’clock and approved it. That is not a tooling failure. That is a system under load doing what systems under load do.

The constraint moved, so the team shape has to

If writing code is the bottleneck, you hire producers and you optimise for throughput per engineer. That was a defensible strategy for a long time. If verifying code is the bottleneck, that same hire makes things worse: you have added supply to the part of the pipeline that was already fast, and more load to the part that was already backed up.

The shape has to change in three ways, none of them exotic:

• —Your senior-to-junior ratio matters more than your headcount. Not because juniors are less useful — they are more productive than they have ever been — but because the scarce commodity is now the judgement to say “this looks right and is wrong”, and that is the one thing the tools cannot supply.
• —Review capacity becomes a resource you plan, not a courtesy people fit around their real work. If review is the constraint, treating it as unpaid overhead is the single most expensive decision available to you.
• —Ownership boundaries need to be tighter. Reviewing code in a system you know well is a ten-minute job. Reviewing code in a system you have never touched, that someone generated in an afternoon, is not really review at all — it is a rubber stamp with extra steps.

The junior engineer problem nobody says out loud

AI adoption clusters around junior engineers. It makes their output look senior almost immediately, which is genuinely good — they ship, they contribute, they feel effective in month one instead of month six.

The difficulty is that the output improved and the judgement did not. The traditional mechanism by which an engineer developed taste — writing something bad, having it picked apart in review, writing it better — has partly been short-circuited. They are producing code that survives review because it looks conventional, without having gone through the thinking that would let them tell whether it is right.

This does not mean hire fewer juniors. It means the apprenticeship has to be deliberate now, because it no longer happens as a by-product of the work. Pair them. Make them defend code they generated in review. Ask “why this?” about lines they did not personally type, and keep asking until the answer is theirs.

What I changed at Propelr

I rolled AI tooling out across the engineering team at Propelr this year, and the useful lesson was not about the tools. Choosing them took a fortnight. Working out what they were doing to us took months — which ones actually earned their licence, where they quietly made things worse, and what had to change in review and release practice once a meaningful share of our code had never been typed by a human.

Everyone benchmarks the assistants. Almost nobody re-examines what happens after the code exists, and that is where all the risk moved.

Measure the thing that broke

DORA’s four metrics are still the right foundation, but on their own they will not show you this. If AI is generating a third to two-thirds of your committed code, you need to watch the verification path directly:

• —Time in review, split from total lead time — the aggregate hides it.
• —The share of pull requests merging with no comments at all, which is the most honest proxy for whether review is real.
• —Change failure rate and rework, because that is where the cost of unreviewed volume actually lands.
• —Diff size distribution. If your median PR got twice as large this year, your review process is now doing twice the work per approval and nobody scheduled that.

The uncomfortable conclusion

A team that adopts AI without changing how it reviews, tests and releases will produce more code, ship it at roughly the same rate, and break things more often. Every one of those effects is invisible on a velocity chart, and two of them look like success.

The teams that get the compounding benefit are the ones that treat this as an engineering management problem rather than a tooling one. Which is inconvenient, because tooling can be bought in an afternoon and management cannot.