Essay

The Quiet Exhaustion Nobody's Talking About

On AI fatigue, the burden of the last human in the loop, and why engineers are tired in a way that's hard to name.


It started as excitement. Of course it did. You ran your first prompt through Copilot or ChatGPT and something clicked — code appeared, boilerplate vanished, the blank screen stopped being terrifying. You felt ten feet tall. You were shipping faster than you ever had. Your PRs were bigger. Your standups were punchy. You were, for a brief window, a superhero.

That was the first phase. Nobody warned you about the second one.

"The tools got faster. The humans didn't."

Here's what actually happens when AI enters your workflow: the volume goes up. A lot. You're generating more code, reviewing more code, context-switching faster, closing more tickets. The surface area of your responsibility expands quietly and continuously — and nobody notices because the metrics look great. Output is up. Velocity is up. On paper, everything is fine.

But you're the one reading the generated code. You're the one catching the subtle bugs that slip through — the ones that look right but aren't, the ones you can only spot if you understand why the code was written, not just what it does. You're the last checkpoint. The only one in the loop who actually understands context, consequences, and edge cases that haven't happened yet.

That's not a small job. That's an enormous job. And it's a job that got bigger the moment AI arrived, not smaller.

The myth of the speedup

There's a story we tell about AI productivity tools: they give you time back. And in one narrow sense, they do — certain tasks that took 30 minutes now take 3. But those minutes don't go to rest. They go to more tasks. The throughput pressure scales to match the tools. You're not working less. You're working differently, at a pace that was designed for machines, not for a person with a nervous system.

"Estimated: 68% of engineers using daily AI coding tools report working longer hours than before adoption — because expectations scaled faster than capacity."

There's also a subtler cost: cognitive novelty. Every AI-generated block of code is slightly unfamiliar — it's not code you wrote, it doesn't carry your fingerprints, and your brain has to work harder to hold it in memory. Reviewing code you didn't write is always more taxing than reviewing your own. Now imagine doing that all day, every day, for months.

The loneliness of the checkpoint

Something nobody talks about: it can feel isolating. You're surrounded by productivity, but it's not human productivity. There's no pair programming moment where someone else gets it wrong and you laugh about it. There's no shared frustration, no afternoon where you and a colleague get stuck on the same bug and figure it out together, building something unspoken between you. The collaboration has changed shape. It's faster and lonelier at the same time.

And when you try to talk about being tired — actually tired, not just "I need a coffee" tired — people look at you strangely. Aren't you shipping more than ever? Isn't the AI doing half the work? Try explaining that the half the AI does isn't actually half the work.

"Being the last human in the loop is the most important job in software right now. It's also the one most likely to burn you out."

What rest even means now

Rest used to be easier to find. You'd close the laptop, go for a walk, and your brain would slowly let go of the problem. Now the problem doesn't feel finished because it's never fully yours. The code is always a little foreign. The PRs never fully close. The backlog keeps refilling faster than you can drain it because the AI is always one prompt ahead of you, generating the next task before you've recovered from the last.

Real rest — the kind that actually restores you — requires a kind of completeness. A sense that the thing is done, or at least paused in a way you control. That's harder to find now. The pipeline doesn't pause. It just keeps generating.

The identity problem

Here's the part that doesn't show up in any survey: AI fatigue is, at its core, an identity crisis wearing productivity's clothes.

Engineering identity — for most of us who chose this path — was built on a specific kind of mastery. The ability to sit with a hard problem. To hold a complex system in your head. To feel the elegant solution emerge after hours, sometimes days, of struggle. That struggle wasn't just how you got the answer. It was how you became the kind of person who could get answers like that.

AI short-circuits that process. And while it makes you faster, it quietly hollows out the experience that built your confidence in the first place.

Talk to engineers who've been deep in AI-assisted workflows for a year or more. Many of them describe a creeping uncertainty — a feeling that they're no longer sure what they actually know versus what they've learned to retrieve. The muscle of sitting with ambiguity, of tolerating not-knowing while you work through a problem, starts to atrophy. The bench gets shorter. The panic arrives sooner when the AI isn't there.

"I started Googling things I used to just know. Not complex things. Basic things. And that scared me more than any sprint deadline ever had."

The culture doesn't help. In most engineering orgs right now, speed is the only currency. Pull request counts. Tickets closed. Features shipped. There's no metric for "depth of understanding" or "quality of the mental model." So the things that take time — reading, thinking, building intuition — become invisible and therefore deprioritized. And you learn, slowly, to deprioritize them yourself.

This is how the identity erosion happens: not in one dramatic moment, but in a thousand small choices to skip the understanding and just ship the thing.

The antidote isn't to reject AI. It's to develop a clearer, more conscious relationship with what you're outsourcing and what you're protecting. Your judgment. Your systems thinking. Your ability to ask the right questions — which matters more than ever now that the answers come cheaply. These are the things that make you an engineer in the most important sense. Guard them.

The invisible toll on junior engineers

If you're a senior engineer reading this, what I've described so far may resonate as gradual erosion — uncomfortable but survivable, because you have deep reserves to draw down. You've felt the satisfaction of building something hard from scratch. You have reference points. You can recognize when the AI is wrong because you've seen the right way before.

Junior engineers don't have that. And they're being asked to grow up in an environment that's taking away the very experiences that create it.

