Ask ten developers how much AI speeds them up, and you'll get eleven answers. The freshest 2026 data, built not on self-reports but on actual telemetry from the Git and CI/CD systems of thousands of developers, shows why: AI genuinely speeds up work and genuinely piles up technical debt at the same time - and both effects are measurable and substantial.
The largest and freshest study
Opsera analyzed data from more than 250,000 developers across more than 60 enterprises as of April 2026. The result: AI cuts time-to-pull-request by up to 58%. But those same AI-generated PRs wait 4.6 times longer for review, and carry 15-18% more security vulnerabilities.
Another telling finding from this study: senior engineers capture nearly five times the productivity gains of junior engineers - a gap that's widening rather than closing. At the same time, 21% of AI coding licenses in companies go completely unused.
Independent telemetry paints an even more detailed picture
Code Ninety analyzed git commits and CI/CD pipelines across 84 organizations and more than 14,200 developers, covering Q1 2025 through Q1 2026 (the study was updated in August 2026). An important methodological detail: this is direct system telemetry, not developer surveys - meaning it's less susceptible to the kind of optimism bias the METR study below revealed.
The results: individual PR lead time dropped by 32.4%. But at the same time, the defect injection rate rose by 50% (from 3.2 to 4.8 bugs per 1,000 lines of code), 30-day code churn rose by 67.8%, security vulnerability flags rose by 61.1%, and PR review time rose by 41.5%. The authors summarize it honestly: the productivity gain is real. The technical debt it creates downstream is equally real, and only gets caught if an organization's engineering processes are mature enough to catch it.
The study that kicked off a serious scientific debate
In July 2025, the nonprofit research organization METR published a randomized controlled trial - the gold standard of scientific evidence, the same methodology used in clinical drug trials. Sixteen experienced open-source developers completed 246 real tasks in their own repositories (average size over a million lines of code, average five years of prior experience with the project).
The result surprised even the authors, who wrote plainly that they had expected to see a positive effect: developers allowed to use AI took 19% longer on their tasks. Before starting, they'd predicted a 24% speedup; after finishing - despite the measured slowdown - they still believed AI had sped them up by 20%. The gap between perceived and measured reality came to 39 percentage points.
In a February 2026 update, METR writes cautiously: "based on conversations with study participants, we believe it is likely that developers are more sped up from AI tools now... However, because of the selection effects in our experiment, our data is only very weak evidence for the size of this increase." Developers were reluctant to work without AI and avoided submitting exactly the tasks where AI would help most - systematically skewing the sample. For participants who took part in both rounds, the estimate came out to roughly an 18% slowdown, with a very wide confidence interval. That's an important contrast with the much larger telemetry-based studies above - METR is the most scientifically rigorous, but also the smallest and most methodologically constrained sample of all the sources cited here.
How serious is the security problem, really
Here the data from several independent sources lines up in an uncomfortably consistent way. Veracode tested more than 100 LLMs across 80 coding tasks and found that 45% of AI-generated code introduced OWASP Top 10 vulnerabilities. CodeRabbit independently found that AI-generated code contains 2.74 times more security vulnerabilities than human-written code. And Black Duck's 2026 OSSRA report recorded a 107% year-over-year increase in known vulnerabilities per codebase - from an average of 280 to 581 vulnerabilities per project.
Martin Fowler, the well-known software engineer and author, put it vividly: treat every slice of AI-generated code like a pull request 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."
Who benefits more, juniors or seniors? Researchers don't even agree
There's a direct contradiction between fresh sources here, and it's more honest to show it than to pretend there's a single answer. Opsera (250,000+ developers) claims seniors capture 5 times the productivity gain of juniors. Meanwhile, a field experiment across 4,867 developers by researchers from MIT, Princeton, Wharton, and Microsoft found that developers with above-median tenure showed no statistically significant productivity increase from AI tools at all.
One logical explanation researchers offer for this contradiction: the people best able to use AI effectively are the same people best able to catch where it went wrong and fix it. So the tools may work better for juniors on simple tasks than for seniors on the work that actually matters most - though "simpler tasks" and "easier to measure gains on" may partly explain each other here too.
The scale of adoption as of mid-2026
For context - just how widely this is already being used. 84% of developers use or plan to use AI tools, 51% of professional developers use them daily. GitHub Copilot has more than 20 million all-time users and 4.7 million paid subscribers as of January 2026, and the entire AI coding tools market hit $8.5 billion in 2026. AI-generated code makes up anywhere from 22% to nearly 27% of all code shipped to production, depending on the data source - and that share keeps growing quarter over quarter.
What to actually do with this
The overall picture that emerges from all of this research at once: AI assistants deliver a measurable, real speed boost at the level of an individual PR or task - that's no longer seriously disputed in 2026. The dispute now is over something else: whether that speed gain offsets the parallel rise in defects, vulnerabilities, and technical debt, and whether "productivity" should be measured by code-writing speed alone in the first place.
The most practical takeaway from all this data: track not just speed (time-to-PR, merged PR count), but quality too - defects per thousand lines, review time, static analyzer flags over time. Companies and teams that measure both dimensions at once consistently outperform those chasing speed alone. And, just as it was a year ago, the core lesson from the METR study still holds: your own sense that "things got faster" is a deeply unreliable indicator, worth checking against real numbers rather than taking on faith.