Claude Code users approve 93% of requests — oversight is becoming a formality

The agent is into its second hour of editing a project and regularly asks permission to run another command. You read the first requests carefully, then start recognizing familiar wording and click the button almost automatically. At some point, deleting a remote branch or migrating the production database appears among the routine operations. Approval has been granted, but a substantive review may never have happened.

An article on Habr about oversight fatigue cites an Anthropic figure: Claude Code users approve 93% of confirmation requests. That percentage alone does not prove inattention: most actions may indeed be safe. But it raises a useful product question: what kind of mistake can your interface stop if the normal way to use it is to agree and move on?

Why the button stops protecting you

Someone carrying out a task gradually builds an understanding of what is happening. Someone reviewing an agent has to reconstruct that understanding from someone else’s actions: which files were read, why a tool was chosen, what has already changed, and what consequences the next command will have. A single confirmation dialog rarely holds all that context.

Imagine an agent tasked with removing obsolete functionality. It has deleted the code, updated the tests, and now proposes cleaning up related branches. Assessing that last step takes more than seeing a valid Git command. You need to know which branches are still in use, whether colleagues have unfinished work, and whether cleaning up the remote repository was part of the original task. The command’s syntax settles almost nothing here.

The problem of supervising automation predates LLMs by decades. The original article draws on aviation and self-driving cars: prolonged monitoring weakens attention, while rare interventions require skills that are hard to maintain without practice. These examples help explain the mechanism. They do not justify transferring accident rates or the effectiveness of specific measures from one industry to another.

What to change in the product and the process

The first step is to define the limits of the agent’s authority before it starts. If the agent needs to prepare a fix, access to release publishing, secrets, and the production database requires separate justification. The fewer consequences it can trigger on its own, the less you have to rely on a person’s attentiveness at the end of a long session.

The second step is to organize reviews around a completed result. For a code change, this could mean a set of edits accompanied by test results, a list of affected components, and an explicit account of actions outside the local copy. This lets the reviewer see how the steps connect. Batch approval must not quietly include a dangerous operation, however: a migration or data deletion should be presented separately, identifying the specific target and expected consequences.

The third step is to verify the result using the technical tools available. Does the promised file exist? Does it open? Does its content match the task? Do the checks pass? These questions are especially important when a tool has failed but the agent has confidently reported success anyway. A polished summary does not prove the work was done.

An automated action classifier can also help. In Habr’s account, Anthropic reports that its classifier missed 17% of 52 examined cases in which an agent took excessive initiative. This is a small, specialized sample, not a universal risk estimate. For a team, the implication is straightforward: an additional model still lets mistakes through, so access restrictions and checks on consequences remain important.

Who should review the agent

Assigning oversight to the least experienced employee looks like a saving until it becomes clear that evaluation requires an understanding of the work itself. To spot a faulty migration, you need to understand the data. To detect a fabricated result, you need to know what a real one looks like.

That gives tasks performed without an assistant practical value: they help employees develop and retain the ability to review work. It is also useful to examine actual failures and corrections: which mistakes a person stopped, what information they lacked, and which requests could be removed from the stream of confirmations.

For product managers, the takeaway is concrete: the approval rate alone says little about the quality of oversight. For developers, every permission request should include enough context to make a decision. For founders, the time required for qualified review needs to be included in the cost of the agent’s work. Otherwise, faster execution can easily be mistaken for faster delivery of a reliable result.