Experienced developers in a randomized trial completed real coding tasks 19% slower when allowed to use AI tools. Afterwards, they estimated that AI had made them 20% faster. That finding, discussed in METR's 2026 productivity survey, raises a practical problem for engineering teams: feeling more productive isn't a reliable measure of getting more work done.

As of August 1, 2026, the evidence discussed here points to useful but uneven gains from AI coding tools. Individual task speed, developer estimates, and organization-wide output tell different stories. Treating them as interchangeable makes it easy to promise improvements that don't appear in delivery numbers.

On July 31, “2x, not 10x: coding with LLMs in 2026” reached the top of Hacker News. Its argument was that AI can make individual developers faster, but that roughly 2x is a more plausible expectation than 10x. The discussion that followed offered practitioner accounts of both useful gains and substantial review costs. Those accounts help explain the tradeoffs, though they don't establish a universal productivity ceiling.

Perceived speed and measured performance

The METR result puts the reported slowdown and perceived speedup nearly 40 percentage points apart. Developers believed the tools had helped even though their tasks took longer.

A responsive tool can make work feel productive. Code appears quickly, suggestions arrive without a pause, and the editor stays busy. But those impressions don't account for all the time spent checking suggestions, correcting mistakes, or deciding whether generated code fits the system.

The trial gives engineering leaders a reason to be cautious about retrospective surveys. Asking whether AI helped during a quarter may produce positive answers even when measured output is flat or lower. It doesn't mean developer feedback has no value. It means that feedback measures an experience, not necessarily a delivery improvement.

The result also shouldn't become a blanket claim that AI slows down every developer. It concerns experienced developers performing real coding tasks under the trial's conditions. The operational lesson is narrower: self-reported gains need to be checked against observed work.

High adoption, modest throughput growth

Developer intelligence platform DX analyzed more than 121,000 developers across over 400 companies and found that 93% used AI coding tools. In that population, pull-request throughput increased 9.97%, while AI usage rose about 65% year over year.

Most organizations recorded gains between 5% and 15%. A smaller group reached 25% to 30%, reportedly tending to be organizations that had integrated AI into their workflows rather than simply distributed Copilot licenses. That association is useful, but it doesn't establish how much of the improvement came from AI or from the surrounding workflow changes.

A genuine 10% throughput increase can be valuable. At the cited GitHub Copilot Business and Enterprise prices of $19 to $39 per developer per month, it can justify the subscription cost. The calculation becomes less favorable if the extra output also creates more review work, rework, or incidents.

These are much smaller gains than the 3x, 5x, and 10x expectations that have accompanied AI coding tools. Even promises of 2x to 3x organization-wide productivity sit well above a measured throughput increase of roughly 10%. Technology leaders need to distinguish a useful purchase from a basis for much larger staffing or delivery commitments.

Faster coding leaves other work untouched

Practitioners in the Hacker News discussion estimated that coding represents roughly 25% of engineering work. Planning, alignment, testing, and code review occupy much of the rest.

The broader argument for a roughly 2x ceiling uses that 25% estimate, but the arithmetic supports a smaller gain. If only coding becomes 10 times as fast, the overall speedup is 1/(0.75+0.25/10), or about 1.29x. Work that previously took 100 hours would take 77.5 hours, since the other 75 hours stay unchanged. The useful principle is Amdahl's law: speeding up one part of a process leaves total performance constrained by the parts that haven't improved.

For software teams, those remaining constraints include understanding what to build, validating correctness, reviewing changes safely, and operating the result reliably. Faster code generation doesn't automatically shorten any of them. It can also increase the amount of work waiting for review.

One commenter reported that properly reviewing AI-generated code took two to three times as long as writing the equivalent code by hand. The reasons included unfamiliar code, inconsistent patterns, and documentation that was missing or confidently wrong. That's an individual account rather than an average, but it describes a cost that code-generation speed alone misses.

Rework can consume the gain

Reported industry figures for 2026 suggest that, alongside increased code volume, code subsequently reworked or deleted increased nearly tenfold. They also put the likelihood of bugs and production incidents at nearly three times the previous level in organizations that adopted AI coding tools without changing their review practices. These are reported figures, not evidence that every AI deployment produces those outcomes.

The concern is the downstream cost. Code generated quickly may later need to be discarded, debugged under production load, or maintained despite being poorly understood. Extra incident response, technical debt, and operational complexity can absorb an apparent delivery gain.

Passing continuous integration checks, or CI, doesn't settle the question. Automated checks cover the behavior they were designed to test. Review still needs to establish whether the code respects the system's assumptions, including corner cases that aren't represented in the test suite.

A team measuring only the amount of code produced or the number of pull requests merged can miss those costs. Throughput needs to be considered alongside cycle time, rework, and incident rates.

Where larger gains are plausible

The “2x, not 10x” post makes a useful distinction between general engineering productivity and tasks that are especially suitable for AI assistance. Its strongest cases have either a clear way to verify success or an experienced engineer who can judge an unfamiliar implementation.

  • Verifiable requirements. File-format conversions, protocol implementations, and tests for specified behavior have concrete, machine-checkable targets. A model can iterate against those targets rather than rely on whether an answer looks convincing.
  • Experts working in an unfamiliar domain. A backend engineer building a first React frontend, or a platform engineer writing a first Kubernetes controller, may compress months of learning into weeks. The model supplies patterns, while the engineer still has to judge their correctness and suitability.
  • Small custom tools that otherwise wouldn't be built. A custom PDF viewer, internal dashboard, or one-off migration script can become worth doing when the implementation cost falls. Calling that an infinite productivity multiplier is rhetorical: the useful change is that previously uneconomic work becomes feasible.
  • Automated feedback loops. Reliable test environments let a model make a change, test it, and revise it. The post argues that this workflow matters more than model capability alone. Teams using test-driven development and CI that runs in seconds are described as approaching 5x gains in suitable work.

Those examples explain why a developer can report a large benefit on a particular task while the organization records a much smaller improvement overall. They also make a fixed 2x ceiling too simple: the result depends on which work is being measured and what remains outside the automated loop.

What engineering leaders should measure and change

AI evaluations should track pull-request throughput, cycle time, and incident rates, with rework included where it can be measured consistently. Developer surveys can help identify friction and useful applications, but they shouldn't stand in for delivery data.

Workflow changes deserve attention alongside model selection. The reported 25% to 30% gains are associated with deeper integration. Practical changes include smaller pull requests, fast tests, and human review focused on the difference between a plausible generated implementation and the requirements of the actual system.

The claim that better models alone will close the productivity gap is doubtful when testing, review, and operational understanding remain constraints. Buying access is only part of the cost. Teams also need to make generated work cheap enough to verify.

Expectations should reflect those distinctions. METR's self-reported data shows developers estimating 2x productivity gains in March 2026 and forecasting 2.5x by March 2027. The aggregate throughput figures discussed here are closer to a 10% gain. These aren't identical measures or necessarily the same populations, so they can't be subtracted to produce a precise productivity shortfall.

For budgeting and delivery commitments, measured local results are a firmer basis than either a vendor's multiplier or a developer's sense of speed. A useful evaluation establishes which tasks become faster, how much verification they require, and whether the improvement survives through review and production.