Does AI Actually Make Developers Faster? The 2026 Data Says It's Complicated

Short answer: It depends heavily on context. AI coding tools speed up simple, well-defined, low-complexity work substantially. On complex tasks inside large, unfamiliar-to-the-model codebases, a rigorous 2025 randomized controlled trial found experienced developers were 19% slower with AI tools - despite believing they were 20% faster. Adoption is near-universal (84-90% of developers use AI tools regularly), but trust in AI output has fallen even as usage has climbed, and AI-generated code carries a measurably higher security vulnerability rate than human-written code. The rest of this article breaks down exactly where each of those findings comes from and what it means for how you should actually use these tools.

Introduction: The Study That Contradicts the Marketing

Most content about AI in software development in 2026 falls into one of two camps: vendor marketing claiming universal productivity gains, or general skepticism with no data behind it. Neither is very useful if you're actually deciding how your team should use these tools.

So start with the single most rigorous study on this question published to date. In July 2025, the AI safety research nonprofit METR ran a randomized controlled trial - the same methodology used in clinical drug trials - with 16 experienced open-source developers completing 246 real tasks in mature codebases they'd worked in for an average of five years. Before starting, the developers predicted AI tools would cut their completion time by 24%. Afterward, they estimated AI had sped them up by 20%. The actual measured result: AI tools made them 19% slower.

That's not a small miscalibration. It's a nearly 40-percentage-point gap between what developers believed happened and what a stopwatch recorded. Economists and machine learning experts surveyed beforehand predicted even bigger speedups (38-39% faster) - so this wasn't a case of skeptics being proven right. Nearly everyone expected AI to help. The data said otherwise, in this specific setting.

That word - setting - matters, and it's the key to using this research correctly. METR's own paper is explicit that this result describes experienced developers working in large, mature codebases they already know extremely well, using February-June 2025 AI tools (primarily Cursor Pro with Claude 3.5/3.7 Sonnet). The researchers themselves caution against overgeneralizing: it's plausible AI tools are genuinely useful in other contexts - for junior developers, for someone working in an unfamiliar codebase, or for narrower, more repetitive tasks. Other 2025-2026 research backs that up: AI tools show speedups of up to 90% on greenfield projects with no existing codebase to reconcile against, and gains of 27-39% for junior developers learning new technology. The honest conclusion isn't "AI slows developers down." It's "AI's effect depends enormously on the type of task and the developer's existing familiarity with the code" - which is a much more useful and specific finding than either the hype or the backlash suggests.

Adoption Is Near-Universal - But Trust Is Falling as Usage Rises

This is the part of the 2025-2026 data that doesn't follow the usual technology-adoption pattern. Normally, the more people use something, the more they trust it. With AI coding tools, Stack Overflow's 2025 Developer Survey - nearly 49,000 responses across 177 countries - found the opposite: usage climbed to 84% (up from 76% the year before), while trust in the accuracy of AI-generated output fell to 29%, down from 40% the year prior.

GitHub's Octoverse 2025 report, drawing on its 180-million-developer platform, shows just how fast adoption has become the default rather than the exception: nearly 80% of new developers who joined GitHub in 2025 adopted GitHub Copilot within their first week on the platform. Separately, JetBrains' late-2025 survey of roughly 25,000 developers put regular AI tool usage at 85%, and Google's internal data reported around 90% adoption among its software engineers. Depending on which 2025-2026 survey you check, somewhere between 84% and 90% of professional developers now use AI coding tools regularly. Adoption, in other words, is no longer a meaningful question. What's worth digging into is why trust is dropping at the same time usage is rising.

The Stack Overflow data has a specific answer: 66% of developers say AI output is frequently "almost right, but not quite" - and 45% report that debugging AI-generated code takes longer than writing the equivalent code themselves would have. That's the mechanism behind the falling-trust number. AI is fast at producing a first draft. It is not necessarily fast once you count the time spent verifying that draft - especially for anything beyond boilerplate, and especially for business logic, edge cases, or anything touching production data. This is the same underlying phenomenon the METR RCT measured directly with a stopwatch instead of a survey question: the speed of generation and the speed of shipping working, correct code are two different numbers, and AI reliably improves the first one while its effect on the second is far more conditional.

The Security Data: A More Serious Problem Than "Almost Right" Code

Beyond speed, there's a second, more consequential finding in the 2025-2026 research: AI-generated code has a measurably higher rate of security vulnerabilities than human-written code, and this holds across multiple independent studies using different methodologies.

