How much autonomy should you give your AI coding agent?

The first time an AI coding agent merged something you didn't mean to ship, you probably turned every gate back on. The second time you added gates back, you also added a rule: always review before the agent moves to the next step. Over time, "always review" is how agents stop saving time and start generating approval queues.

The instinct is right — some decisions need your eyes on them. The mistake is treating all decisions the same. Autonomy isn't binary, and treating it that way either makes the agent useless (every step gated) or risky (no gates at all). The question isn't how much to trust your agent; it's which decisions are yours to make and which ones it can handle.

The failure modes at each extreme

Full human-in-the-loop: the agent proposes, you approve each step, work proceeds. Sounds safe. In practice it means the agent runs faster than you can review, the queue builds up, and you're spending thirty minutes a day clicking "approve" on outputs you can't evaluate in thirty seconds. You've added overhead without removing risk.

Full hands-off: you describe the task, the agent ships the PR. Sounds efficient. It works until it doesn't — until the agent auto-advanced through scope clarification, decided the answer to an ambiguous design question on its own, and wrote code on top of a wrong assumption. By the time you see the output, the problem is three layers deep.

Neither extreme is wrong in every situation. They're wrong when applied uniformly, regardless of the task.

A decision framework based on blast radius

The practical question for any task is: if the agent makes a wrong call here, how much does it cost? Answer that, and the right autonomy level follows.

Gate everything when scope is uncertain or blast radius is high

New tasks in an unfamiliar codebase. Architectural changes that touch many files. Anything that modifies data models, migrations, auth, or external integrations. Security-critical paths. When the wrong turn costs real time to unwind, the gate at each stage earns its keep.

This isn't about distrust — it's about the cost of a wrong assumption compounding over a long task. The agent that confidently implements the wrong spec for three hours is more dangerous than the one that stops and asks at the edge of a decision it can't reverse.

Use selective gates for known-good workflows with a hard stop at the edges

You've run the same pattern before: a feature request turns into a design + implementation + review cycle on a codebase you know well. The agent understands the conventions. You've seen it handle this shape of task cleanly. Let it auto-advance through implementation and review. But stop it at scope — before it locks in a direction — and again before it ships, so you see the output before the PR opens.

The two gates that matter most are almost always the same ones: the scope decision at the front (what is this task, what's out of scope, what are the acceptance criteria) and the release gate at the back (did it build what you asked). Everything in between is mechanical execution you've already validated. Gate the decisions, not the steps.

Run fully hands-off on confident, bounded, reversible work

You need a unit test suite expanded for a module you've already reviewed. You want a specific refactor applied across a set of files. You're running a batch of small, scoped tasks where you've seen this exact pattern pass cleanly before and the worst outcome is a PR you close without merging.

For work that's well-understood, bounded in scope, and easy to revert, human gates introduce delay with no corresponding risk reduction. The agent that can run from task open to PR open without a single interrupt is net faster, not net riskier, when those conditions hold.

The conditions that shift the level

A few factors that should move your default setting:

• Task familiarity. Your first time asking an agent to work on a given module: gate more. After you've seen it handle the same type of task cleanly three times: gate less.
• Code area. Core business logic, payment flows, auth, and data migrations deserve more caution than new features, isolated utilities, or test coverage.
• Reversibility. If the wrong output is a PR you can close without merging, the cost of a miss is low. If the wrong output runs a database migration, it isn't.
• Agent history on this task type. If the agent has a good track record on this shape of work in your codebase, trust it. If it's been surprising you with wrong scope or unexpected side effects, add gates until you understand why.

These conditions change task-by-task. The right approach is a task-level setting, not a global one.

The review problem that persists at any autonomy level

Adjusting gates handles the approval question — when do you see the work before the agent proceeds. It doesn't handle the review quality question — when the agent does show you something, how good is that review.

The two failure modes described at the start (too much gating, too little) both assume the human review happening at the gates is meaningful. If your review at the scope gate just rubber-stamps what the agent wrote, the gate is theater. The point of putting a gate at scope is to actually read the acceptance criteria and correct them before three hours of implementation locks in the wrong answer. If the review step at the end just approves a diff you didn't read, the gate added latency without reducing risk.

Autonomy level is a scheduling decision. Review quality is a separate problem — and the harder one. The yes-man problem means agents tend to approve their own work; the stage boundaries problem means they tend to blur the line between planning and implementing. Gates give you the intervention points; what you do at those points is still on you.

where defract lands on this

defract ships three autonomy presets — Drive (approve every stage gate), Delegate (auto-advance through implementation and review, stop at scope and release), and Autopilot (end-to-end hands-off, agent runs from task open to PR without interruption). They map directly to the three levels above, and they're set per-task, not globally, because no single setting is right for every piece of work.

The mental model that guides the design is the same one above: gate the decisions, not the steps. Implementation proceeding without approval isn't risky; implementation proceeding on a wrong scope decision is. The two gates that earn their keep in every setting are scope (what is this) and release (is this what you asked for). Everything in between is the mechanical part the agent is good at. Treat it as one approach to the problem — the decision framework is more useful than the specific product.