Agentic Fatigue Is The New Burnout
I shipped more code last year than any year of my career. I also ended every single week of it more tired than I've ever been in front of a keyboard. The two things are related, and I think the entire industry is quietly figuring out the same thing right now.
There's a name for it now: agentic fatigue. The Bloomberg piece in late February put a label on it, the Harness 2026 State of Engineering Excellence report put numbers on it, and every senior engineer I know recognized themselves in both.
The Numbers Are Brutal
From the 2026 Harness report, surveying ~3,000 engineers:
- 31% of a developer's day is now consumed by AI-related invisible work — reviewing, fixing, explaining, supervising
- 53% identify "reviewing AI code for accuracy" as the top friction source
- 52% identify "fixing subtle bugs the AI introduced"
- 48% identify "explaining AI-generated code to teammates" — including code they wrote themselves but didn't read carefully enough to defend
- 63% report spending more time debugging AI-generated code than they would have spent writing it manually
The security picture is worse. Independent analyses are converging on roughly 45% of AI-generated code containing at least one vulnerability — most commonly command injection, hardcoded secrets, and SSRF patterns. Code co-authored by generative AI shows around 2.74x the rate of major security issues compared to fully human-written code.
These aren't anti-AI numbers from a luddite think tank. They're the productivity story we're all telling ourselves, with the costs added back in.
What "Vibe Coding" Actually Costs
Karpathy's "vibe coding" phrase from early 2025 was funny because it was honest. You describe the vibe, the model writes the code, you ship it. Most of us are doing some version of this, including me, including the people who'd never admit it.
The bill comes due in three places:
1. Cognitive overhead. Every AI completion is a micro-decision: accept, reject, edit. A senior engineer used to make those decisions about their own code occasionally, when refactoring. Now they make them every few seconds. The mental energy this consumes is not free. It's just invisible on the standup.
2. Ownership erosion. When the bug ships at 3 AM, the on-call engineer reads code they didn't write, can't always defend, and isn't sure was the right approach in the first place. The team's confidence in the codebase degrades. Investigation takes longer. Fixes ship slower.
3. Skill atrophy. Junior engineers I work with in 2026 reach for an AI completion the way I reached for Stack Overflow in 2014. The difference is Stack Overflow forced you to read three answers, understand the trade-offs, and pick one. Cursor's autocomplete gives you a polished, plausible solution before you've finished formulating the question. The reasoning step is being skipped.
These costs compound. You can paper over them for a quarter. You cannot paper over them for a year.
The Double Bind
Here's the bit that ruins my mood: the cost of AI tooling creates pressure to use it more, which creates more of the cost.
A team paying $200/user/month for Claude Code, Cursor, and GPT-5 Pro feels institutional pressure to show that the spend is justified. The way you show that is shipping more code, faster. The way you ship faster is by leaning harder on the agents. The way that backfires is more debugging, more review load, more invisible work.
I've watched this play out in three of the small teams I advise. The shape is always the same:
- Tooling spend up 5-10x year-over-year
- Output velocity up 30-50% in the first six months
- Bug rate up 20-40% in months 4-9
- Senior engineer tenure drops as the most experienced people get burned out from doing all the review
- Spend stays. Velocity flattens. Bugs persist.
The companies that handle this best are the ones that admit early that AI tooling shifts work, it doesn't eliminate it. The work that gets shifted is review, judgment, and integration. Those are the parts of engineering that don't scale with token counts.
What Actually Helps
This isn't a "stop using AI" post. I use Claude Code every day. I'm using it to write this paragraph. The question is how to keep it from running your life.
Things that have worked for me, in roughly descending order of impact:
- One-AI-task-at-a-time rule. Spawning three parallel agents feels productive. It feels productive the way checking email every 90 seconds feels productive. Stop.
- Mandatory read-throughs of any agent diff above ~100 lines. Not skim. Read. If the model can't be tested or read in 10 minutes, it's not ready to merge regardless of how confident the chat output sounded.
- Pair on AI-generated code, not just on hand-written code. The expensive bugs hide in confidently wrong agent output. A second pair of eyes during the review matters more than during the writing.
- Aggressive context boundaries. I run separate agents for separate concerns. The agent doing the migration doesn't see the auth code. The agent fixing a bug doesn't get to refactor neighboring files. Scope discipline beats prompt engineering.
- Slow-down rituals. Reading the diff out loud. Drawing the data flow on paper. Pretending I have to explain it to a junior in 30 minutes. Anything that forces a pace slower than the model's output speed.
- Logging off. Yes, really. The model is on 24/7. You can't be. If your tools work faster than your brain, your day needs to end before your tools do.
The Quiet Truth
The pre-AI developer's job was writing code. The post-AI developer's job is judging code at high speed. These look the same on a hiring page. They are wildly different in the brain.
Writing code activates one mode: creative, additive, problem-solving. Reviewing code activates another: skeptical, subtractive, pattern-matching. Switching between them all day was always hard. Doing nothing but the second mode, all day, every day, against a firehose of plausible-looking output — that's a new failure mode the industry hasn't priced in yet.
We will price it in. Either through better tooling that surfaces why a model made each choice, through team rituals that protect the cognitive budget, or through a wave of senior engineers quietly resigning in the back half of 2026.
I'm betting on all three.
For now, the practical advice is the boring kind. Use the tools. Set boundaries with them. Treat anything they hand you as a suggestion from a fast junior with no context, not as a finished work product. Read the diff. Walk away from the screen when you can't.
The productivity revolution is real. The fatigue is also real. Pretending only one of them exists is what got us here.
Sources: