Developer Productivity Statistics (2026)
Your AI coding assistant may finish a function in minutes, yet the pull request can still wait for review, testing, and a production-safe sign-off. That gap is why the question behind developer productivity statistics is not simply whether code is written faster. It is whether reliable work reaches users faster.
The short answer is that there is no defensible single percentage for developer productivity in 2026. The current evidence shows widespread AI use and commonly reported time savings, alongside review, trust, maintenance, and workflow friction. The statistics below separate adoption, self-reported experience, systems-based delivery measures, and research findings so you can cite the right number for your decision.
Key developer productivity statistics for 2026
These developer productivity statistics are grouped by what they measure. A survey response about feeling faster is not interchangeable with a pull-request throughput measure or a controlled experiment.
Adoption and usage
84% of respondents to Stack Overflow’s 2025 Developer Survey said they used or planned to use AI tools in their development process. The survey received more than 49,000 responses from 177 countries. This is a 2025 self-reported adoption measure, not a measure of delivered output. Stack Overflow’s survey release provides the population and result.
51% of professional developers in Stack Overflow’s 2025 survey reported daily AI-tool use. This is self-reported usage among professional-developer respondents, not proof of a productivity gain. The survey’s AI section reports the result.
31% of Stack Overflow’s 2025 respondents said they currently used AI agents. Separately, 69% of developers who had used agents at work agreed that agents increased their productivity. The latter is a result among agent users, not among all developers. Stack Overflow reports both denominators in its AI survey.
85% of developers in JetBrains’ 2025 survey regularly used AI tools for coding and development, while 62% relied on at least one coding assistant, agent, or AI editor. JetBrains surveyed 24,534 developers in 194 countries; these are vendor-published survey results about that sample. JetBrains’ 2025 developer ecosystem report is the source.
91% of organizations in GitLab’s June 2026 Harris Poll research had two or more AI coding tools in active use. The vendor-sponsored survey covered 1,528 developers and technology buyers in six countries. It describes reported organizational practice, not audited tool telemetry. GitLab’s release states the sample and finding.
Perceived gains and delivery measures
79% of respondents in GitLab’s June 2026 survey agreed that AI had improved individual developer productivity, and 78% said developers were writing and committing code faster. These are vendor-sponsored, self-reported perceptions from the same 1,528-person, six-country population—not a longitudinal delivery study. GitLab’s research release reports both figures.
DX’s 2026 benchmarks reported nearly 20% higher systems-based pull-request throughput and a 16.9% improvement in defect ratio. DX says benchmark segments draw on customer and research-panel data, each with at least 30,000 individuals and/or 200 organizations. These are vendor-produced, systems-based benchmark measures rather than survey sentiment. DX’s benchmark release describes the data and results.
The same DX release reported self-reported AI time savings rising 60%, from 3.9 to 6.2 hours per developer per week. That reported weekly saving should remain distinct from DX’s systems-based throughput and defect measures. DX labels the measures in its 2026 benchmark release.
Atlassian’s 2025 developer-experience research found that 99% of developers reported saving time with AI, and 68% reported saving more than 10 hours per week. Wakefield Research surveyed 3,500 developers and managers across six countries for the vendor-sponsored program. Atlassian’s report page documents the research population.
Review, trust, and friction
66% of respondents to Stack Overflow’s 2025 AI survey encountered AI solutions that were “almost right, but not quite,” and 45.2% said debugging AI-generated code took more time. These are reported friction experiences, not estimates of AI’s causal time cost.
Sonar’s January 2026 survey found that AI accounted for 42% of committed code and that 96% of surveyed developers did not fully trust AI-generated code. Sonar surveyed more than 1,100 professional developers, so these are vendor-survey findings rather than independent industry telemetry. Sonar’s survey analysis provides the context.
In Sonar’s January 2026 survey, 48% said they always verified AI-generated code before committing it, while 38% said reviewing AI code took more effort than reviewing human-written code. Sonar’s release frames this as a verification gap.
50% of developers in Atlassian’s 2025 research reported losing 10 or more hours a week to non-coding inefficiencies. In the same vendor-sponsored research program, 63% said leaders did not understand their pain points, up from 44% in the prior year. Atlassian’s research summary reports those developer-experience findings.
Chainguard’s 2026 Engineering Reality Report found that respondents spent 16% of their week writing code and building new features, while 79% identified code maintenance as a major time drain. The report is based on 1,200 responses collected in August 2025 from 600 software engineers and 600 senior technology leaders in the US, UK, Germany, and France. This is survey evidence about that population. Chainguard’s report gives the fieldwork and figures.
Research findings to keep in context
Google DORA’s 2025 research combines more than 100 hours of qualitative data with survey responses from nearly 5,000 technology professionals worldwide. Its central finding is that AI amplifies organizational strengths and dysfunctions. That is a research conclusion, not a universal effect size. Google Research’s DORA 2025 report describes the study.
METR’s July 2025 randomized controlled trial found that experienced open-source developers took 19% longer with early-2025 AI tools, despite expecting a 24% speedup. METR explicitly says the result is out of date and does not reflect current AI impact, so it is useful only as historical evidence about the difference between perception and observation. METR’s study page carries that warning.
Get the Mobile Testing Playbook Used by 800+ QA Teams
Discover 50+ battle-tested strategies to catch critical bugs before production and ship 5-star apps faster.
AI adoption is widespread, but adoption is not a productivity outcome
AI use is clearly common in developer workflows. Stack Overflow and JetBrains each report high adoption in broad international samples, while GitLab reports organizations running multiple AI coding tools. That tells you the technology is part of day-to-day work. It does not tell you whether a release reaches customers sooner or with fewer defects.
An adoption number supports a claim about exposure to a tool. A self-reported time-saving number supports a claim about developers’ experience of that tool. Neither, by itself, supports a claim about end-to-end delivery performance.
Stack Overflow’s agent figures show why denominators matter. Saying “69% of developers are more productive with agents” would overstate the evidence. The survey found 69% agreement among people who had used agents at work, while 31% of respondents currently used agents. Preserve both parts of the finding when you cite it.
Why coding speed is not the same as delivery performance
Writing a first draft of code faster can help. But work still has to pass review, testing, integration, deployment, and—when needed—incident response. A productivity measure that stops at code generation can shift the bottleneck out of view.
GitLab’s 2026 survey captures that concern directly: 85% of its respondents agreed that AI shifted the bottleneck from writing code to reviewing and validating it. This is a vendor-sponsored survey perception, but it gives you a useful hypothesis to test in your own workflow.
The DX results are valuable because they separate two measurement approaches. Its nearly 20% higher PR throughput and 16.9% defect-ratio improvement are systems-based benchmarks; its 6.2 weekly hours of AI time savings are self-reported. They may both be useful, but they answer different questions. Do not average them or turn them into a single productivity score.
DORA’s work supplies broader historical context. Its 2024 report found that AI adoption was associated with higher individual productivity, flow, and job satisfaction while negatively affecting software-delivery stability and throughput. Treat that as research context, not a current universal benchmark. DORA’s 2024 report details the finding.
Quality, review, and verification are productivity signals
A developer who produces a change quickly has not necessarily produced a completed change quickly. The gap between those outcomes often appears in review and verification.
Stack Overflow’s “almost right” result matters because code that is close to correct can take careful human work to diagnose and finish. Sonar’s survey points in the same direction: respondents reported both low confidence in AI output and incomplete verification before commit. These figures do not prove that AI slows every team; they show why typing speed is too narrow a productivity measure.
Track review and quality work as first-class signals. Useful measures include review turnaround, time to resolve review findings, validation completion, rework, defect ratio, change failure, and rollback or revert signals. You can then see whether faster authoring is moving the whole system or simply creating more work downstream.
For adjacent testing context, Quash’s AI testing statistics and adoption data focuses on testing rather than treating generated code as the finish line.
Where developer time goes beyond feature work
The Atlassian and Chainguard findings make a compatible point without being mathematically additive. Developers can report time savings from AI and still lose substantial time to inefficient processes, maintenance, interruptions, and context switching. One figure describes a gain in a task; another describes drag across the workweek.
Chainguard also found that 88% of respondents said tool switching affected productivity, with 44% reporting significant focus loss from context switching. Those are self-reported survey results, but they are a reminder to inspect the handoffs around development—not merely the editor where code is written. Chainguard’s Engineering Reality Report provides the survey context.
If you are considering AI-assisted development, establish a baseline before changing tools. Measure a representative period of review turnaround, lead time, defects, maintenance work, and interruption load. Then compare like with like after adoption. The relevant question is whether your delivery system improved, not whether a model produced more text.
What to measure instead of one productivity number
You will get a more useful view of developer productivity from a balanced scorecard than from one headline percentage. This is an editorial recommendation, not an industry standard or a set of universal targets.
Measurement category | What you can track | Why it belongs |
Delivery flow | PR throughput, cycle time, review turnaround, incremental delivery | Shows whether work moves through the delivery system. |
Reliability and quality | Defect ratio, change failure, incidents, rework, reverts | Prevents faster code creation from being confused with better outcomes. |
Review and verification | Review effort, validation completion, traceability, time to resolve findings | Makes the verification bottleneck visible. |
Developer experience | Reported time savings, interruptions, context switching, maintenance load, focus | Captures work that code-volume metrics omit. |
Team and product outcomes | Customer-facing delivery, product quality, user impact, sustainable workload | Connects engineering activity to the outcome you need. |
Use the scorecard to ask specific questions. Did review turnaround worsen as AI-generated code rose? Did PR throughput improve while incident work increased? Did developers save time on routine tasks but lose it to switching tools? Your answers will be more actionable than an aggregate “productivity up 20%” claim.
What the public data still cannot tell you about mobile QA
No first-party Quash data covers general developer productivity, so Quash cannot provide a proprietary productivity statistic for this report. The available public research is also notably thin on mobile-specific verification work.
The sources above do not measure how AI changes mobile bug-discovery rates, mobile test-authoring or maintenance time, device and OS-version coverage, or the effort to reproduce failures across permission states, lifecycle states, network transitions, safe-area conditions, and process-death recovery. They also do not quantify the time from an AI-generated code change to a reproducible mobile regression.
That gap matters if your product is mobile. A broad PR-throughput improvement does not establish that your Android and iOS coverage improved, that a device-specific bug was found earlier, or that the verification burden created by device fragmentation fell. Those are separate measures worth adding to your own scorecard.
Methodology and source limitations
This report uses figures published in 2025 and 2026, but they do not share a common population, question, or method. Stack Overflow, JetBrains, Atlassian, GitLab, Sonar, and Chainguard provide survey-based evidence. DX supplies a vendor benchmark that combines systems-based and self-reported measures. DORA and METR provide research findings with different designs.
Vendor sponsorship does not make a result unusable. It does mean you should retain the sponsor, sample, period, and evidence type when you reuse it. A survey response about perceived speed, a benchmarked change in PR throughput, and a randomized trial are different kinds of evidence.
The statistics are therefore not combined into an industry average. The most defensible reading is narrower: AI is widely used; many developers report time savings; review, trust, maintenance, and workflow friction remain material; and delivery outcomes must be measured across the whole system.
Conclusion
Use developer productivity statistics as decision inputs, not as a scoreboard. Adoption figures can establish that AI is widespread. Survey results can show where developers perceive gains or friction. Systems-based measures can reveal whether work is moving. None can replace measurement of your own delivery flow, quality, and verification workload.
For your next decision, start with the bottleneck you need to move—authoring, review, testing, or delivery—and choose the statistic that actually measures it.
Continue reading
More articles from the Quash editorial desk.
