Agent in IDE, autonomy set by a written rule

An agent working inside your IDE is qualitatively different from chat or autocomplete. Instead of suggesting code for you to accept, the agent acts: it reads files, makes edits across multiple files, runs commands, reads the output, and iterates. For two years the question was whether you clicked the setting that removed the confirmation step between actions - "YOLO mode", auto-approve in Claude Code, auto-run in Cursor's Composer. As of August 2026 that framing is gone. What removes the confirmation step is no longer a toggle you flip per prompt; it is a permission policy you write down. Claude Code's auto mode became the default for Pro, Max and Team accounts on August 14 (announced August 7), with a classifier judging individual actions and a circuit breaker that halts the session after 3 consecutive or 20 total blocks. This is not a return to YOLO. Two declarative rule layers run before the classifier is ever consulted: permissions.deny blocks outright, and neither the classifier nor your stated intent can override it; permissions.ask forces a prompt, and an explicit ask rule is treated as your stated intent, so the classifier cannot auto-approve past it. Auto mode remains opt-in on Claude Enterprise, the Claude API, Bedrock, Google Cloud and Microsoft Foundry, existing user-set defaults move only through a one-time prompt, and org-managed defaults do not move at all.

Claude Code, Cursor, GitHub Copilot Workspace, Windsurf, and Aider all support agentic operation. Cursor 3 (launched April 2, 2026) represents the most radical expression of this idea: an agent-first IDE redesign where the primary workflow is directing fleets of agents rather than editing code with agent assistance. Windsurf now supports 5 parallel agents (since February 2026), enabling concurrent agentic work streams within a single IDE session. The difference between a policy-governed agent and an agent that stops at every action is significant: without per-action confirmation prompts, the agent completes a feature implementation or refactoring task in a single run rather than requiring dozens of keystrokes to approve each individual step.

At L2 (Delegated), this is the team's first experience with AI acting rather than merely suggesting. The agent can implement a complete feature, refactor a module, or fix a class of bugs across an entire codebase - tasks that previously required hours of focused developer time. This is the point where the maturity matrix starts to deliver real throughput gains rather than just convenience.

The "Delegated" level distinction from L1 (Assisted) is that at L2 the autonomy has a stated shape: a CLAUDE.md or .cursorrules file that tells the agent what conventions to follow, a permissions.deny and permissions.ask ruleset that says where the agent may not go, and a development environment where mistakes can be easily reverted (version control, clean branches). Running an agent loose with no project context and no committed ruleset is L1 behaviour dressed up as L2. The L2 signal is not whether the agent runs unattended - it is whether the boundary it runs inside is written down, reviewed, and in version control.

A written autonomy boundary is the unlock that turns AI from a typing assistant into a productivity multiplier:

• Eliminates approval friction - a task that would require 50 confirmation clicks runs to completion with one prompt
• Enables larger task scope - agents can tackle "implement this entire feature" rather than just "write this function"
• Demonstrates AI's true capability - developers who've only used autocomplete are often shocked by what an agent can accomplish in a single run
• Creates the feedback loop for better context - when the agent makes wrong decisions, it reveals exactly what context was missing, driving improvement of CLAUDE.md and of the ruleset itself
• Sets the foundation for L4 governed agents - the pattern of "state the limits, agent runs, review the result" is the same at L2 and L4; the difference is sandboxing, evidence, and scale
• The human click was never the control - developers approve 97% of permission prompts. In Anthropic's 1,053-person study humans caught 13.6% of dangerous commands where the classifier caught 89%. A rule you reviewed once beats a click you make fifty times a day
• Agent-first IDEs made the toggle obsolete - Cursor 3's redesign proves the industry is converging: the entire IDE is built around agent orchestration, not code editing with agent assistance. When a developer is directing several agents at once there is nobody left to watch each action, so the governance moves from the toggle to the ruleset - which is why the L2 question is now whether your deny and ask rules are written down and reviewed, not whether a human is clicking

The key risk of a fast-moving agent is that mistakes happen faster. An agent that misunderstands a requirement can make dozens of incorrect edits before you notice. This is why L2 autonomy is combined with: working on a clean branch, having tests to catch errors, and reviewing the diff before merging. The goal isn't blind trust - it's informed delegation, bounded by a rule you wrote, with a review gate at the end.

1. Start on a clean branch - Always run agents on a separate git branch. This makes reviewing the diff easy and reverting trivial if the agent goes wrong.
2. Write a CLAUDE.md first - Before turning autonomy up, ensure the agent has project context. An agent without context will make confident, wrong decisions. Even a basic 50-line CLAUDE.md dramatically improves agent behavior.
3. Write the permission rules before you turn autonomy up - Autonomy is a config file now, not a keystroke. In Claude Code, put your non-negotiables in permissions.deny (secrets, deploy scripts, force-push, anything that reaches production) and your judgement calls in permissions.ask. Both layers run ahead of the classifier and cannot be argued past, so this file is the actual control surface: commit it and review it like any other production config. In Cursor: configure auto-run in Composer settings (Run Mode stays classifier-gated). In Aider: use the --yes flag. For code you did not write, Claude Code 2.1.248 (August 27) added --restricted / CLAUDE_CODE_RESTRICTED=1, which removes command and code execution and WebFetch, keeps file tools inside the working directory, refuses bypassPermissions and ignores settings files entirely.
4. Start with low-risk tasks - Point the agent first at tasks like "write tests for this function," "update all import statements to use the new module path," or "add type annotations to this file." These are bounded, reversible, and easy to verify.
5. Review the diff, not the code - After an agent run, don't try to read every line. Use git diff to review what changed. Look for: did it change files it shouldn't have? Did it follow the patterns in your rules file? Do the tests pass?
6. Iterate on failures - When the agent makes a wrong decision, that failure is information. Add what it got wrong to your CLAUDE.md, or add a deny rule if it went somewhere it should never go, and run again. Three or four iterations usually converge on correct, consistent agent behavior.

Running agents without version control hygiene. An agent making dozens of changes without checkpoints means a single misunderstood requirement can corrupt significant code. Always work on a clean branch with a recent commit as your fallback. git stash and git reset --hard are your escape hatches.

Treating the classifier as the control. Auto mode ships with a risk classifier, and the classifier is genuinely good at the job the human click was doing badly. But it is the last line, not the policy. The control is the deny and ask ruleset that runs ahead of it, and that ruleset is worth exactly what its review process is worth. Check it into the repository, diff it in code review, and re-read it after every incident. A team that switched auto mode on and never wrote a deny rule has not adopted a policy - it has adopted a vendor default.

Not reading the full diff before merging. The whole point of delegated autonomy is that the agent runs to completion without your supervision. This shifts your review responsibility from "review each step" to "review the final result." Skipping the diff review eliminates the safety net entirely. At L2, 100% review of agent-produced diffs is non-negotiable.

Giving underspecified tasks. "Refactor the auth module" will produce a confident, comprehensive refactoring that may completely change patterns you intended to keep. An agent running to completion amplifies both good and bad task specifications. The more specific your task description and acceptance criteria, the better the result.

Conflating agent output with production-ready code. Agent-generated code can pass all your tests and still have subtle issues: security vulnerabilities, performance problems, or logic errors that tests don't catch. The agent produces a first draft that requires human review - it's not a replacement for code review.