The output is faster. So why does the work feel worse?
Alec Scollon describes a way of working with AI that, by current developer standards, is not especially exotic. He works on one task at a time, discusses it with Claude Code at work or Codex at home, reads the generated code carefully, tries to understand it, and revises it when necessary. In his own words, his usage is probably average and his methods “primitive.” He is not deep into autonomous-agent orchestration. He simply spends hours each day reading model-generated text, which is already a fairly radical change from how he worked only a few years ago. [1]
On July 8, 2026, Scollon published I Think I Have LLM Burnout. The essay reached the front page of Hacker News and drew more than 400 points and hundreds of comments. [1][2] What travelled through the developer community was not a dramatic claim that AI had ruined programming. His complaint was smaller, and probably more recognizable because of it: after spending so much time inside model output, he had started to dread reading it.
He still thought LLMs made him more productive. He did not pretend that human engineers are reliable by comparison; humans make false assumptions, write bad code and irritate one another perfectly well without machine assistance. What seemed to be wearing him down was the recurrence. The same stylistic tics kept resurfacing, along with the same kinds of misplaced confidence and familiar mistakes.
His job, as he described it, had changed from designing and writing code into something more layered: design the code, explain that design to the model, review what comes back, then write or repair whatever remains. The change sounds modest when reduced to a workflow diagram. After several hours a day, every day, for roughly a year, it no longer felt modest to him. [1]
“I don’t know how to deal with this feeling yet,” he wrote. The uncertainty is probably more useful than trying to diagnose him from the outside.
AI inside a system that was already overloaded
Eric Ma wrote about a different experience a few months earlier. His circumstances were untidier and, importantly, he did not retrospectively force them into a clean causal story. Work was already overloaded. Meetings could be triple- or quadruple-booked, operational and personnel problems were active at the same time, and several unrelated categories of work had to remain mentally open. He later wrote that he still could not identify one exact cause for the stress he experienced. [3]
AI was nevertheless part of the environment. During the first quarter of 2026, Ma had gone heavily into coding agents. He could test ideas rapidly and reshape large parts of codebases with a speed that would previously have required considerably more time.
He found that pace stimulating, and also disorienting. In his account, the compression of time created by AI-assisted coding became entangled with questions about how durable the work was and how much of the pace could actually be sustained.
His essay, How I Recognized and Handled AI Burnout, is useful because it refuses the easiest explanation. AI entered an environment in which the load was already too high, making it difficult to separate the technology from the organizational conditions surrounding it. [3]
What changes when AI makes work faster?
Scollon called his experience LLM burnout, and Ma also wrote about AI burnout. But those two stories do not by themselves show that AI has created a new form of burnout. What they do show is that AI can change the pace and shape of an already demanding workday.
The most obvious change is speed. A developer can generate code in seconds, but someone still has to read and test it. A researcher can produce a summary almost instantly, but the claims and sources still need verification. A manager can create several drafts in the time it once took to write one, but someone still has to decide which one is actually usable.
AI can reduce the time needed to produce work without reducing the time needed to judge it.
That difference becomes more important as output grows. If five versions can now be produced where there used to be one, there may also be five versions to compare, reject or correct. And the extra work does not necessarily stay with the person who benefited from the faster production.
A developer may generate a pull request in minutes while a colleague spends much longer reviewing it. A report may be drafted quickly while someone else later has to verify its sources. Some of the time saved at one point in the workflow can reappear as work somewhere else.
This brings the discussion back to burnout as we already understand it. The World Health Organization describes burnout as an occupational phenomenon resulting from chronic workplace stress that has not been successfully managed, associated with exhaustion, growing mental distance or cynicism toward work, and reduced professional effectiveness. [4]
We do not yet have evidence that “AI burnout” is a separate condition. But we do have a clearer question to investigate: if AI allows more work to be produced, reviewed and decided on within the same working day, does that added density contribute to the chronic workplace stress we already know can lead to burnout?
Productivity rises, and the workload does not politely disappear
The intuitive promise of faster production is simple: if AI helps people finish work sooner, the workday should become lighter.
The reality is rarely that neat.
A 2025 survey by the Upwork Research Institute of 2,500 professionals makes the tension hard to miss. Workers using AI reported an average productivity increase of 40 percent. Yet among those reporting the highest gains, 88 percent also reported burnout. They were roughly twice as likely to consider quitting, and 62 percent said they did not understand how their daily AI use connected to their organization’s broader goals. [5]
Those numbers do not prove that AI caused the burnout. The survey was self-reported, and people already under pressure may have adopted AI more aggressively or simply been given more work once their output increased. But the pattern itself is difficult to ignore: feeling much more productive does not translate into feeling less exhausted.
A 2026 tech-worker sentiment survey showed a similar split. In How Tech Workers Are Feeling in 2026, 82 percent of respondents said AI made them better at their jobs, while significant burnout rose from 44.7 percent to 55.7 percent year over year. [6] Their concerns were practical rather than abstract. Workers worried about being expected to do more for the same pay, maintaining an unsustainable pace, and watching quality deteriorate as output increased.
This points to an organizational habit that existed long before AI but becomes easier to amplify with it: freed capacity attracts more work.
If a task that once took an hour now takes twenty minutes, the remaining forty minutes rarely become recovery time. They become available capacity. Once that happens repeatedly, yesterday’s exceptional throughput can quietly become today’s expected baseline.
Productivity rises, but the experience of work gets worse
As that baseline rises, the question is what happens to the day-to-day experience of doing the work.
Productivity metrics are good at showing how much gets finished. They are much worse at showing how much attention is required to keep that faster output understandable, correct, and usable. A workflow can become faster without necessarily becoming easier to live inside.
In a longitudinal study at the University of Auckland, Annie Vella and Kelly Blincoe tracked professional software engineers across two surveys six months apart. At both checkpoints, 84 percent said AI coding assistants improved their productivity. [7]
Developer experience moved differently. Among the engineers who responded at both checkpoints, the share reporting deterioration in at least one dimension nearly doubled, from 14 percent to 27 percent. Vella and Blincoe call this the productivity–experience paradox. [7]
In plainer terms, the dashboard looks happier than the person doing the work.
The nature of the work was changing at the same time. Eighty-two percent reported spending less time writing code, while more effort shifted toward directing AI, evaluating what it returned, and correcting the output. Vella and Blincoe describe this as supervisory engineering work. [7]
A controlled study presented at CHI 2026 found a similar tension under experimental conditions. Sixty programmers completed Python tasks with and without AI assistance. AI reduced completion time by 22 percent, improved correctness, and even lowered conventional workload scores. [8]
Yet across repeated tasks, fatigue accumulated faster in the AI group. The researchers found that verification load—measured through things such as compile failures, code churn, pauses, and context switches—partially explained that increase. [8]
That result helps explain what the productivity numbers miss. Less time spent producing something does not necessarily mean less human effort overall. Some of that effort moves into reading, checking, comparing, correcting, and deciding whether the generated result can actually be trusted.
Traditional productivity accounting has trouble seeing that labor. A developer may spend less time typing code but far more time tracing why a generated test passed, comparing several plausible implementations, or repairing logic that looked correct at first glance.
Then all of that human effort gets compressed into two words: “used AI.”
The speed is visible. The attention spent making the result usable often is not.
And that may be the most recognizable part of the paradox: AI can work exactly as advertised—you finish more, and you finish it faster—while you still reach the end of the day wondering why you feel more tired than before.
The time saved by one person often becomes work for someone else
There is another part of this productivity gain that is easy to miss: the person who saves the time is not always the person who does the checking.
This dynamic shows up especially clearly in software teams. AI can help one developer produce a change very quickly, but before that change reaches users, someone else may still have to understand it, question it, test it, and decide whether it is safe to keep.
Sebastian Baltes, Marc Cheong and Christoph Treude found this pattern repeatedly in developer discussions about low-quality AI-generated code. They describe it as a tragedy of the commons. [9]
The author gets the productivity gain. The reviewer gets the uncertainty.
Or, to borrow an old idea and update it for AI: the lunch may be free for one person, but someone else still has to wash the dishes.
In one team described in the study, six reviewers were dealing with around thirty pull requests a day. The frustration was not simply that AI-generated code was wrong. Someone still had to determine whether it was wrong, where the problem was, and what could safely be accepted. [9]
Software makes this exchange unusually visible because review is an explicit part of the workflow. But the pattern itself is familiar outside engineering too. A report appears in minutes; someone still checks the claims. A presentation is drafted instantly; someone still decides whether the argument holds together.
AI can make creation dramatically faster without making judgment equally fast.
The work gets faster, but the human burden does not disappear
Once this kind of checking becomes part of almost every task, the cost stops looking dramatic. It just becomes part of the day.
A report appears in minutes, but you still read it line by line because one confident sentence feels slightly wrong. A presentation is finished before lunch, but you spend another hour deciding which claims are actually defensible. AI gives you three reasonable options, and instead of having no answer, you now have a different problem: choosing which answer you are willing to stand behind.
None of these moments feels large enough to call a crisis.
That is precisely why they are easy to miss.
The work arrives faster. The decisions do not.
Over a day, those small decisions accumulate: accept this, reject that, check the source, rewrite the paragraph, compare the alternatives, ask one more question, verify one more detail. AI may have done much of the producing, but the responsibility for deciding what is good enough to keep still belongs to a person.
This is what I mean by supervisory exhaustion.
Not a new diagnosis, but a name for something much more ordinary: the fatigue that builds when more and more of the working day is spent watching, checking, correcting, and taking responsibility for work that can now be produced almost instantly.
And this may explain the strange feeling running through this entire story.
AI works.
You get more done. Things move faster. The dashboard looks better.
And somehow, at the end of the day, you are still tired.
Maybe even more tired than before.
References
[1] Scollon, A. (2026). I Think I Have LLM Burnout. Personal essay, July 8, 2026.
[2] Hacker News. (2026). I think I have LLM burnout — discussion thread. More than 400 points and hundreds of comments.
[3] Ma, E. J. (2026). How I Recognized and Handled AI Burnout. Personal post-mortem, May 2, 2026.
[4] World Health Organization. (2019). Burn-out an “occupational phenomenon”: International Classification of Diseases.
[5] Upwork Research Institute. (2025). From Tools to Teammates: Navigating the New Human-AI Relationship. Global self-reported survey, n=2,500.
[6] Segal, N., & Rachitsky, L. (2026). How Tech Workers Are Feeling in 2026: A Workforce Splitting in Two. Technology-worker sentiment survey.
[7] Vella, A., & Blincoe, K. (2026). The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study. Longitudinal study of professional software engineers.
[8] Fan, G., Liu, D., Pan, L., & Zhang, R. (2026). When Help Hurts: Verification Load and Fatigue with AI Coding Assistants. Proceedings of CHI 2026, Article 733. Controlled study, n=60.
[9] Baltes, S., Cheong, M., & Treude, C. (2026). “An Endless Stream of AI Slop”: How Developers Discuss the Burden of AI-Assisted Software Development. Qualitative analysis of 1,154 posts across 15 Reddit and Hacker News discussions.
