Few questions in technology have produced more confident claims and more contradictory evidence than this one. Vendors report developers finishing tasks in half the time. A respected research nonprofit measured experienced developers taking longer with AI than without it — while those same developers believed they had been sped up. Survey data shows near-universal adoption paired with conditional, verify-first trust.
This article lays out what the best available evidence actually shows as of October 2026: the major studies, why they disagree, where the gains are real, where they evaporate, and what "efficient" even means when the bottleneck in software development was never typing speed in the first place.
First, define "efficient" — the studies do not agree on it
Most arguments about AI coding tools are really arguments about measurement. There are at least four different things people mean by efficiency, and the evidence differs for each.
Task completion time is the simplest: how long does a defined piece of work take? This is what controlled experiments measure, and it is where the biggest, cleanest gains appear. Throughput is how much work a team finishes per week or sprint — the metric that matters to a business. Delivery stability is whether the changes you ship break things: change failure rates, rollback frequency, time to recover. And perceived productivity is how fast developers feel they are going — which, as we will see, can diverge sharply from the clock.
A tool can improve one of these while worsening another. Code that is generated faster but arrives in larger, harder-to-review batches can raise individual task speed while lowering team throughput and stability. Keep the four meanings separate, and the apparently contradictory research below starts to cohere.
The case for large gains: controlled experiments and field trials
The most-cited result in favor of AI coding tools comes from a 2023 controlled experiment run by GitHub and Microsoft Research. Ninety-five professional developers were randomly split into two groups and asked to implement an HTTP server in JavaScript. The group with access to GitHub Copilot finished 55.8% faster — an average of 1 hour 11 minutes versus 2 hours 41 minutes — with a higher completion rate (78% versus 70%).
The important context: this was a self-contained, well-specified, greenfield task with no legacy codebase, no dependencies on other teams, and an automated test suite to grade correctness. It is close to the best case for an AI assistant — exactly the kind of work these tools are good at. Treating 56% as the expected gain on ordinary maintenance work would be a category error, and the authors did not claim otherwise.
The strongest large-scale evidence is newer. A study published in Management Science in February 2026 combined three randomized field experiments run inside real companies — Microsoft, Accenture, and an anonymous Fortune 100 firm — covering 4,867 developers doing their ordinary work. Pooling the experiments, developers with access to an AI coding assistant completed 26.08% more tasks (standard error 10.3%). Each individual experiment was noisy, and results varied across the three companies, but the direction was consistent. Notably, less experienced developers adopted the tool more and gained more — a pattern that recurs across the literature.
GitHub's enterprise research with Accenture adds a adoption-and-satisfaction layer: over 80% of participating developers successfully adopted Copilot, 90% reported feeling more fulfilled in their jobs, and 95% said they enjoyed coding more with it. Satisfaction is not throughput, but it is not nothing either — retention and burnout are real costs in software organizations.
Peng et al. — The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (arXiv, 2023)
GitHub — Quantifying GitHub Copilot's impact in the enterprise with Accenture (2024)
The case against: the METR result that refused to go away
In July 2025, the research nonprofit METR published the result that still anchors the skeptical side. Sixteen experienced open-source developers — each working on repositories they knew well, with an average of years of history in the codebase — completed 246 real issues. Each issue was randomly assigned to be done with AI tools allowed or disallowed.
The result: with AI allowed, tasks took 19% longer. The developers themselves did not notice. Before starting, they predicted AI would speed them up by 24%; after finishing, they still believed they had been sped up by about 20%. The gap between felt and measured productivity — roughly 40 percentage points — is arguably the study's most important finding, because it means developer self-reports, the basis of most industry surveys, cannot be taken at face value.
Why were they slower? METR's analysis points to the overhead of prompting, waiting, reviewing and correcting AI output in a large, mature codebase with high standards — work where the developer already knows exactly what to do, and the AI's suggestions need careful verification against context the model does not have. The authors were explicit about scope: early-2025 tools, experienced developers, familiar repositories. It was a snapshot, not a verdict on all software work.
The 2026 follow-up: the effect moved, and the experiment broke
METR reran the study starting in August 2025 with more developers and newer tools, and published the outcome in February 2026. The raw numbers moved sharply: for developers returning from the original study, the estimate flipped to an 18% speedup; among newly recruited developers, a 4% slowdown. Both estimates came with wide confidence intervals.
The more interesting finding is that METR declared its own data unreliable. A significant share of developers refused to participate because they did not want to work without AI, and 30–50% of participants told researchers they were choosing not to submit some tasks rather than do them unaided. That selection pressure likely biases the measured effect downward. Pay cuts and the rise of developers running multiple AI agents concurrently — which makes "time spent on a task" nearly impossible to define — compounded the problem.
Read carefully, the follow-up says two things at once. The productivity effect of AI tools in early 2026 is probably positive and probably larger than in early 2025. And the effect has become genuinely hard to measure, because the control condition — working without AI — is one a growing share of developers will no longer accept. When a measurement breaks because the treatment has become indispensable, that is itself a kind of evidence.
METR — We are Changing our Developer Productivity Experiment Design (February 2026)
Why the studies disagree: task, experience and codebase
Laid side by side, the pattern is less contradictory than it looks. The largest gains appear on self-contained, well-specified, lower-context tasks — writing a fresh HTTP server, boilerplate, tests, documentation, work in an unfamiliar language or framework. The smallest gains, and the 2025 slowdown, appear on high-context work: mature codebases, experienced maintainers, tasks where correctness depends on history and conventions the model cannot see.
Experience cuts both ways. The Management Science field experiments found less experienced developers gained more — consistent with AI substituting for knowledge they do not yet have. The METR study found experienced developers slowed down — consistent with AI adding verification overhead to work they could already do unaided. Both can be true, and the reconciliation is obvious: AI helps most where the human's advantage over the model is smallest.
There is also a selection story. Developers choose which tasks to hand to AI, and they choose well — routine, well-bounded work. Studies that measure the tasks developers actually delegate will find bigger effects than studies that randomize across all tasks. Neither is wrong; they are measuring different questions.
The organizational view: DORA's amplifier finding
Individual task speed is not the same as team performance, and the most comprehensive organizational data comes from DORA, the Google Cloud research program that has surveyed thousands of technology professionals annually for over a decade.
DORA's 2025 report — nearly 5,000 respondents plus over 100 hours of interviews — found AI adoption nearly universal (90% of respondents) and, for the first time, a positive relationship between AI adoption and both software delivery throughput and product performance. The 2024 data had shown the opposite: every 25% increase in AI adoption was associated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability.
One thing did not improve: AI adoption still had a negative relationship with delivery stability in 2025. DORA's framing is that AI is an amplifier, not a fix. It magnifies what an organization already is. Teams with strong automated testing, mature version control and fast feedback loops convert faster code generation into faster, stable delivery. Teams without them convert it into larger change batches, slower reviews and more production incidents. The tool did not create the difference; it exposed it.
What developers themselves report in 2026
Stack Overflow's 2026 Developer Survey — over 30,000 respondents from 169 countries — shows how thoroughly these tools have been absorbed. Sixty-six percent of respondents use AI coding assistants or agents, ahead of even general-purpose chatbots (63%), and 73% of those users work with them daily. Nearly a third of daily users spend four or more hours a day with them.
The trust data is the revealing part. Forty-eight percent of respondents say they trust AI output only when they can easily verify it; just 6.6% extend trust to important work decisions. Nearly 79% say source attribution is important or very important when evaluating AI-generated code or answers. Overall sentiment is favorable by roughly three to one — but the dominant working mode is human-in-the-loop, with the developer as verifier.
That posture matches the experimental evidence. The developers in METR's study who felt 20% faster while working 19% slower were the exception in self-awareness; the broader population has settled on a verify-first stance that treats AI output as a draft, not a deliverable. Given that verification is where the hidden time cost lives, the survey posture and the stopwatch data are consistent.
Stack Overflow — Developer Survey 2026: AI
Stack Overflow — 2026 Developer Survey press release (October 6, 2026)
Where the efficiency leaks out: review, testing and maintenance
Code generation is only one stage of software development, and speeding it up can simply move the bottleneck. AI-assisted developers tend to produce larger change sets, and larger change sets take longer to review and fail more often in production — the mechanism DORA identified behind the 2024 stability decline. A pull request that took twenty minutes to write and two days to get reviewed is not a twenty-minute improvement.
Verification has a real cost even before review. AI suggestions in an unfamiliar-looking but plausible style — the failure mode developers call confident wrongness — demand line-by-line checking, and checking code is a different skill from writing it. The 48% of Stack Overflow respondents who trust AI only when they can verify it are describing a workflow where the human's job has shifted from author to editor. Editing is often faster than writing. It is not free.
Maintenance is the longest tail. Code is read far more often than it is written, and code nobody on the team fully understands — because nobody wrote it — can be a liability for years. None of the major studies measure multi-year maintenance costs; the field is simply too young. Any honest accounting of efficiency has to mark this cell as "unknown," not "zero."
So, will traditional software development become more efficient?
Assembled honestly, the evidence supports a specific, bounded set of conclusions rather than a single number.
For individual task speed on well-bounded work, the gains are real and large — the controlled experiments, the field trials and the survey behavior all agree, and the effect has grown as the tools improved between early 2025 and early 2026. For experienced developers on high-context work, the effect is smaller and was negative as recently as 2025. For team-level delivery, the 2025 DORA data shows throughput gains are now achievable, but stability still degrades unless the surrounding engineering system — tests, review capacity, deployment practices — absorbs the higher change volume. And for long-term maintainability, nobody knows yet.
The most defensible summary is DORA's: AI coding tools are an amplifier. They make efficient development organizations more efficient and disorganized ones faster at producing instability. The returns come less from the tool than from the system around it.
What teams should actually measure
The METR perception gap — developers feeling 20% faster while working 19% slower — is a warning to any organization evaluating these tools by asking developers how they feel. Feelings are real and matter for retention, but they are not a productivity metric.
The metrics that survive scrutiny are the boring ones: cycle time from commit to production, change failure rate, review wait time, and rework. If AI adoption is working, cycle time falls without change failure rate rising. If generation speed is up but review queues and incident counts are up with it, the efficiency is an illusion moving cost downstream. DORA's research points to the enabling investments: automated test coverage, small batch sizes, fast feedback loops, and clear organizational policies on where AI-generated code is acceptable.
A practical reading for a US engineering organization in late 2026: adopt the tools — your developers already have, with or without permission — but budget for the verification and review capacity they demand, and instrument the delivery pipeline before and after, not the vibes.
The strongest argument on each side
The optimist's case: three randomized field experiments across nearly 5,000 real developers found a 26% throughput gain; the one famous contrary result has been substantially revised upward by its own authors; adoption is near-universal and voluntary; and the tools of late 2026 are markedly better than the early-2025 tools in the METR study. The direction of travel is unmistakable.
The skeptic's case: the largest measured gains come from tasks and populations chosen to flatter the tools; the most rigorous study of experienced developers on real work found a slowdown; delivery stability has consistently worsened with adoption; and the long-term maintenance bill for AI-generated code has not come due yet. Faster code generation was never the industry's binding constraint — coordination, review and correctness were.
Both are reading real data. They differ on time horizon and on which stage of the pipeline matters most.
What this article can and cannot establish
This piece relies on published studies with stated methods: two randomized controlled designs with opposite headline results, a three-company field-experiment synthesis, two years of large-scale survey data, and one survey of developer attitudes. That is a strong evidence base by the standards of this field, but it has gaps. Most studies measure weeks or months, not the years over which maintenance costs accrue. Vendor-affiliated research — GitHub and Microsoft fund much of it — may tilt toward favorable framings, which is why this article leans on the independent METR and DORA work for the hardest claims. And the tools are changing faster than the research cycle: every number here describes tools that have already been superseded.
The question in the headline, then, has a real but unglamorous answer: AI coding tools are already making software development more efficient at the task level, are beginning to do so at the team level where the surrounding engineering practices support it, and carry costs — verification, review load, stability risk, and unknown maintenance debt — that decide whether the net effect is positive. Efficiency was never about how fast code gets written. It still is not.