A study published in July 2025 gave AI coding tools their most credible test yet. Sixteen experienced open-source developers, 246 real tasks, randomized controlled design. The researchers expected to measure how much faster AI made them. They found that developers using AI took 19% longer to complete tasks than those working without it.

The developers themselves thought they were 20% faster.

That 39-point gap between perception and reality is the central result in METR’s paper. It lands inside two years of adoption data pointing in the opposite direction. DX surveyed 121,000 developers across 450+ companies and found 92.6% use AI coding tools at least monthly. JetBrains’ AI Pulse measured 93%. The DORA 2025 report put it at 90%. On the productivity side, the findings depend on what is measured: time spent on a task, reported hours saved, or software delivered. Those aren’t interchangeable, and faster code generation doesn’t guarantee faster delivery.

Exhibit showing METR study results: developers using AI took 19% longer to complete tasks while believing they were 20% faster, a 39-point perception gap across 246 tasks with 56% of AI suggestions rejected

The bottleneck was never the typing

Goldratt’s Theory of Constraints makes the following prediction: optimizing a step that isn’t the bottleneck doesn’t improve system throughput. You can make the fastest machine on the factory floor twice as fast. If it’s feeding a queue that’s already backed up, you’ve accomplished nothing at the output level.

Writing code has never been that bottleneck. Bain’s analysis found that writing and testing code accounts for roughly 25-35% of the total software development lifecycle. The rest goes to code review, understanding requirements, debugging, meetings, documentation. Even with a 100% speedup on the coding step, that gives you a 15-25% overall improvement, and that’s before accounting for what happens downstream when you generate a lot more code. Gergely Orosz, who runs The Pragmatic Engineer, put it directly:

Speed of typing out code has never been the bottleneck for software development.

The data below shows AI tools moving the bottleneck downstream and making it worse.

Exhibit showing coding is 25-35% of the software development lifecycle with developers writing code only 52 minutes per day, meaning even a 100% coding speedup yields at most 15% system improvement under Amdahl's Law

The code review bottleneck

Faros AI measured this across 10,000+ developers on 1,255 teams in June 2025. Teams with high AI adoption completed 21% more tasks and merged 98% more pull requests. PR size grew 154%. Review time rose 91%, bugs rose 9%, and organizational DORA metrics stayed flat.

The coding step accelerated. The review step, already a constraint, got worse. Michael Truell, Cursor’s CEO:

Cursor has made it much faster to write production code. However, for most engineering teams, reviewing code looks the same as it did three years ago

Cursor then acquired Graphite, a code review startup. The acquisition is a more honest statement about where the constraint lives than anything in Cursor’s marketing. The DORA 2024 report found that for every 25 percentage point increase in AI adoption, delivery throughput dropped 1.5% and delivery stability dropped 7.2%. DORA 2025, at 90% adoption, put it tersely: “AI doesn’t fix a team; it amplifies what’s already there.” The 2025 report also found a positive relationship with throughput, alongside greater instability. That is a different result from 2024 and from Faros’s unchanged delivery metrics, rather than evidence of one universal productivity ceiling.

Exhibit showing Faros AI data across 10,000+ developers: high AI adoption teams merged 98% more pull requests but review time increased 91%, bugs rose 9%, and DORA delivery metrics were unchanged

41% of what?

One number circulates constantly in press coverage: 41% of code is now AI-generated. It comes from Emad Mostaque, who took GitHub’s figure about the share of code accepted by Copilot users and extrapolated it into a claim about all code everywhere. The original figure applied only to developers already using Copilot, a fraction of GitHub’s user base at the time. The extrapolation doesn’t hold.

DX’s more defensible measurement across 4.2 million developers puts AI-generated production code at 26.9%. A study published in Science found roughly 30% of Python functions from U.S. contributors on GitHub were AI-generated by late 2024. Sundar Pichai said more than a quarter of all new code at Google is AI-generated. These numbers cluster around 25-30%.

The inflated figure matters because it supports a specific argument: that AI has already crossed some threshold, that the transformation is done, that the productivity gains are already baked in. At 27%, AI is a meaningful contributor to software production. At 41%, you’re telling a different story, and the decisions that follow from it are different decisions.

The quality picture at 27% is not reassuring. Veracode tested 100+ LLMs across 80 coding tasks and found 45% of AI-generated code introduced OWASP Top 10 vulnerabilities. CodeRabbit’s analysis found AI-generated code contains 2.74x more security vulnerabilities than human-written code. Black Duck’s 2026 OSSRA report found vulnerabilities per codebase up 107% year over year, the mean codebase going from 280 to 581 known vulnerabilities. Martin Fowler’s framing is still the most honest I’ve seen: “Treat every slice as a PR from a rather dodgy collaborator who’s very productive in the lines-of-code sense, but you can’t trust a thing they’re doing.”

Perception is reality

