Agentic Coding is Burning Me Out

A short May 2026 post by 0xsid arguing that agentic coding compresses the natural rhythm of software work into a stream of variable-reward decisions, and that the binding constraint on output is no longer typing speed but the operator's mental endurance.

cognitive-debt is the comprehension-side companion: 0xsid describes what's depleted, the MIT study describes what's eroded. Osmani's prescription (form a hypothesis first, ask for explanation before code, re-derive by hand) is one practical answer to both at once.

Pacing collapse

Trad coding had recovery built in. Wiring things together, writing the obvious glue, restructuring an import — these were the catch-your-breath stretches between hard problems. They also did real work: they built up the mental model that the next hard decision would draw on. Doing tasks manually means context accumulates as a side effect of execution.

Agents remove the glue work and leave only the decisions. The code "just appears in front of you" — 0xsid uses the Memento tattoos analogy, where every session starts cold because you didn't live through the construction. The model holds the context the human didn't get to build.

The gacha loop

The post calls the agent supervision pattern "a string of variable psychological rewards followed by cognitive fatigue" — explicitly comparing it to gacha or slot-machine mechanics. Sometimes the agent one-shots a hard task; sometimes it produces something subtly broken. The unpredictable payoff schedule is the same one casinos engineer for engagement.

This sits next to ai-sycophancy-loop and the "cyber psychosis" framing — both describe systems that feel productive while quietly degrading judgment. 0xsid's contribution is naming the mechanism: the variable-reward schedule on top of operational uncertainty.

Decision fatigue as the ceiling

The arithmetic is the post's punchline. Normal trad coding sustains "eight to ten productive hours." Agent supervision burns through the operator in "four or five extremely intense hours." Friends are already burning out, and they don't say it out loud — 0xsid claims to see it in how they approach projects.

The mechanism is constant context switching plus a much higher decision-per-hour rate. Architectural and big-picture calls made while overseeing a "cracked junior dev" turn out to be harder than executing standard programming tasks yourself, because every supervisory pause breaks momentum. The cognitive load doesn't compose with parallelism — spinning up more agents does not give you more attention.

Ceding operational control

A second observation: the volume of generated code now exceeds what any single human can debug or reason through. So you sign off on raw code "just to keep up with the output that's expected these days." This is a shift in the contract — you're not approving the code, you're trusting the tool's raw power and hoping for the best. Most of the time it works, until an edge case falls apart and leaves you in limbo: stuck using the tool for the productivity boost, unable to trust it unsupervised.

This is the same complaint Cantrill makes from the supply side in peril-of-laziness-lost (LLMs lack the human time-constraint that drives simplicity), and the same one Bram Cohen makes about refusing to read code at all. 0xsid is making it from the demand side: even with intent to review, the throughput exceeds the human's capacity to do it well.

The verifier-of-the-verifier problem

The obvious response — "build better review and verification loops" — runs into a regress. Who builds the verifier? If the LLM does, you have to trust a verification system built by something whose primary output you don't trust. And then you have to verify that the verification system targets the right parts of the system and tests them correctly. 0xsid doesn't claim to know the answer.

This is a softer version of the byzantine-fault problem applied to tooling: a faulty validator is worse than no validator because it produces false confidence. It's also the same trust-recursion that makes AI supply-chain-security hard.

Where this fits

The wiki's LLM-skeptic thread now has three angles on the same observation:

• peril-of-laziness-lost — philosophical: LLMs lack human time-pressure, so they don't simplify
• no-silver-bullet-llms — theoretical: code generation isn't the bottleneck; essential difficulty is
• This post — operational: even when LLMs work, the supervisor is the bottleneck, and the bottleneck has a human ceiling

building-syntaqlite-ai is the lived case study — Maganti's two phases describe exactly the gacha loop and the recovery (re-establishing human control over architecture). ai-assisted-workflow is one proposed mitigation — front-load the thinking so each agent invocation is a small, verifiable step rather than a slot pull.

The "average is all you need" thesis is the optimistic mirror: if you accept that the floor rises and the scarce resource shifts to filtering, then 0xsid's complaint is a description of the scarce resource — not a flaw in the system, but a hard constraint on how much filtering one human can do per day.

Lars Faye makes the structural version of the verifier-of-the-verifier point: the supervisor role depends on skills that supervised work erodes. The cluster around that circularity has its own page at skill-atrophy-supervision-paradox.