By
Stuart Kerr, Technology Correspondent,
LiveAIWire
In a study that should have been the
corrective the AI productivity narrative needed, researchers at METR followed
experienced open-source developers in a randomised controlled trial and found
that allowing AI tools access increased task completion time by 19 percent.
The developers themselves estimated they would be 24 percent faster with AI
assistance. The gap between the 24 percent speed improvement developers
expected and the 19 percent slowdown they actually experienced is the most
precise measure yet of the AI productivity illusion. More revealing still: 69
percent of those developers continued using AI coding tools after the study
ended, despite being measurably slower with them. The explanation the
researchers offer, that developers were trading productivity for cognitive
ease, that the tasks felt less effortful even when they took longer, points
to something the industry has not adequately reckoned with: AI tools can be
compelling and counterproductive simultaneously.
This
research sits alongside a broader picture of AI adoption generating stress
rather than relief. Harvard
Business Review’s March 2026 research on developers confirmed what
many knowledge workers were reporting from personal experience: 88 percent of
heavy AI users are experiencing increased burnout, AI tool adoption is
correlated with increased work intensity rather than decreased workload, and
67 percent of workers who adopted AI tools in 2025 reported working more
hours, not fewer, by the end of the year. The productivity paradox is real:
the tools that promise to reduce effort are, for a substantial proportion of
their users, expanding scope and increasing total cognitive load rather than
reducing it.
Why AI Tools Create More Work, Not
Less
The mechanism is consistent across accounts from
developers, marketers, and knowledge workers in multiple industries. AI does
not replace tasks; it accelerates the execution phase of tasks while
expanding what people believe is achievable in the same timeframe. A
developer who can now write boilerplate code in minutes rather than hours
does not stop after writing the boilerplate. They write more code, test more
edge cases, add more features. A marketer who can produce a first draft in
seconds does not produce one piece of content instead of ten. They produce
ten pieces instead of one, with the same hours available for review and
refinement as before. The velocity of production has increased. The time
available for review, judgment, and the high-context decisions that AI cannot
make has not.
The hallucination-checking tax is a specific
version of this problem. AI-generated code, text, and analysis contains
errors at a rate that requires systematic verification before anything
produced is trusted. The verification work is often as cognitively demanding
as the original production task, but it is less interesting, less satisfying,
and invisible in productivity measurements that count outputs rather than the
quality of judgment applied to those outputs. The result is a pattern where
total output volume rises while cognitive satisfaction declines. That
combination is a burnout mechanism, not a productivity
gain.
What Developers Are Actually
Finding
The most honest accounts of AI tool adoption from
experienced developers in 2026 share a common structure: initial excitement,
significant productivity gains on specific task types, gradual discovery of
the verification overhead, and eventual recalibration toward using AI tools
for the tasks where they reliably help and not using them for the tasks where
the verification cost exceeds the production benefit. That recalibration
process takes months and requires the kind of accumulated personal evidence
that only comes from using tools across a variety of real tasks, not from
demos or benchmarks.
The 95 percent of companies that
McKinsey found had seen no measurable return on AI investment by 2025 are
largely companies that have not yet completed this recalibration process.
They have deployed tools broadly without the specificity about which tasks
benefit from AI acceleration and which do not. The companies seeing
measurable returns are, consistently, those that have identified specific
high-volume, well-defined tasks where AI accelerates reliable output and
deployed it there, rather than applying AI broadly across every function and
hoping for aggregate efficiency gains that require task-specific fit to
materialise.
What Comes After Boring
The
burnout and disillusionment phase that many developers are experiencing in
2026 is not the end of the AI productivity story. It is a necessary
correction after an adoption period characterised by unrealistic claims,
insufficient specificity about which tasks benefit, and inadequate attention
to the overhead costs that AI assistance introduces alongside its benefits.
The developers who come out of this phase with well-calibrated, task-specific
AI workflows will be materially more productive than those who either
abandoned AI tools entirely or continued using them
indiscriminately.
Understanding how
AI products need to be designed to maintain genuine user value
rather than just initial excitement is the product side of this same
challenge. And the broader dynamics of how
AI is actually changing what knowledge workers do are being shaped
by exactly the recalibration process described here: not mass displacement,
and not uniform productivity gain, but a slow, uneven sorting of which tasks
benefit from AI and which require the kind of human judgment that AI
accelerates at the cost of amplifying errors. The data is telling us
something specific. The question is whether the industry is ready to listen
to it. Why
people keep using AI tools despite the evidence of their
limitations is the psychological counterpart to the productivity
data: the two stories together explain the current moment more completely
than either does alone.
What the Best Developers Are
Actually Doing
The developers who report the most positive
experience with AI tools in 2026 share a common characteristic: they have
developed explicit rules about which tasks they use AI for and which they do
not. These rules are task-specific rather than tool-specific. AI code
generation for boilerplate and repeated patterns: yes. AI code generation for
the core algorithmic logic where understanding the code deeply matters for
maintaining it: no, or with significantly more verification investment. AI
draft generation for routine communications: yes. AI as the primary author of
communications where the relationship with the recipient matters more than
the efficiency of production: no. The rules vary by role and context, but the
presence of any explicit rules at all is a consistent predictor of positive
experience with AI tools, far more than the specific tools chosen or the
volume of adoption.
The research from the METR developer
productivity study found that the tasks where AI assistance
produced genuine speed improvements were concentrated in well-defined,
bounded subtasks with clear success criteria. The tasks where it slowed
developers down were those requiring sustained context over long periods,
judgment about architecture trade-offs, and the kind of understanding of why
code works that matters for debugging novel failures. That is not a reason to
avoid AI tools; it is a specification of where to apply them. The developers
who have worked out that specification for their own role and context are the
ones reporting genuine productivity gains rather than the productivity
paradox of more output and more exhaustion
simultaneously.
The burnout data is not an argument against
AI tools; it is an argument for using them with the same intentionality that
makes any powerful tool useful rather than
exhausting.
About the Author
Stuart
Kerr is Technology Correspondent at LiveAIWire, covering artificial
intelligence, cybersecurity, and the social impact of emerging technology. He
publishes daily at LiveAIWire.com.