We Measured AI Coding 'Productivity' Across 32 Teams. It's Complicated.

Everyone has a strong opinion about whether AI coding assistants make engineers faster. Almost nobody has data past their own vibes. So we pulled six months of activity from 32 teams that gave us access, ran the numbers, and found something neither the boosters nor the doomers will love.

Methodology, because we're not going to hand-wave

We looked at 32 engineering teams (ranging 4-40 engineers), all using AI assistants daily, from January to June 2026. We instrumented four things per engineer, per week:

• Merged PRs (throughput proxy)
• Cycle time from first commit to merge
• Revert + hotfix rate within 14 days of merge (quality proxy)
• Self-reported focus hours via a weekly one-click survey (n=1,847 responses)

We normalized against each team's own pre-adoption baseline rather than comparing teams to each other, because comparing a fintech monolith to a greenfield startup is malpractice.

The headline number

Median throughput gain: 18%. Not 10x. Not zero. Eighteen percent more merged PRs per engineer-week, sustained.

But the median hides everything interesting. The distribution was brutally bimodal:

• Top quartile: +41% throughput
• Bottom quartile: -6% — yes, negative

The teams that got slower weren't using worse tools. They were using the same tools differently.

What separated the +41% from the -6%

Three variables explained most of the gap.

1. Test coverage before adoption. Teams above 70% coverage got a median +34%. Teams below 40% got +4%. The reason is obvious in hindsight: AI writes plausible code fast, and without tests, "plausible" ships. The bottom teams spent their speed gains debugging confidently-wrong code in production.

The AI didn't make good teams good. It made their existing discipline pay compound interest.

2. Review culture. Teams that kept human review rigorous held their revert rate flat (2.1% before, 2.3% after). Teams that let AI-generated PRs sail through saw reverts climb to 5.8% — and that rework ate the throughput gains whole.

3. Task type. Boilerplate, glue code, and test scaffolding: +50% and up. Novel architecture and gnarly debugging: statistically indistinguishable from zero. The tools are a throughput multiplier on the work that was already mechanical.

The quality asterisk nobody quotes

Aggregate revert rate rose from 2.4% to 3.6% across all 32 teams — a 50% relative increase in things breaking. That's the cost side of the ledger that the productivity headlines skip. Faster isn't free; it front-loads velocity and back-loads a specific, measurable tax in hotfixes.

Teams that netted out ahead paid that tax deliberately: more tests, tighter review, AI pointed at mechanical work. Teams that pretended the tax didn't exist paid it anyway, with interest, in incident channels.

What this means if you run a team

Stop asking "does AI make us faster." Wrong question. Ask:

1. Is our test coverage high enough to catch confident nonsense? Below 50%, fix that first — it's the highest-leverage move.
2. Are we reviewing AI PRs harder or softer than human ones? It should be harder, and most teams do the opposite.
3. Are we pointing the tools at boilerplate or at the hard 20%? The gains live in the boilerplate.

The honest takeaway

The +18% median is real and worth having. But it's a discipline multiplier, not a discipline replacement. It rewards teams that already had tests, review, and taste, and it quietly punishes teams that didn't by helping them ship their mistakes faster.

The 10x-engineer crowd is selling the top quartile as the average. The AI-is-useless crowd is quoting the bottom quartile as the ceiling. The truth is a boring, actionable 18% — and which side of it you land on is almost entirely about the engineering habits you had before you ever installed the thing.

No hype. Just the commit log.