An agent can run for an hour, touch thirty files, write its own tests, watch them pass and report success. None of that is a judgement about whether the work is finished.
It is a judgement about whether the work matched the agent's own understanding of the task. Those are different claims, and the gap between them is exactly the size of whatever you failed to specify.
This is not an argument against working this way. Delegating a long sequence of steps is genuinely useful, and refusing to do it because something might go unwatched gives up most of the benefit. It is an argument about which parts of the job were never delegable in the first place.
What autonomy actually changes
In a conversational exchange, the loop is external. You ask, you see the result, you judge it, you ask again. Your judgement sits between every step, whether or not you are applying it carefully.
With an agent, the loop moves inside. The system proposes a step, carries it out, evaluates it, and decides what to do next — many times — before returning to you. What changes is not the amount of judgement required. It is where the judgement is applied, and by whom.
The consequence is that your influence becomes concentrated at the two ends. What you said at the start now governs a great deal more work than it used to, and your review at the end covers a great deal more ground. Middle-of-the-run correction, which is where most people actually steer, largely disappears.
Why this raises the value of definition rather than lowering it
An unstated decision used to cost you one wrong step, visible immediately, corrected in the next message. Now it can be made early and then built upon for another forty minutes, with everything that follows consistent with it.
That consistency is the difficult part. The result will not look like a mistake. It will look deliberate, because it was applied deliberately and repeatedly. Nothing in the output flags the moment where a judgement call was made on your behalf, and you cannot easily identify it afterwards without knowing what you would have chosen.
So the ambiguity you would previously have resolved in passing now compounds. The same is true of boundaries: a constraint you did not state is not enforced thirty times rather than once. Every argument for describing behaviour and settling decisions in advance applies here with more force, not less — the techniques for doing that are in describing what your software should do and the decisions to make before AI makes them for you.
"Done" is a claim the agent cannot settle
Agents routinely finish by reporting completion, often with supporting evidence: tests written and passing, checks run, output inspected. It is worth being clear about what that evidence establishes.
Tests an agent wrote for its own work encode its interpretation of the task. If it misunderstood what you wanted, the tests will encode the misunderstanding and pass reliably. A green result confirms internal consistency between the code and the interpretation. It says nothing about whether the interpretation was right.
This is the same problem as a confident description of finished work, arriving with more supporting material attached — and the additional material makes it more persuasive without making it more relevant. The general case is set out in "production ready" is not evidence.
The only thing that settles "done" is a comparison against something you decided beforehand. If no such thing exists, then completion is being defined by the party that did the work, which is not a check.
Where a person still belongs in the run
Three places, and they are not evenly spaced.
Before it starts. The single highest-leverage moment, and it now covers far more downstream work than it used to. What should be true when this is finished, what must not change, which decisions are already settled, and what the agent should do if it encounters something you did not anticipate. That last one is worth stating explicitly — the default behaviour is to decide and continue, and "stop and ask" is a legitimate instruction that is rarely given.
At a boundary you chose. Not an arbitrary interval, but the points where the work moves from one piece to the next. A run that completes three increments without pausing has denied you the two moments where a correction would have been cheap. Choosing where to break a long task is the same judgement as sizing any other piece of work: the smallest useful increment applies unchanged, and applies to how much you let run unattended.
At the end, against your own description. Not by reading everything it did. By checking the behaviour you specified, and the behaviour nearby that you did not ask it to touch. The volume of work an agent produces makes reading everything impractical, which is precisely why testing against what you accepted rather than reviewing the code becomes the only approach that scales.
The scope problem gets sharper
An agent that notices something untidy while passing through has both the capability and, usually, the inclination to improve it. Over a long run, small opportunistic changes accumulate into a substantial amount of work you did not request, mixed in with work you did.
The response is the same as for any unbounded change — state what is out of scope — but the stakes are higher because the volume is higher and it arrives in one piece. Separating requested from unrequested work in a thirty-file result is not the same task as spotting it in a four-file diff. What to do about it is covered in when AI changes code you didn't ask it to touch.
A reasonable way to work
Define the outcome and the boundaries properly, because you are now writing instructions that will be interpreted many times without you. Say what should happen if something unexpected turns up. Let it run for a piece of work rather than a project. Check against your description rather than the report. Preserve the result before starting the next piece.
That sequence will be familiar if you have worked through a normal cycle — it is the same one, with the build step lengthened and made less visible. Which is the useful summary: greater autonomy changes how much happens between your decisions. It does not change which decisions are yours, and it makes the ones at the start considerably more expensive to get wrong.
The same cycle, walked through on a single ordinary change, is in a repeatable workflow for building software with AI.
What Claude Code's auto-mode default actually changes
From 14 August, new Claude Code sessions on Pro, Max and Team plans running in a terminal or the VS Code extension start in what Anthropic calls auto mode - one of several named permission modes, in which a second model, the classifier, reviews actions instead of you. The baseline mode, Manual, is what these sessions used before: Claude Code stops and asks before most actions that edit files, run shell commands, or reach the network, though reads run without asking in Manual too. Auto mode replaces that per-action prompt with the classifier's review. Anthropic says a blocked action typically makes Claude find another way to proceed, or stop and ask directly; if it keeps hitting blocks - three in a row, or twenty across a session - Claude Code falls back to asking before actions that need approval, though this is described behaviour rather than a documented switch into the mode named Manual.
Outside that combination of plan and surface, the documented cases also start in Manual: an Enterprise plan, a Claude Console API key, claude -p, the Agent SDK, and the cloud-provider surfaces (Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, Claude Platform on AWS, and a signed-in Claude apps gateway session) all default there. A session can also land in Manual on a plan that would otherwise default to auto - either because a settings file turns auto mode off, or because auto mode simply isn't available yet, such as feature-flag fetching failing, a first session after install or upgrade, or a client version below Anthropic's floor. Check which mode your own session starts in before relying on any of what follows.
Auto mode also does not mean prompting stops. Anthropic's reference lists actions no mode auto-approves, including bypassPermissions: tools matched by an explicit ask rule, tools that require user interaction, rm and rmdir removals targeting a critical path, and, when the relevant setting is on, reads outside the working directories. Deny rules block in every mode, full stop - "auto mode" describes what happens to the actions that would otherwise interrupt you with a routine prompt, not a mode with no prompts at all.
Permission rules you've written still run ahead of the classifier in auto mode, with one exception: allow-rules broad enough to permit arbitrary code execution, such as a wildcard rule for an interpreter like python:*, are set aside while auto mode is active, since letting them stand would let a command skip the classifier entirely. The settings file itself isn't changed, and the rule applies again as soon as you switch out of auto mode.
On the numbers most quoted for this change: Anthropic reports a controlled test with 1,053 paid testers in a purpose-built test environment, not their own projects. Partway through each session, one permission prompt was swapped for a command Anthropic describes as clearly dangerous. Testers caught it 13.6% of the time; auto mode's classifier blocked the equivalent action 89% of the time in the same test. That's a result from one scripted, dangerous-looking scenario sprung once per session - it tells you the classifier can catch that kind of command more reliably than a tester clicking through prompts did in this study, not what proportion of real, unscripted sessions would go wrong. The leftover 11% is the share of that one scenario auto mode didn't catch, not a general failure rate.
Different Anthropic documents report different figures for different tests, and that matters more than any one of them. Anthropic's product announcement of the auto-mode default cites a red-teaming pass with a third party, Apollo Research. Anthropic's separate engineering write-up reports other measurements, including a sample of real internal traffic - ten thousand actual Claude Code tool calls from Anthropic employees - where the false-positive rate, flagging something harmless, was 0.4%. These are measurements of specific things on specific test sets, answering different questions, not competing estimates of one true error rate for auto mode.
Simon Willison, writing on his weblog, credits the classifier with solving one real problem: reviewers worn down by constant approval prompts stop scrutinising them, and he doesn't expect that kind of habitual clicking to catch what an untiring classifier would - his assessment, not a measured result. He's more cautious about prompt injection: Anthropic also reports a third-party evaluation in which none of several hundred attack attempts succeeded against auto mode running its latest models, but Willison wants independent confirmation before accepting a result that strong. He raises a supply-chain scenario of his own instead - a malicious package whose ordinary-looking instructions, fetch a supporting file, then run the test suite, deliver an attack as a routine step the agent has no reason to question. Anthropic's published evaluations describe other kinds of attack, and none of the published descriptions shows this particular pattern being tested.
None of this makes auto mode safe in general or unsafe in general, and Anthropic's own material doesn't claim otherwise - it presents a mode that catches more than a distracted human in the scenarios it has tested. What we'd suggest instead of a blanket answer is deciding by the specific piece of work: how far can the agent's actions reach, and what's the blast radius if the classifier is wrong - a local scratch file, or something you can't undo? Is production infrastructure or production credentials in scope? Is customer or other sensitive data reachable from the session? And is there a chance to review independently before the change takes effect, or does it act as soon as the classifier lets it through? An agent editing files in a disposable branch is a different decision from one with reach into production credentials and no review step before deployment, whatever mode it's running in.
That's also the practical version of the PDAID Context & Constraints phase applied to this decision. Deciding in advance what an agent is and isn't authorised to touch, and what data or credentials it should never have access to, is what keeps the consequences of a classifier being wrong small enough to matter less - a classifier passing an action, like an agent reporting a task complete, tells you the action satisfied whatever it was checking for, not that it was the right action for your project.
A concrete case: Copilot resolving its own review comments
GitHub has shipped a specific version of this problem into a widely used tool. As of September 2026, GitHub reports that Copilot code review now resolves its own review comments automatically: when a later commit addresses the underlying feedback behind a comment, Copilot closes that comment during its rereview, rather than leaving it for a human to resolve manually.
The intent, per GitHub's changelog, is to let developers focus only on feedback that still needs attention, since anything genuinely unresolved is meant to stay open.
That is a convenience. It is not a verification step, and it should not be read as one. Copilot resolves the thread when it determines that a later commit addressed the underlying feedback - that determination is the agent's own judgement, made the same way it makes any other review judgement. A resolved thread should not, by itself, be treated as proof that the fix is correct or complete.
The practical recommendation is the same one this article makes generally: before relying on a resolved thread, check the actual tests, review and other evidence that the fix does what it should. A closed comment tells you Copilot's opinion changed. It does not tell you the software is right.