Skip to content
Published on

LLM Burnout: When the Job Becomes Reviewing the Work Instead of Doing It

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Share
Authors

Introduction — the post that trended

On July 8, 2026, a developer named Alec Scollon published a short essay titled "I Think I Have LLM Burnout." It climbed Hacker News quickly, which usually means it named something a lot of people were already feeling but had not put into words.

The claim is not that AI tools are bad. It is that something about the shape of the workday has quietly changed, and the change is tiring in a way that is hard to explain to anyone who has not lived it. That gap between "I use these tools all day" and "and it is wearing me out" is exactly what the piece captures.

I want to represent his argument accurately, then add a grounded take of my own: where LLM assistance genuinely earns its place, and where the constant reviewing and context-switching wear people down. No doomerism, no boosterism, and no pretending the fatigue is a personal failing.

What the essay actually says

Scollon is not anti-AI. He spends hours a day reading LLM output, both reviewing code from an assistant and sifting through the results of an agent he lets run unsupervised, and he is clear that the tools expose him to approaches he would not have reached on his own.

He is careful to credit what works. The models teach him things, surface designs he would not have considered, and move the routine parts of the job faster. This is not a complaint dressed up as fake balance; the value is real, which is exactly what makes the fatigue confusing rather than obvious.

His workflow has folded into a loop: he designs the code, describes the design to a model, reviews what the model produces, and only then writes code himself. The act of programming is still there, but it now sits at the end of a pipeline of prompting and reading.

The fatigue, he argues, is not really about the errors. It is about repetition. In his words, "LLMs write in the same style, and they make the same kinds of mistakes." The false assumptions, the hallucinations, the clipped staccato phrasing, the excessive emojis: none of them is severe on its own, but meeting the same handful of tics over and over grinds him down.

What makes the essay land is its honesty about not having a fix. He mentions personalization settings and admits they only go so far. He ends without resolving it: "I don't know how to deal with this feeling yet." That refusal to tie a neat bow on it is probably why it resonated so widely.

The real cost: reviewing is work

The uncomfortable insight underneath all of this is simple. Generation got cheap; verification did not. A model can produce a page of plausible code or prose in seconds, but checking whether it is correct still runs at human speed, and often slower than writing it yourself would have.

That asymmetry is the whole problem. When your day fills up with output that something generated in seconds, the reviewing does not feel like a lighter version of the old job. It feels heavier, and there are concrete reasons why:

  • Reading unfamiliar code critically is more effortful than writing your own, where you already hold the intent in your head.
  • Plausible-looking output lowers your guard, so catching a subtle wrong assumption takes more attention, not less.
  • The failures repeat, so you are re-checking the same categories of mistake all day instead of meeting fresh, interesting problems.

This is the part worth naming on a blog that keeps repeating "verify everything." Verification is not a formality you tack on after the real work; reviewing AI output is the work now, and it carries a real cognitive cost that rarely shows up in a productivity dashboard. The Hacker News thread was full of the same observation: people describing stacks of generated documents they had to fact-check, and the growing sense that "faster to produce" had quietly become "slower to trust."

It is worth separating this from ordinary overwork. Classic burnout usually comes from volume: too many hours, too many tickets. This is different. You can be working fewer hours and still feel hollowed out, because the composition of the work changed underneath you from making things to auditing them. Naming which kind of tired you are is the first step to fixing the right thing.

Where the tools still earn their keep

None of this means the tools are a net negative, and the honest version of this post has to say so plainly. LLMs are genuinely good at boilerplate, at scaffolding a UI, at getting you oriented in an unfamiliar language or domain where the research overhead used to be prohibitive. Used there, they remove drudgery instead of adding it, and the review cost stays low because the stakes are low.

The wear comes from a few specific places, and it helps to separate them:

  • The constant mode-switching between author and reviewer, which are genuinely different cognitive gears.
  • The sameness Scollon points at: reviewing output that always fails in the same ways.
  • The hype treadmill and tool churn, where a new model or workflow arrives every few weeks and re-learning it becomes its own tax.
  • The pressure to route everything through a model, sometimes because a company is literally counting tokens.

The clearest wins in the discussion were the same ones: scaffolding, unfamiliar languages, and side projects where the research cost used to be the thing that killed momentum before it started. Almost nobody argued the tools were useless. The argument was about proportion, and about what happens when the exception quietly becomes the default.

So the tools earn their keep when you choose them deliberately for tasks that suit them. They wear you down when the default silently becomes "generate first, always."

That reframing matters because it changes what you can do about it. If the fatigue were really about model quality, you would just wait for a better model. But if it is about the ratio of producing to reviewing, that is a dial you can actually turn yourself.

Closing

Scollon's essay is worth reading precisely because it does not overclaim. The burnout he describes is not an addiction and not the model's fault; it is a structural shift in what the job is made of, and naming it is the first honest step.

The practical move is unglamorous. Watch the ratio of time spent reading model output versus producing your own. Treat review as first-class work with a real budget, not a free afterthought. Reserve the tools for where they genuinely lighten the load rather than where habit or mandate puts them.

That is neither rejecting the tools nor surrendering to them. It is just being honest about the cost, which is the only footing from which you can use them well for a long time.

References

Discuss on Twitter • View on GitHub