The Numbers Don't Add Up
In 2026, 84% of developers use AI coding tools. AI-generated code now accounts for 41% of all committed code, projected to reach 65% by 2027. The market narrative is productivity transformation.
Then there's the METR study.
Published in July 2025, it tested 16 experienced open-source contributors on 246 real tasks drawn from their own projects — repositories averaging 22,000 GitHub stars and over one million lines of code. The result: developers using AI tools took 19% longer to complete tasks than those without.
The perception gap is what makes the finding particularly striking. After the study, those same developers estimated that AI had sped them up by 20%. They were measurably slower while believing they were faster.
Understanding the Slowdown
The disconnect between perception and performance has several identifiable causes.
Prompt iteration overhead
Working with AI requires repeated prompt refinement. Getting the output you actually need — not just plausible-looking output — involves cycles of specifying, receiving, evaluating, and re-specifying. For complex tasks, this iteration cost can exceed the time saved on the actual implementation.
Verification load
AI-generated code cannot be merged without review. A separate dataset shows AI-generated code contains 2.74x more security vulnerabilities than human-written code. The time saved writing code is partially offset by the time spent verifying it. For security-sensitive code paths, that offset can be complete.
Automation bias
There's a well-documented psychological tendency to accept AI output with reduced scrutiny because it looks authoritative and complete. Code that looks correct and code that is correct are different things, but the visual similarity makes the distinction easy to miss in a review.
Atrophied tooling habits
Developers who rely heavily on AI tend to reach less for debuggers, profilers, and purpose-built analysis tools. Over time, this creates a gap in the debugging and diagnostic skills that AI cannot yet substitute.
The February 2026 Update
METR published a follow-up in February 2026, and it revealed a new methodological problem: developers are now so dependent on AI tools that they refuse to participate in control groups where AI is prohibited.
This is a significant signal. AI tools have transitioned from "useful addition" to "assumed prerequisite" for a growing segment of the developer population. Measuring productivity without AI access has become comparable to measuring productivity without internet access — the baseline itself has shifted.
METR's assessment is that developers are likely more sped up by late-2025 AI tools than by early-2025 tools, but their experimental design can no longer cleanly measure it.
What Works and What Doesn't
The METR findings have been challenged by practitioners who argue that lab conditions don't map to real-world workflows. Deloitte's 2026 Software Industry Outlook projects 30–35% productivity gains from properly applied AI. The gap between "properly applied" and "casually adopted" is where the METR numbers live.
Teams that report genuine productivity improvements share recognizable patterns.
Task-type discipline
AI delivers consistent speed gains on well-scoped, pattern-heavy tasks:
High-leverage AI tasks:
- Boilerplate generation within established patterns
- Test case generation from existing implementations
- Library API usage and documentation lookup
- Refactoring suggestions with clear before/after criteria
- Regex, SQL, and configuration generation
Low-leverage AI tasks:
- Architecture decisions with significant trade-offs
- Ambiguous requirements that need human clarification
- Security-critical logic requiring deep domain reasoning
- Novel integrations with undocumented behavior
Structured verification
Teams that treat AI output as unreviewed code — not as approved code that happens to need a signature — catch problems before they compound. A short mandatory checklist for AI-generated changes reduces the automation bias effect:
// Common issues to check in AI-generated code:
// 1. Missing null/error handling
async function getUser(id: string) {
const user = await db.users.findOne({ id });
// AI often omits: what happens when user is null?
if (!user) throw new NotFoundError(`User ${id} not found`);
return user;
}
// 2. Silent data loss in transformations
// 3. Hardcoded values that should be configurable
// 4. Missing input validation at boundary functions
// 5. Over-permissive error handling (catch-all without logging)Using AI output as input, not output
The most effective teams treat AI-generated code as a first draft to think from, not a final result to approve. The question shifts from "does this look right?" to "what would I have written differently, and why?"
The Dependency Signal
The 2026 update's methodological problem — developers refusing to work without AI — is worth sitting with. It means measuring "before and after AI" is becoming as meaningless as measuring "before and after Google."
This matters for how engineering organizations should think about capability development. If critical reasoning, security judgment, and architectural thinking are skills that atrophy under constant AI delegation, and if those same skills are what make AI output useful to review, then the teams that maintain those skills deliberately will have a compounding advantage.
Webhani's Take
The METR findings are not an argument against using AI tools. They are an argument for using them with intention rather than habit.
Adoption without workflow redesign is what produces the 19% slowdown. The developers in the METR study were using AI because it was available and felt productive, not because they had a deliberate framework for which tasks to delegate and how to verify the results.
At webhani, we treat AI tool adoption as a workflow design problem as much as a tooling selection problem. What tasks get delegated, how outputs get verified, and how teams maintain the reasoning skills that make verification meaningful — these are engineering decisions, not incidental to tool adoption.
84% adoption means the conversation has moved past "should we use AI" to "are we using it in a way that actually helps."