Most coding agent failures happen at the approval gate. Teams pick a default execution mode (plan or auto-accept) and apply it uniformly. Plan mode wastes time on trivial edits. Auto-accept ships silent regressions when context drifts. The real control surface is treating mode selection as a per-task decision, not a global preference.
Claude Code, Cursor, Windsurf, and Grok Build all expose this pattern: agents can either propose changes for review (plan mode) or write directly to disk (auto-accept). The distinction maps cleanly to financial authorization workflows. Plan mode is dual authorization. Auto-accept is a pre-approved transaction limit. Both have failure modes. Both require observability.
This article examines execution mode selection as a safety primitive. It covers plan boundaries, state persistence between approval and execution, rollback strategies when auto-accept breaks builds, and the signals that distinguish safe automation from human-required review.
Plan Mode Mechanics
Plan mode prevents file writes until a human approves the batch. The agent reads the codebase, generates a diff, and presents it as a proposal. No mutations occur until the operator confirms.
What constitutes a plan unit:
- A single logical task (add logging, refactor function, fix bug)
- All file changes required to complete that task
- Dependencies between changes (if file A imports file B, both edits land together)
The boundary is task-scoped, not file-scoped. An agent might propose changes to six files in one plan if they all serve a single feature. The operator reviews the entire batch or rejects it.
State persistence between proposal and execution:
- The agent stores the diff in memory or a temporary branch
- File hashes at proposal time get compared to current state before applying changes
- If the codebase drifts (another developer commits), the plan becomes stale
- The agent must regenerate or abort
This is where most plan mode implementations fail. If the agent doesn’t detect drift, it applies a diff to the wrong base and creates merge conflicts. The correct pattern is to lock the plan to a specific commit SHA and reject execution if HEAD moves.
Auto-Accept Mechanics
Auto-accept grants write authority from the start. The agent mutates files as it generates changes. No approval gate exists. The operator sees results after the fact.
When auto-accept is safe:
- Mechanical transformations (rename variable, update import paths)
- Isolated file changes with no cross-module dependencies
- Codebases with strong test coverage and CI gates
- Tasks where rollback cost is low (formatting, documentation)
When auto-accept is dangerous:
- Exploratory refactors where the agent might misunderstand intent
- Changes to shared modules or API contracts
- Tasks that touch configuration, deployment scripts, or infrastructure
- Any scenario where a bad change blocks the team
The failure mode is silent corruption. The agent writes invalid code, the developer doesn’t notice until CI fails, and the team spends time debugging agent output instead of shipping features.
Rollback Strategies
Auto-accept requires a rollback plan. If the agent breaks the build, the operator needs a fast path to undo.
Common rollback implementations:
| Strategy | Mechanism | Latency | Failure Mode |
|---|---|---|---|
| Git revert | Agent commits each change, operator reverts the commit | Seconds | Loses work if multiple changes landed in one commit |
| Shadow branch | Agent writes to a feature branch, operator merges or deletes | Minutes | Requires branch hygiene, can accumulate stale branches |
| Checkpoint snapshots | Agent saves filesystem state before each mutation, operator restores | Seconds | High disk usage, doesn’t integrate with version control |
| Undo buffer | Agent tracks inverse operations (delete line X, restore line X), operator replays | Milliseconds | Breaks on non-invertible changes (file deletion, lossy transforms) |
The best pattern is shadow branches with automatic cleanup. The agent creates a branch per task, writes changes, runs tests, and either merges (if tests pass) or deletes (if tests fail). The operator never sees broken state in the main branch.
Observability Signals for Mode Selection
The decision to use plan mode or auto-accept should depend on measurable risk factors. Agents that learn from failure patterns can automate mode selection.
Signals that indicate plan mode:
- High token count in the agent’s reasoning trace (complex task, high uncertainty)
- Changes span multiple modules or cross architectural boundaries
- No test coverage for affected code paths
- Task involves configuration, secrets, or deployment logic
- Historical failure rate for similar tasks exceeds threshold (e.g., 10%)
Signals that indicate auto-accept:
- Low token count (simple, mechanical task)
- Changes isolated to a single file or module
- Test coverage above 80% for affected code
- Task matches a known safe pattern (formatting, linting, documentation)
- Historical success rate above 95%
The agent can track these signals per task type and build a decision model. After 100 formatting tasks with zero failures, auto-accept becomes the default. After three failed refactors in a shared module, plan mode becomes mandatory.
Hybrid Workflow Pattern
The most effective teams use both modes in a single session. The agent starts in plan mode for exploration, switches to auto-accept for mechanical steps, and returns to plan mode for risky changes.
Example workflow:
- Developer asks agent to add a new API endpoint
- Agent uses plan mode to propose the route definition, handler signature, and test structure
- Developer reviews and approves
- Agent switches to auto-accept to generate boilerplate (imports, error handling, logging)
- Agent returns to plan mode to propose database schema changes
- Developer reviews and approves
- Agent switches to auto-accept to update documentation
The mode switch happens based on task phase. Exploration and design decisions require human review. Mechanical implementation steps run autonomously.
State Management Across Mode Switches
Switching modes mid-task introduces coordination risk. The agent must track which changes landed in which mode and prevent inconsistent state.
Coordination requirements:
- Plan mode changes must not depend on uncommitted auto-accept changes
- Auto-accept changes must not invalidate pending plans
- The agent must serialize mode switches (no concurrent plan and auto-accept operations)
The correct implementation is a state machine:
class AgentExecutionMode:
def __init__(self):
self.mode = "plan" # Start in safe mode
self.pending_plan = None
self.auto_accept_log = []
def propose_plan(self, changes):
if self.mode != "plan":
raise InvalidStateError("Cannot propose while in auto-accept")
self.pending_plan = changes
return changes
def execute_plan(self):
if not self.pending_plan:
raise InvalidStateError("No pending plan")
apply_changes(self.pending_plan)
self.pending_plan = None
def switch_to_auto_accept(self):
if self.pending_plan:
raise InvalidStateError("Cannot switch with pending plan")
self.mode = "auto_accept"
def auto_accept_change(self, change):
if self.mode != "auto_accept":
raise InvalidStateError("Not in auto-accept mode")
apply_changes([change])
self.auto_accept_log.append(change)
def switch_to_plan(self):
self.mode = "plan"The state machine prevents the agent from proposing a plan while uncommitted auto-accept changes exist. It also prevents auto-accept writes while a plan is pending review.
Security Boundaries
Execution mode selection is a security control. Auto-accept bypasses human review, so it must respect the same boundaries as any automated write operation.
Security requirements:
- Auto-accept must not modify files outside the project directory
- Auto-accept must not execute shell commands without explicit permission
- Auto-accept must not write to configuration files that affect other developers (CI config, Docker files, deployment scripts)
- Auto-accept must not commit changes without the operator’s git identity
The enforcement layer is a file access policy. The agent checks every write operation against a whitelist. Auto-accept writes to source files are allowed. Auto-accept writes to .github/workflows are blocked.
Failure Mode Analysis
Both modes have distinct failure modes. Understanding them helps teams choose the right default.
Plan mode failures:
- High latency (every change requires review)
- Developer fatigue (too many trivial reviews)
- Stale plans (codebase drifts between proposal and execution)
- Coordination overhead (multiple developers reviewing overlapping plans)
Auto-accept failures:
- Silent regressions (agent writes broken code, tests don’t catch it)
- Merge conflicts (agent writes to files other developers are editing)
- Scope creep (agent makes unrelated changes while fixing a bug)
- Lost context (developer doesn’t understand what the agent changed)
The mitigation strategy is to use plan mode as the default and whitelist specific task types for auto-accept. The whitelist grows as the agent proves reliability.
Production Deployment Shape
Coding agents in production need execution mode configuration at multiple levels: organization, repository, and task.
Configuration hierarchy:
- Organization policy: “Auto-accept disabled for all repositories”
- Repository policy: “Auto-accept enabled for formatting and linting”
- Task policy: “This specific refactor requires plan mode”
The agent checks all three levels before executing. The most restrictive policy wins. If the organization disables auto-accept, no repository or task can override it.
Technical Verdict
Use plan mode as the default for all coding agents. It prevents silent failures and keeps developers in the loop. Switch to auto-accept only for task types with proven reliability: formatting, linting, documentation updates, and mechanical refactors.
Avoid auto-accept for:
- Exploratory refactors
- Changes to shared modules or API contracts
- Configuration, deployment, or infrastructure changes
- Any task where the cost of a bad change exceeds the cost of review
Use plan mode for:
- First-time tasks (no historical success data)
- High-risk changes (database schema, authentication, authorization)
- Cross-module refactors
- Tasks that touch more than five files
The best teams build observability into mode selection. Track success rates per task type. Automate the decision when confidence is high. Require human review when uncertainty is high.
Execution mode selection is not a preference. It is a safety primitive. Treat it like transaction limits in financial systems: start conservative, expand boundaries as trust grows, and always maintain rollback capability.