The Agentic Developer's Burnout

Siddhant Khare shipped more code last quarter than any quarter in his career. He also felt more drained than any quarter in his career. "We used to call it an engineer," he wrote. "Now it is like a reviewer. Every time it feels like you are a judge at an assembly line and that assembly line is never-ending."¹

Khare is an infrastructure developer. His blog post went viral because it named something thousands of developers were feeling but couldn't articulate. The old burnout was simple: too much work, too little time. The new burnout is stranger. You're shipping faster than ever. Your metrics look great. You feel terrible.

This isn't the same condition that wellness programs are designed to treat. Traditional burnout comes from doing too much. Agentic burnout comes from doing the wrong kind of work. The cognitive load hasn't decreased. It has shifted from creation to evaluation, from flow state to vigilance state, from building things to judging things that a machine built for you.

The science for this has existed for decades, in domains where nobody thought to look for parallels to software engineering. Until now.

The Numbers

In March 2026, BCG surveyed 1,488 U.S. workers and coined a term for the phenomenon: "AI brain fry." 14% of AI-using employees reported it. Those affected experienced 33% more decision fatigue, 39% more major errors, and 19% greater information overload than their peers. They described a "buzzing" feeling, mental fog, slower decision-making, and headaches. 34% of them intended to quit.²

One in seven. That's not a niche complaint. That's a workforce risk.

The same month, METR published results from a randomized controlled trial with 16 experienced open-source developers. The developers using AI tools were 19% slower at completing tasks. They believed they were 20% faster.³ A 39-point gap between perception and reality. They felt the acceleration. The acceleration wasn't there.

Stack Overflow's 2025 survey of 49,000 developers found 84% using AI tools, up from 76% the year before. Trust: under a third, down from 43% the year before. Active distrust of AI accuracy: 46%, up from 31%. 45% cited debugging "almost-right" AI code as time-consuming.⁴

Read those numbers together. Usage is at 84%. Trust is at 29%. Nearly half the people using these tools don't trust them. They use them anyway, because everyone else does, because management expects it, because the tools are genuinely fast. And then they spend their days verifying output they don't trust from tools they can't stop using.

Workday quantified the verification cost: 37% of time saved by AI is lost to rework. Correcting errors, verifying outputs, rewriting content that fails to meet quality or context requirements. Only 14% of employees consistently report net-positive outcomes.⁵

Faros AI analyzed telemetry from 10,000 developers across 1,255 teams. High AI adoption produced a 98% increase in PR volume with a 91% increase in review time.⁶ Nearly twice the code. Nearly twice the time to review each piece. The bottleneck didn't disappear. It moved from writing to reading. And reading someone else's code is the most cognitively expensive thing a developer does.

The Ironies of Automation

In 1983, a cognitive scientist named Lisanne Bainbridge published a paper called "Ironies of Automation." Her argument was simple and devastating: the more reliable automation becomes, the worse humans get at supervising it. Automation removes active tasks and converts operators into monitors. But humans are bad monitors. We lose focus. We trust the system. We stop checking. And when something finally goes wrong, we're the least prepared to catch it.⁷

Bainbridge was writing about industrial control systems. She could have been writing about Cursor.

The vigilance research is even older. In 1948, Norman Mackworth studied RAF radar operators and found detection accuracy dropped 10-15% within 30 minutes of sustained monitoring.⁸ Nuclear power plant research has since found vigilance decrements within 5 minutes.⁹

Five minutes. That's how long a human can reliably monitor a mostly-correct automated system before attention starts to degrade. An AI coding agent produces output every few seconds. Each output is a monitoring event. Each monitoring event requires a trust decision: accept, reject, or modify. Hundreds of these per day.

Baumeister's ego-depletion model (the idea that willpower is a finite resource that gets used up) largely failed to replicate.¹⁰ But Danziger's study of Israeli judges found favorable rulings dropped from 65% to near zero as sessions progressed, spiking after meal breaks. The "willpower battery" explanation may be wrong. The degradation pattern is real. Whether you call it decision fatigue or something else, the hundredth approve/reject decision of the day is measurably worse than the first.

Apply Bainbridge's framework to software development and five things happen simultaneously:

