Here’s an uncomfortable stat to bring to your next planning session: according to Faros AI telemetry published this week, engineering teams with high AI adoption have seen code churn — lines deleted shortly after being written — increase by 861%. At the same time, engineering managers report 80–90% code acceptance rates. Both numbers are real. They are measuring completely different things. And the gap between them is where the AI productivity story actually lives in 2026.
The metric we’re celebrating is the wrong one
The productivity narrative around AI coding tools has been built almost entirely on input metrics: tokens consumed, suggestions accepted, PRs created. These are visible, easily dashboarded, and satisfying to report upward. They are also deeply misleading.
TechCrunch coined a term for this pattern in April 2026: tokenmaxxing — the tendency for developers to maximize their use of AI-generated code without adequately scrutinizing quality. GitClear’s data shows regular AI users average 9.4x higher code churn than non-AI counterparts. That apparent 80–90% acceptance rate? When you factor in post-acceptance churn — code accepted and then deleted or rewritten within days — the real-world figure drops to 10–30%.
Meanwhile, a randomized controlled trial published in September 2025 found that experienced developers working on their own mature codebases were 19% slower with AI coding tools than without them. Contrast that with the lab studies showing 51% speed gains in synthetic tasks, and you begin to see the credibility problem: the benchmark conditions bear almost no resemblance to real enterprise engineering work.
Amdahl’s Law applies to AI pipelines too
There is a best-case scenario for AI-enabled engineering. VentureBeat documented a case of teams achieving 170% throughput at 80% of their previous headcount. Daily AI users merge approximately 60% more PRs. These numbers are real too — and they come with a critical footnote buried in the same report: achieving them requires modernizing the entire development pipeline, not just the coding step.
This is Amdahl’s Law in practice. AI makes one part of the system dramatically faster. Everything else runs at human speed. Faros AI’s analysis of 10,000+ developers across 1,255 teams makes this concrete: AI adoption increased PR merge rates by 98% — but PR review time surged 91%, and average PR size grew 154%. The bottleneck didn’t disappear. It moved downstream to code review, QA, and deployment, where it now creates a larger pile-up than before.
Enterprises that bought AI coding tools without rebuilding review and testing pipelines bought a faster car with no road. The throughput gains exist, but they require infrastructure investment that most organizations haven’t made.
The hidden tax nobody budgeted for
There is another cost that doesn’t appear in any dashboard. Stack Overflow’s 2025 Developer Survey found that 66% of developers cite “almost right” AI output as their top frustration, and 45% report that debugging AI-generated code takes longer than expected. More developers actively distrust AI accuracy (46%) than trust it (33%). Only 3% report highly trusting AI output.
That verification overhead — reading, testing, correcting code you didn’t write — is real work. It shows up in sprint velocity and in burnout, not in the token dashboard. It’s the gap between what teams report feeling (“we’re using AI everywhere”) and what the system actually produces.
The internal divide that the averages hide
Here is perhaps the most important number in the AI productivity conversation: OpenAI’s analysis of 7 million enterprise seats (December 2025) found a 6x productivity gap between AI power users and the median employee in the same organization, using the same tools. For custom workflows, that gap widens to 7x.
This means that the productivity wins being reported at the organizational level are real — but they are concentrated in a small group of power users, while the majority of the team sees flat or negative returns. The aggregate number looks positive. The distribution tells a different story.
Spotify’s case illustrates the best-case ceiling. Its co-CEO disclosed in February 2026 that the company’s top engineers hadn’t written a line of code since December, operating entirely through an internal system called “Honk.” Spotify shipped 50+ new features in 2025 under this model. That outcome is real — and it required years of internal tooling investment, a culture of experimentation, and organizational structure built around it. Most enterprise teams are not Spotify. The gap between the showcase case and the average org is exactly where the productivity gap lives.
What actually moves the needle
The teams getting real returns from AI coding tools in 2026 share a few consistent patterns — and none of them are about the tools themselves:
- They rebuilt review pipelines before scaling AI adoption. Faster code generation with a slow review process creates a worse system, not a better one. The investment in automated testing, smaller PR conventions, and review tooling came first.
- They measure output metrics, not input metrics. PRs created is an input. Features shipped, defect rates, and time-to-production are outputs. Teams measuring inputs are optimizing for the wrong thing.
- They treat the internal skill gap as the primary constraint. The 6x divide between power users and median users is not a tool problem — it’s an adoption depth problem. The teams closing that gap are running structured enablement programs, not just issuing licenses.
- They apply AI selectively. The 19% slowdown for experienced developers on mature codebases suggests that AI tools are not uniformly beneficial. The highest ROI tends to come from greenfield work, boilerplate generation, test writing, and documentation — not from complex refactoring on legacy systems.
The honest assessment
AI coding tools are genuinely useful. The productivity ceiling shown by Spotify and VentureBeat is real and achievable. But the path from “we have licenses” to “we have leverage” is longer and more structural than most organizations budgeted for. The teams that will pull ahead in 2026 are not the ones that deployed the most AI — they’re the ones that rebuilt their engineering systems to actually benefit from it. The churn numbers, the review backlogs, and the internal skill divides are not bugs in the AI story. They are the story. The sooner enterprise teams treat them as primary constraints rather than edge cases, the sooner the productivity gap closes.