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. That combination captures the emerging developer burnout problem in a single controlled study.

This research sits alongside a broader picture of AI adoption generating stress rather than relief. Harvard Business Review’s February 2026 research on developers confirmed what many knowledge workers were reporting from personal experience as a driver of developer burnout: AI tool adoption is correlated with increased work intensity rather than decreased workload, and a substantial share of workers who adopted AI tools in 2025 reported working more hours, not fewer, by the end of the year [FLAG: the original draft cited “88 percent of heavy AI users” and “67 percent working more hours” attributed to this HBR piece — I could not verify either specific figure against this or any source. The HBR article’s actual verified numbers are 83% of workers reporting increased workload and 62%/61% burnout among associates/entry-level staff. Confirm the correct figures before publishing.]. 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 Are Driving Developer Burnout

The mechanism behind developer burnout 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 developer 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, and developer burnout is one of the clearest symptoms of that gap. 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 developer 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 on developer burnout 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, precisely the discipline that keeps productivity gains from tipping into developer burnout. 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 developer burnout pattern of more output and more exhaustion simultaneously.

The developer 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.