Vigilance decrement. The developer monitors mostly-correct output for defects. Accuracy drops within minutes.

Decision fatigue. Approve, reject, modify. Repeated across every AI suggestion, every PR, every completion. The quality of each decision degrades as the day continues.

Flow deprivation. Csikszentmihalyi's flow state requires challenge matched to skill, clear goals, and a merging of action and awareness. Reviewing breaks all three. The challenge is inconsistent. The goals shift with each suggestion. Action and awareness never merge because you're evaluating, not creating.¹¹

Cognitive overload. Every piece of AI-generated code requires the reviewer to reconstruct the machine's reasoning from its output alone. Gloria Mark's research at UC Irvine found it takes 23 minutes and 15 seconds to return to deep focus after an interruption.¹² AI suggestions interrupt continuously. But they don't feel like interruptions because the work is nominally "yours."

Automation complacency. AI code works 80% of the time. Good enough to build trust. Bad enough to require checking. The trust builds faster than the checking decays. Parasuraman and Manzey's 2010 review found this complacency affects naive and expert operators alike, and cannot be overcome with practice.¹³

Five well-established cognitive phenomena, all converging on the same person at the same desk.

The Speed Trap

UC Berkeley researchers Aruna Ranganathan and Xingqi Maggie Ye spent eight months embedded in a 200-person tech company, observing how AI adoption changed work. They found three forms of intensification.¹⁴

First: task expansion. Product managers started writing code. Researchers handled engineering work. AI made unfamiliar tasks feel "newly accessible," so people took on responsibilities that weren't theirs. Engineers then spent additional time reviewing and coaching colleagues on their AI-assisted output.

Second: blurred boundaries. The conversational interface of AI tools disguised work as casual chatting. People inserted tasks during lunch breaks, during meetings, during file-loading waits. Evenings and mornings absorbed work without deliberate intention.

Third: increased multitasking. Workers managed multiple active AI threads simultaneously. This normalized higher speed expectations without explicit demands.

"You had thought that maybe, oh, because you could be more productive with AI, then you save some time, you can work less. But then really, you don't work less. You just work the same amount or even more."

A Multitudes study of 500+ developers confirmed the pattern: 27% more merged pull requests, 20% more out-of-hours commits.¹⁵ The PRs go up. The hours go up. The burnout follows.

Tim Williams applied Kahneman's dual-process framework to the phenomenon. System 1 is fast, automatic, low-effort. System 2 is slow, deliberate, cognitively expensive. The old development workflow mixed both: routine coding (System 1) gave the brain recovery time between complex design decisions (System 2). AI eliminated the routine coding. What remains is sustained System 2 work with no built-in rest.¹⁶

This explains something counterintuitive. Developers who comfortably coded 14 hours on weekends before AI tools are burning out at 8 hours with them.¹⁷ The duration hasn't changed. The sustained cognitive intensity has.

The Identity Question

Simon Hojberg's essay "The Programmer Identity Crisis" drew 460 points on Hacker News. His argument: prompt engineering erodes deep engagement, creative problem-solving, and theory-building. "Code reviewers are losing their minds realizing they're now the first layer of quality control instead of one of the last."¹⁸

GitHub's 2025 Octoverse report described developers furthest along with AI as seeing their role as "creative director of code." Orchestration and verification, not implementation.¹⁹

Anthropic's own Agentic Coding Trends Report found engineers use AI in roughly 60% of their work but fully delegate only 0-20% of tasks. The rest requires active human oversight.²⁰ Sixty percent AI involvement. Eighty percent supervision. That ratio describes a monitoring job.

An HN thread titled "Identity crisis as a software engineer because of AI" drew experienced engineers sharing the same question: Am I still a developer if I mostly read and approve?²¹

The question is uncomfortable because the honest answer is: it depends on what you think "developer" means. If it means someone who ships software, yes. If it means someone who writes code, less and less. If it means someone who enters a flow state while building things, maybe not at all.

The Uncomfortable Parallel

In 2013, researchers showed expert radiologists CT scans with a gorilla image embedded in them. The gorilla was 48 times larger than the lung nodules the radiologists were trained to find. 83% of them missed it. Many looked directly at it.²²