Veracode's 2025 GenAI Code Security Report - one of the most comprehensive studies of its kind, testing over 100 large language models across 80 coding tasks in Java, Python, C#, and JavaScript - found that 45% of AI-generated code samples failed security tests, meaning they introduced at least one OWASP Top 10 vulnerability. Two specific vulnerability classes stood out badly: 86% of samples failed to defend against cross-site scripting, and 88% were vulnerable to log injection. Java performed worst, with a 70%+ failure rate. Separately, an independent 2026 study by AppSec Santa, testing 534 code samples across six major current-generation LLMs (including GPT-5.2, Claude Opus 4.6, and Gemini 2.5 Pro) against the OWASP Top 10 specifically, found roughly 1 in 4 AI-generated code samples contained a confirmed vulnerability - a somewhat lower number than Veracode's, but the gap reflects different testing methodology, not a contradiction. CodeRabbit's separate analysis of production pull requests found AI-generated code carries roughly 1.9-2.7x the vulnerability density of human-written code in the same codebases.

This isn't a hypothetical risk. In 2025, a specific, now-public case illustrates exactly how this plays out: CVE-2025-48757 was assigned after a security researcher found that AI-generated Supabase database schemas (via the Lovable platform) were routinely missing Row Level Security configuration - the setting that restricts who can query which rows in a database. Over 170 production applications built this way were found exposing data they shouldn't have. Separately, GitGuardian's 2026 State of Secrets Sprawl report found AI-assisted commits leak hardcoded credentials at roughly double the rate of the general public-repository baseline (3.2% versus 1.5%).

Interestingly, this isn't purely a story of AI making security worse everywhere. GitHub's Octoverse 2025 data shows the average time to fix a known, flagged critical vulnerability actually dropped 30% in 2025 (from 37 days to 26), and automated dependency-patching adoption (Dependabot) grew 137% - because AI-assisted tooling is also making remediation and detection faster once a problem is caught. The risk isn't that AI makes all security worse across the board; it's specifically that AI-generated code, before review, contains more first-pass vulnerabilities than a careful human writing the same logic - and that gap is large enough (45% vs. an established human baseline of roughly 30-35% fewer critical flaws in equivalent enterprise audits) that skipping security review on AI output is a measurably worse bet than skipping it on human-written code.

Where AI Coding Tools Are Genuinely Winning

None of the above means these tools aren't worth using - the research is specific about where they hold up well, and it's worth being just as precise about the wins as the risks:

• Boilerplate and scaffolding. Repetitive, well-understood patterns - CRUD structures, config files, initial component layouts - where a wrong output is both low-risk and easy to spot.
• Greenfield projects. Research cited across multiple 2025-2026 industry analyses shows AI speedups of up to 90% on new projects with no existing codebase to reconcile against - the exact opposite setting from the METR study, and a genuinely strong use case.
• Learning and onboarding. Junior developers and anyone working in an unfamiliar codebase or new technology report the largest, most consistent gains - commonly cited in the 27-39% range - because AI is filling a genuine knowledge gap rather than competing with existing expertise.
• Language and dependency shifts. GitHub's 2025 data found TypeScript overtook Python and JavaScript to become the most-used language on the platform, driven partly by the fact that static typing gives AI tools clearer guardrails when generating code - a real, measurable shift in how teams are structuring new projects around AI-friendly patterns.
• First-pass code review and test scaffolding. Catching obvious issues before a human reviewer spends time on them, or generating the shape of a test suite that a developer then fills in and verifies rather than trusting blindly.

A Working Framework: Match the Tool to the Task, Not the Hype

Pulling all of the above together, the pattern that holds up across the METR trial, the Stack Overflow survey, and the security research is consistent: AI's value is highest on low-familiarity, low-complexity, low-risk-if-wrong work, and drops - sometimes below zero - on high-familiarity, high-complexity, high-risk-if-wrong work. A practical way to apply that:

1. Let AI draft; keep humans deciding. Boilerplate, scaffolding, and first drafts - yes, generate freely. Final logic in anything security- or data-sensitive - always human-reviewed before merge, given the 45% vulnerability rate in unreviewed AI output.
2. Weight AI use by codebase familiarity, not developer seniority. The METR result was specifically about experienced developers in codebases they already knew well. The same developer working in an unfamiliar part of a large system, or a junior developer learning the codebase, is a different - and generally more favorable - case for AI assistance.
3. Treat security review as mandatory, not optional, for AI-generated code. Given that AI output fails OWASP Top 10 checks at roughly 1.5-2x the rate of human code across independent studies, security review should scale up for AI-generated code, not stay the same or get skipped because "the AI already checked it."
4. Watch for "almost right" specifically, not just obvious bugs. Since that's the most common failure mode reported by developers themselves, review AI output for logic that looks plausible but is subtly wrong - not just for syntax errors that a compiler would catch anyway.
5. Don't let AI write and grade its own homework. Tests generated by the same tool that generated the code they're testing can share the same blind spots. Independent human verification, or a second review pass, catches more.

This is exactly the standard that matters for client-facing production software, where a subtly wrong piece of authentication or payment logic is a very different kind of mistake than a subtly wrong internal script. Deliberate, human-reviewed architecture - not raw generation speed - is what actually determines whether a custom-built system holds up in production, and the 2025-2026 research on AI coding tools backs that priority rather than undermining it. For more context on operational AI implementation, explore our guides on AI Automation Use Cases & ROI and Custom Software vs SaaS for Scalability.