The headline numbers are hard to ignore. A Navigara study tracking 676 open-source engineers at six major tech companies found engineering production grew 116% year-over-year from Q1 2025 to Q1 2026. PR volume is up 98%. Code commit rates are climbing. On the surface, the case for AI coding tools looks airtight. Look closer at the data, and a more complicated picture emerges — one that has serious implications for how engineering teams should be measuring, adopting, and managing AI assistance in 2026.
Commit Volume Is Not the Same as Shipped Value
The Navigara study is careful to avoid causal claims. It measures public repository activity — commits per engineer up 35%, per-commit intensity up 51% — but explicitly does not distinguish AI-assisted commits from human-written ones. The data is real. The interpretation is where the industry is making a costly mistake.
Software engineering has been down this road before. In the early days of productivity measurement, “lines of code per day” was treated as a proxy for developer output — until teams realized it rewarded verbose, bloated implementations over clean, minimal ones. The industry eventually moved past it. AI adoption appears to be reviving the same fallacy at scale, now dressed as commits per quarter.
The underlying data tells a different story. Faros AI’s analysis of 10,000+ developers across 1,255 teams found that while individual task completion improved 21% under AI adoption, there was no statistically significant correlation between AI adoption rates and company-level productivity improvements. PR review time went up 91%. Bugs per developer went up 9%. PR size ballooned 154%. The volume gains were absorbed and neutralized by downstream bottlenecks in review queues, QA, and security.
The Tokenmaxxing Problem: 2x Throughput at 10x Cost
A TechCrunch analysis drawing on Jellyfish data from 7,548 engineers coined the term “tokenmaxxing” for a pattern that is emerging as AI coding tools mature: developers using AI at high adoption rates show 9.4x higher code churn than their non-AI counterparts — far outpacing the roughly 2x throughput gain. Code accepted at 80–90% rates in the IDE is being revised or discarded in production, with real-world retention rates dropping to 10–30%.
Code churn — defined as the rewriting of recently-added code — is expensive in ways that don’t appear in commit counts. It consumes review capacity, fragments institutional knowledge, and creates maintenance surface that compounds over time. When churn rates under high AI adoption reach 861% above baseline, the 2x headline productivity number becomes a ratio that doesn’t hold up at the organizational level.
The Perception Gap Is the Riskiest Part
The most consequential finding in the recent research isn’t about code quality or commit rates. It’s about what developers believe is happening versus what is actually happening.
METR’s randomized controlled trial — the only rigorous RCT in the space — studied 16 experienced developers across 246 tasks using Cursor Pro with Claude 3.5/3.7 Sonnet on mature repositories where they had five or more years of experience. The result: developers were 19% slower with AI tools than without them. The same developers forecast they would be 24% faster going in, and reported feeling 20% faster coming out. The gap between perceived and measured performance was not a rounding error. It was the headline finding.
A Lightrun survey of 200 senior SRE and DevOps leaders at large enterprises found that 43% of AI-generated code changes require debugging in production even after passing QA and staging. Zero percent of respondents said they were “very confident” that AI-generated code would behave correctly in production. Eighty-eight percent reported needing two to three redeploy cycles to verify an AI-assisted fix. These numbers reflect production systems, not sandboxed experiments.
When perception and reality diverge this sharply — and when the subjective experience of speed is so consistently wrong — the risk is that headcount decisions, sprint velocity targets, and team-size reductions get made using inflated productivity assumptions before the actual data catches up.
Context Integration Is What Separates 4x Gains from 19% Slowdowns
The apparent contradiction between the METR slowdown and the headline gains resolves when you look at the conditions under which AI coding tools actually work. The pattern is consistent across the better-controlled studies: AI amplifies productivity when it has deep organizational context, and it creates overhead when it doesn’t.
EY’s reported 4x to 5x productivity gains came specifically from integrating AI agents with internal code repositories, engineering standards, and compliance frameworks. Early-adoption baselines without that integration showed 15–60% gains — meaningful, but far below the headline number. The critical variable was context depth, not model capability. IBM’s Project Bob, which reported 45% productivity gains across 80,000+ internal developers, took a similar approach — full-SDLC context including modernization, security, and compliance, not just a generic autocomplete layer on top of the IDE.
The METR study, by contrast, used mature repositories with no specific AI context integration — experienced developers trying to apply general-purpose AI tools to codebases where they already had deep tacit knowledge. In that scenario, the AI’s suggestions created friction rather than reducing it: reviewing and correcting AI output on code a developer knows well turns out to be slower than just writing it.
What the Data Actually Requires of Engineering Leaders
None of this means AI coding tools don’t work. It means the proxy metrics most organizations are using to evaluate them are wrong. Commit count and PR volume measure activity. They don’t measure delivered value, code longevity, security posture, or review overhead — the variables where the costs of AI adoption are currently accumulating.
Engineering teams that are outperforming with AI share a pattern: they invest in context infrastructure before they invest in tooling. They measure churn, review queue depth, and production incident rates alongside throughput. They build the organizational scaffolding — standards, compliance integration, internal repo access — that transforms a general-purpose model into a system that actually knows the codebase it’s working in.
The 116% production number is real. So is the 19% slowdown. So is the 43% production debugging rate. The question for every engineering organization in 2026 is not whether to adopt AI, but whether the measurement infrastructure exists to tell the difference between the scenario that produces each outcome — before the headcount decisions get made.