This is inattentional blindness. When you're monitoring for a specific type of defect, you become blind to unexpected problems. It affects domain experts. It cannot be eliminated with training. It is a fundamental property of human attention.

Nuclear power plant operators went through the same transition a generation ago. Active controllers became passive monitors. Vigilance decrements appeared within 5 minutes of sustained monitoring tasks. The automation was too reliable to distrust, too unreliable to ignore. Researchers described the optimum as a balance between operator fatigue and operator complacency, with AI coding tools potentially occupying the worst zone: reliable enough to trust, unreliable enough to require constant checking.⁹

The NTSB cited "automation complacency" in the 2018 Uber self-driving fatality. Tesla Autopilot users exhibit what researchers call "passenger-like viewing behaviours." They stop watching the road because the car is usually right.

Radiologists. Nuclear operators. Drivers. Software developers. Same transition, same fatigue pattern, different domain. The human brain was not designed for sustained passive monitoring of mostly-correct automated output. No amount of mandate pressure changes the neuroscience.

What Helps

The honest answer: not much, yet. The mitigations that exist are real but fragile.

BCG found that manager support specifically focused on answering AI questions reduced mental fatigue by 15%. Unsupported self-learning increased fatigue by 5%.² Being told to figure out AI on your own is worse than not having AI at all. BCG also found productivity peaks at 3 simultaneous AI tools and drops beyond 4.²³

Addy Osmani, Google's Chrome engineering lead, published a framework he calls "AI Hygiene": reserve one day per week for unassisted coding, struggle through problems independently for 15-30 minutes before consulting AI, red-team every output, explain solutions back in your own words. Anthropic's own research supports the approach. Developers who used AI for conceptual questions scored 65%+ on follow-up quizzes. Those who delegated code generation scored below 40%.²⁴

Stephan Schmidt, a 40-year programming veteran, diagnosed his own unprecedented fatigue: "My brain does not get the baking time to mentally process architecture, decisions and edge cases." His prescription was deliberate pacing. Consciously slow down. Reintroduce the pauses that compilation used to give you for free.²⁵

But here's the trap. In METR's follow-up study, 30-50% of developers chose not to submit certain tasks because they did not want to do them without AI.²⁶ A third of developers can't or won't work without the tool that's burning them out. The "No-AI Day" strategy requires a capability that a significant portion of the workforce has already lost.

Every individual mitigation requires discipline that erodes under mandate pressure. Every organizational mitigation conflicts with the productivity expectations driving AI adoption. The strategy with the strongest evidence (manager support, 15% fatigue reduction) requires the same managers who are under pressure to show AI ROI. The strategy developers want (AI-free days) is the one a third of them can no longer execute.

LeadDev reported that 67% of developers spend more time debugging AI-generated code than they did before, and 59% experience deployment problems at least half the time when using AI coding tools.²⁷ And yet nearly 70% of CEOs use AI less than one hour per week.²⁸ The people mandating adoption don't use the tools themselves. They don't experience the cognitive cost. They see the metrics. The metrics look great.

The GPS Problem

Khare used an analogy that stuck with me. Before GPS, you built mental maps. You knew your city. After years of GPS, you can't navigate without it.

The question for software development isn't whether AI makes people more productive. The data says yes, sort of, sometimes, with asterisks. NBER found mean time savings of 5.4% among AI users and 1.4% across all workers.²⁹ A separate NBER study found 9 in 10 executives reported no measurable impact on employment or productivity from AI over the past three years.³⁰ The gains are real. They are also far more modest than the sales pitch.

The real question is what the asterisks cost.

METR's finding is the sharpest version: developers believed they were 20% faster while being 19% slower. The perception of acceleration was real. The exhaustion was real. The acceleration was not.

That gap between how fast you feel and how fast you are might be the most precise definition of agentic burnout anyone has found. You're running on a treadmill that's speeding up, watching numbers climb on a dashboard, while your brain burns through its monitoring capacity in 5-minute increments. The metrics say you're thriving. Your prefrontal cortex disagrees.

Bainbridge wrote her paper 43 years ago. The ironies she identified have played out in aviation, nuclear power, autonomous driving, and radiology. Software development is the latest domain to discover that automating the easy parts doesn't make the job easier. It makes the hard parts harder, and it makes them all that's left.