Stop approval fatigue by treating it like Cal Newport's attention residue: classify agent actions into reversible, risky, and destructive, auto-approve only the first, batch the second, hard-stop the third. Anthropic's own data shows users approve 93% of prompts anyway, so the fatigue is the real risk.
The first time I left an AI coding agent running while I made coffee, I came back to forty-seven pending approval prompts. By the thirty-eighth one I was clicking "yes" without reading it. That moment — the click without reading — is the actual problem. It looks like efficiency. It is the opposite. It is what Anthropic's own engineering team measured when they shipped Claude Code's auto-mode in March 2026: users were already approving 93% of permission prompts, which means the prompts had stopped functioning as a safety check and had become a button to press.
The viral Hacker News submission in late May 2026 — a sixty-second browser game called "Continue? Y/N" about AI agent permission fatigue — captured what 159 commenters were already feeling. The game is funny because it is true: the more an agent asks, the less you read, until you are an unpaid rubber stamp for your own tool. That is not safety. That is the worst of both worlds — slow enough to break your flow, careless enough to actually approve something you should not have.
The framing that helped me most comes from Cal Newport's Deep Work, specifically the idea of attention residue. Every time your focus snaps from the work to a yes/no decision and back, a slice of your cognitive context stays stuck on the interrupting task. Newport's research shows the residue lingers for minutes, not seconds. Multiply that by forty-seven prompts and you have shipped a feature in twice the time it would have taken without the agent, while feeling busier. The agent did not save deep work. It fragmented it.
What I actually use now, after testing this across Claude Code, Cursor, the OpenAI Agents SDK and a hand-rolled setup, is a three-bucket classifier I run before any session. Bucket one is reversible actions — reading files, listing directories, running tests in an isolated sandbox, drafting text that I will review later. These I auto-approve. The cost of a wrong call is roughly zero. Bucket two is risky but recoverable — installing dependencies, writing to project files inside the repo, pushing to a branch nobody else is on, calling a paid API under a small spend cap. These I batch. The agent collects a few of them and I approve them in groups of five with a quick read, not individually. Bucket three is destructive or expensive — deleting files, force-pushing, touching production, paying anything over a threshold, sending email or messages to real people. These get a hard stop and a single, slow, manual confirmation. Always.
The trick is that the agent itself does not get to decide which bucket an action is in. That classification lives in a config file I own, written once, edited rarely. Claude Code's auto-mode is the closest implementation of this I have seen in a shipped product — it ran the numbers and found that the 93% approval rate could be safely automated for the low-risk slice while still pausing on the dangerous calls, and the classifier they trained for this is exactly the right shape. Approval fatigue, as one developer put it on Hacker News, is an agent security bug, not a user problem.
The deeper coaching point — and this is where the builder side and the executive coach side of me start to overlap — is that the human in the loop has to actually be in the loop. If you are approving 93% of prompts, you are not supervising the agent. You are giving it the illusion of supervision while it does what it was going to do anyway. Naval Ravikant's observation that the modern edge belongs to people who can sit with hard questions instead of outsourcing them applies here in an unexpected way: the prompts that matter, the bucket-three ones, deserve real thought. The bucket-one ones deserve none of your attention. Mixing the two is what destroys your judgement on both.
Concrete setup, if you want to copy mine: a written permissions config per project, ten lines at most, listing what the agent may do without asking. A maximum step count per session so it cannot loop into oblivion. A spend cap on the API key, low enough that an honest mistake is annoying, not catastrophic. A separate, isolated workspace for the agent — never the same shell I work in. And one rule I will not negotiate on: I never approve a prompt I did not read. If I am too tired to read, the session ends. The agent waits. Deep work is not what happens when AI is running. It is what happens when I am still capable of saying no to what AI suggests, and that capability erodes fast if every yes is free.
Related: How to Find Your Passion · Best Self-Improvement Books · How to Make Better Decisions · Why Exploration Is Important for Success