AI Coding Productivity Study Data: What METR, McKinsey, and GitHub Found in 2026

METR's own randomized controlled trial found experienced developers were 19% slower using AI coding tools in early 2025 — and the same research group now estimates those developers are 18% faster a year later.

That's the short answer. The longer answer is more interesting: the productivity data on AI coding isn't one number, it's a moving target that depends on task complexity, developer seniority, and how long a team has actually been using the tools. McKinsey's study of 4,500 developers across 150 enterprises found AI cuts routine task time by 46% but under 10% on high-complexity work. Opsera's analysis of over 250,000 developers found AI reduces time-to-PR by up to 58% — but those same AI-authored pull requests wait 4.6x longer in code review, and AI-generated code carries security vulnerabilities at up to 2.74x the rate of human-written code. The gains are real. So are the tradeoffs. Almost nobody reports both.

What does the AI coding productivity study data actually show in 2026?

The AI coding productivity study data shows a wide, task-dependent range rather than one clean number: METR's controlled trial found a 19% slowdown in early 2025 that flipped to an estimated 18% speedup by early 2026, McKinsey found 46% time savings on routine tasks but under 10% on complex tasks, and Opsera's 250,000-developer dataset found up to 58% faster time-to-PR alongside 4.6x longer AI pull-request review times.

Every one of these numbers is technically correct, and every one of them is incomplete on its own. The reason the headline stat swings so wildly between studies is that they're measuring different things: raw task-completion time, PR cycle time, self-reported developer sentiment, or downstream code quality. A team that only tracks time-to-merge will look like it's winning even while GitClear's data shows code churn — code rewritten or deleted within two weeks of being committed — nearly doubled from 3.1% to 5.7% between 2020 and 2024 as AI-assisted coding scaled.

The METR reversal: from 19% slower to 18% faster in twelve months

METR's July 2025 study is the most rigorous piece of AI coding productivity study data published to date, and it's also the most misquoted. Sixteen experienced open-source developers, working on real tasks in repositories they'd maintained for an average of five years, were randomly assigned to use AI tools or not. The developers using AI took 19% longer to complete their work — despite predicting beforehand that AI would make them 24% faster, and believing afterward that it had sped them up by 20%. Their perception and the measured reality were pointed in opposite directions.

By early 2026, METR revisited a subset of that same developer cohort and now estimates a speedup of roughly 18% (confidence interval: -38% to +9%, so the uncertainty band is still wide). That's a 37-percentage-point swing in a single year, and METR's own explanation is straightforward: the tools got better, and — more importantly — the developers learned how to use them. The lesson for anyone reading a single AI-productivity headline number: ask how long the study's participants had been using the tools before the clock started.

AI coding productivity by task type: where the real gains concentrate

Lay the numbers side by side and a pattern emerges: the closer a task is to boilerplate — scaffolding an HTTP server, writing tests, drafting a PR description — the bigger the reported gain. The closer it is to a real engineering judgment call in an unfamiliar, high-stakes codebase, the closer the gain gets to zero, and in METR's early-2025 snapshot, negative. Opsera's dataset backs this up structurally: senior engineers captured nearly 5x the productivity gains of junior engineers, because seniors have the judgment to know when to trust an AI suggestion and when to override it. Juniors mostly don't yet, which is also why AI-authored pull requests took 4.6x longer to clear code review in the same dataset — someone senior still has to check the work.

The AI coding productivity study data on code quality and security

Speed and quality are not the same measurement, and the studies that only report speed are the ones getting quoted the most. The quality-focused data tells a less flattering story.

CodeRabbit's review of 470 real-world pull requests found AI-generated code produced 1.7x more issues than human-written code. Academic and OWASP-aligned research puts the share of AI-generated snippets containing at least one CWE-class vulnerability at 30-40%. A March 2026 study spanning 304,362 AI-authored commits across 6,275 repositories found that security issues introduced by AI had a 41.1% survival rate — meaning fewer than half get caught before merge. And GitClear's analysis of 211 million lines of code found the average developer checked in 75% more code in 2025 than in 2022, which is exactly the volume increase you'd expect if speed gains are real but review rigor hasn't scaled to match.

Study-by-study comparison: what each AI coding productivity dataset actually measured

Figures compiled from METR (metr.org, July 2025 and February 2026 posts), McKinsey enterprise developer research, Opsera's 2026 AI Coding Impact Benchmark Report, GitHub/Copilot enterprise case studies, GitClear's 2026 maintainability research, and CodeRabbit's State of AI vs. Human Code Generation report. Methodologies and sample definitions differ across studies and are not directly comparable.

Why AI coding productivity study data varies so much between reports

Three variables explain almost all of the spread in these numbers. First, task complexity — McKinsey's own 46%-vs-under-10% split within a single study proves this isn't a methodology quirk, it's the actual shape of the effect. Second, tenure with the tools — METR's 37-point swing over twelve months shows the learning curve is not a rounding error, it's the majority of the effect. Third, what gets measured — time-to-PR looks great in isolation, but pair it with 4.6x longer review times and 2.74x more security vulnerabilities and the net picture changes substantially.

For VCs and operators, this matters beyond a curiosity about developer tooling. Engineering velocity claims show up in diligence decks constantly now — "we shipped 3x faster with AI" is the 2026 equivalent of "we're capital efficient." The study data says: ask which task type they're measuring, ask how long the team has used the tools, and ask what their AI-authored code churn and vulnerability rate look like, not just their PR count. We track the downstream effect of engineering velocity on hiring and headcount trends and on SaaS valuation multiples, and the teams that are actually compounding are the ones treating AI coding tools as a skill to be trained, not a switch to be flipped.

How I read the AI coding productivity data as an investor

I've made 65+ investments and operated engineering teams across three startups, and the pattern in this data matches what I see in portfolio companies directly: the founders who got real gains from AI coding tools are six-plus months into deliberate adoption — code review standards adjusted, prompting practices standardized, security scanning tightened — not founders who bolted on Copilot or Cursor last month and are reporting week-one anecdotes as a permanent multiplier.

The adoption numbers back this pattern: 84% of developers now use or plan to use AI coding tools and 51% use them daily, but trust in the output has actually fallen — from 40% in 2024 to 29% in 2026. That's not contradictory, it's healthy. Developers are using the tools more while trusting them less blindly, which is exactly the behavior that turns a 19% slowdown into an 18% speedup over twelve months. The teams treating that 29% trust number as a design constraint — heavier code review, tighter security gates on AI-authored PRs — are the ones who will show up as durable productivity gains in next year's study data instead of this year's churn and vulnerability statistics.