The classic path to engineering mastery ran through something we don't talk about enough: productive failure. Spending three hours on a bug that turned out to be a missing semicolon. Implementing a data structure from scratch to understand why the standard library version was better. Getting a PR review back covered in comments and having to sit with the uncomfortable feeling of not knowing enough — then knowing more afterward. That loop of attempt, fail, understand, retry was the curriculum. The bugs were the lessons.

"If you let AI handle all your failures, you don't get the education that comes with surviving them."

Many junior engineers today are building workflows where that loop is bypassed. The AI catches the errors. The AI suggests the fix. The PR goes through with minimal friction. They're shipping. They look productive. And they're quietly accumulating a kind of technical debt in their own mental models — debt that won't come due until the AI isn't available, or is wrong in a way they can't detect, or the problem is novel enough that the AI's training data offers no footing.

This isn't the junior engineers' fault. They're doing what the environment rewards. But it means that the engineering organizations of 2030 may be staffed at senior levels by people who have the titles but not the depth — and that will matter exactly when it matters most, in the crises and edge cases where human judgment is the only thing standing between a working system and a catastrophic one.

If you're a junior engineer reading this: deliberately build in struggle. Pick problems where AI is not the first tool you reach for. Write code by hand sometimes. Read other people's code — not AI-generated code, but human code, written by engineers who were solving real problems and made interesting choices about how. That's where the education lives.

Finding your way back

None of this is a call to reject AI. That ship has sailed, and the tools are genuinely useful. But there's a difference between using a tool and being used by one — and a lot of engineers right now are on the wrong side of that line without quite realizing it.

Finding your way back starts with noticing. Noticing when you reach for the AI out of reflex rather than genuine need. Noticing when you accept output you don't fully understand because understanding it would slow you down. Noticing when you've gone three hours without a single thought that was fully your own. These are the moments that, accumulated, constitute AI fatigue — and they're also the moments where you can make a different choice.

Recovery isn't dramatic. It looks like: one small problem today that you solve without assistance. Fifteen minutes of reading something dense and technical that requires your full attention. A conversation with a colleague that isn't about output — that's about why you both got into this in the first place. A journal entry about what you're actually thinking, in your own words, for no one but yourself.

"You don't need to leave the industry. You need to find the places in it that still feel like yours."

The goal is not to become a Luddite in a world that runs on AI. The goal is to use these extraordinary tools deliberately — to be the author who uses the typewriter, not the secretary who maintains it. To stay, in the fullest sense, in the loop.

You are not a process. You are not a pipeline. You are not a productivity metric. You're an engineer — which means you're someone who learned to hold hard problems in your mind long enough to understand them. That skill is not obsolete. It's more valuable now than it's ever been. The machines are fast. They need someone who can tell them when they're wrong.

That's you. Don't forget that.

So what do you do, in this moment, right now? Maybe you close this tab and go for a walk. Maybe you open your journal and write down what this essay made you feel. Maybe you spend the next hour on a problem that you solve without any help at all, just to remember that you still can.

This place was built for that. Use it.

Continue reading

Frequently Asked Questions

Common questions about AI fatigue in software engineering.

AI fatigue in software engineers is a specific form of cognitive and emotional exhaustion that develops when engineers rely heavily on AI coding tools. It manifests as difficulty concentrating without AI assistance, loss of confidence in unaided problem-solving, disconnection from the craft of coding, and a persistent low-grade anxiety about one's own technical relevance. It differs from general burnout in that it's tied specifically to the adoption of AI tools and the cognitive labor of being "the last human in the loop" — the person responsible for reviewing, validating, and owning AI-generated work.
AI tools increase output velocity, but expectations and workloads scale to match — so engineers often work more, not less. Reviewing AI-generated code is cognitively more expensive than reviewing code you wrote yourself, because your brain must reverse-engineer someone else's reasoning rather than recall your own. Context-switching increases. The volume of decisions increases. And the emotional labor of being the sole accountability checkpoint for AI output creates persistent background stress that doesn't lift when you close your laptop.
Engineering identity has historically been built around problem-solving mastery — the ability to sit with a hard problem, struggle through it, and emerge with a working solution you fully understand. AI tools short-circuit this process. Many engineers report feeling like "prompt managers" rather than engineers, and struggle to point to work that feels authentically theirs. Over time this creates a quiet identity crisis: if the AI can do the technical parts, what makes you an engineer?
Junior engineers face a different but serious risk. Senior engineers have deep reserves of hard-won knowledge to draw on; they can recognize when AI output is wrong because they've seen the right way before. Junior engineers are being shortchanged on the formative struggle that builds that reservoir — learning to ship without deeply learning to build. The result is a profound fragility: reaching senior-equivalent titles without the mental models to back it up.
Recovery involves both immediate and structural changes. Immediately: deliberately take on small problems without AI assistance to rebuild confidence; create time for deep, uninterrupted work; keep a private engineering journal to reconnect with your own thinking. Structurally: advocate for realistic productivity expectations that account for cognitive overhead; protect time for reading, learning, and reflection; seek peer connection with other engineers who feel the same. The goal isn't to reject AI tools — it's to use them intentionally rather than compulsively.
Traditional developer burnout typically comes from overwork, poor management, or accumulated technical debt. AI fatigue adds several unique dimensions: the cognitive load of reviewing AI-generated code, the identity disruption of feeling like a "reviewer" rather than a creator, anxiety about professional relevance, and social isolation from a workflow that's faster but lonelier. AI fatigue can develop even when work hours are normal — it's about the quality of cognitive engagement, not just the quantity.