The 19% slowdown is a result for one early-2025 setting: experienced developers on familiar codebases, with a confidence interval of +2% to +39% in task time. In February 2026, METR published a follow-up covering 57 developers and 800+ tasks. Returning developers had an estimated 18% reduction in task time (CI: -38% to +9%); newly recruited developers had a 4% reduction (CI: -15% to +9%). Both intervals include slowdown. Developers increasingly declined to participate, and 30-50% reported withholding some tasks because they did not want to do them without AI. Those selection effects, lower participation pay and difficulties measuring concurrent agent use made the data unreliable for estimating current productivity benefits. The original slowdown remains a valid finding for its setting; it is not a current verdict on experienced developers generally.

METR’s companion Horizon benchmark (Kwa et al., 2025) puts numbers to that curve: the 50%-task-completion time horizon for Claude 3.7 Sonnet was 60 minutes. Claude Opus 4.6, released February 2026, reached 719 minutes. The doubling time from 2023 is approximately 128 days. METR frames the productivity result as a point on that trend, not a fixed constant, though they also note that their benchmark tasks are cleaner than real production work and performance on “messier” tasks may improve more slowly. But the perception gap itself is more robust than the exact slowdown figure, and it replicates.

Stack Overflow’s 2025 Developer Survey found favorable views of AI tools dropped from 70% to 60%, with 46% not trusting AI output and 66% citing “almost right but not quite” as their top frustration. Software.com’s monitoring of 250,000 developers found the median developer codes for 52 minutes per day, about 11% of a 40-hour week. The tools are fighting over 11% of the workday.

A field experiment across 4,867 developers from MIT, Princeton, Wharton, and Microsoft found that above-median-tenure developers showed no significant productivity increase from AI tools. The people capable of using AI most effectively are also the people most likely to catch when it’s wrong and fix it. It’s why the tools work better for junior developers on simple tasks than for senior developers on more demanding work.

GitHub’s 2022 Copilot study

GitHub’s 2022 Copilot study, the “55% faster” figure, still appears in enterprise sales decks in 2026. One JavaScript task: implementing a web server with HTTP endpoints. Thirty-five completers. No assessment of output quality, test coverage, or whether the code would survive production. Confidence interval: 21% to 89%. Participants knew they were being timed for productivity.

When you pick a task specifically suited to AI assistance and measure completion time without checking correctness, AI looks fast. That finding has been stretched to justify eight-figure licensing deals.

Macro data

Apollo’s Torsten Slok wrote in early 2026: “AI is everywhere except in the incoming macroeconomic data.” An NBER paper from February 2026 surveying nearly 6,000 executives found over 80% of firms reported AI had no impact on productivity over the preceding three years. Expected improvement over the next three: 1.4%.

Daron Acemoglu, who shared the 2024 Nobel Prize in Economics partly for his work on technology and labor markets, projected a 0.5% total factor productivity increase from AI over the next decade. His reasoning: the economic value of AI concentrates in a narrow set of tasks that don’t represent enough of total economic activity to move aggregate numbers. The Bain arithmetic, at macroeconomic scale.

The standard optimist response is the IT comparison: computers entered enterprises in the 1970s and 1980s without producing measurable productivity improvements for a decade, then the gains came in the mid-1990s. It’s a reasonable historical parallel. I’m uncertain whether it applies. Computers replaced manual processes wholesale. AI coding tools are a faster ingredient inside a process whose other ingredients haven’t changed: the requirements still need to be understood, the review still needs to happen, the tests still need to pass. The productivity lag might resolve. Or the structure of the workflow might mean it doesn’t, even eventually. I don’t know.

Where the value actually lands

Exploration is faster. When I’m working on something unfamiliar, a library I haven’t used, an API I’m integrating for the first time, the startup cost drops. A working first draft arrives in minutes rather than hours. That’s real, and I notice it. Whether it shows up in throughput metrics is a different question, and the data suggests mostly not, because the constraint was never the first draft.

Boilerplate, test scaffolding and documentation benefit too. The tasks that are well-scoped and low-stakes if approximately wrong are where these tools earn their keep.

Simon Willison, in an NPR interview: “Our job is not to type code into a computer. Our job is to deliver systems that solve problems.” The tools handle the first part better than they did a year ago. The second part hasn’t changed.

The right question

The useful product question, if the bottleneck is now review, is what makes review faster and more reliable, not what generates more code faster. AI tools that flag security issues, catch logic errors, and surface context about why code was written a certain way would attack the actual constraint. This is at least part of what Cursor is working toward with Graphite.

The harder problem is cultural. Bain and DORA say the same thing from different angles: AI amplifies what’s already there. Teams with good review practices and clear requirements can deliver more. Teams without them produce more code that still doesn’t ship on time. The organizations that most want a tool to fix their velocity tend to be the ones with the process debt that prevents any tool from working.

I have no idea what the five-year picture looks like. The Solow paradox took a decade to resolve and resolved in ways nobody expected. Maybe the AI productivity gains show up in 2029 and the 2026 skeptics look naive. I try to take that possibility seriously.

What these studies show is that high adoption and more generated code do not guarantee faster delivery. METR found a slowdown in one early-2025 setting; its later estimates suggested speedups but could not establish their size reliably. Faros found more code and slower reviews without better delivery metrics, while DORA 2025 associated AI adoption with both higher throughput and greater instability. The bottleneck question remains useful. A universal 10% ceiling, or a blanket claim that experienced developers are slower with AI today, goes further than this evidence supports.