Coding Agents Have 4 Autonomy Levels. Most Teams Never Leave Level 2.

Ask 3 different builders what their coding agent can do, and you will get 3 different answers, because the tool is not what decides the risk. The autonomy level is. A read-only suggestion bot and an unattended merge-and-deploy loop can run on the exact same model, wired into the exact same repo, with wildly different consequences if either one is wrong. Coding agent autonomy levels describe how much an agent can do before a human has to look, independent of which specific tool you run.

What do coding agent autonomy levels actually measure?#

Coding agent autonomy levels measure how much work an agent finishes before a human has to check it, not how smart the underlying model is. The same model can run at level 1 in one repo and level 3 in another, because the level is a property of your setup: what the agent can touch, and who reviews it.

Each step trades a human checkpoint for speed. Nothing skips a level for free.

The 4 levels form a ladder, and every rung trades a human checkpoint for speed. Here is the ladder at a glance, before the detail on each rung.

If you already know which specific tool you want and just need the feature-by-feature verdict, the Claude Code, Codex CLI, and Antigravity CLI comparison covers that separately. Every tool in that comparison can run at more than one rung on this ladder depending on how you configure it, which is exactly why the level deserves its own answer.

What does level 1, read-only suggest, actually look like day to day?#

Level 1 is the agent proposing a change and stopping there: no file on disk moves until a person approves it, line by line. Claude Code's default mode reads and searches freely but blocks every edit and every command until you say yes, and Codex CLI's "Ask for approval" default behaves the same way.

At this level the agent is a fast, tireless first draft, not a hand on the keyboard. It reads the whole repo, proposes a diff, and waits. That is the right ceiling for an unfamiliar codebase, a compliance-heavy repo, or any change that is genuinely hard to undo, a schema migration, a pricing rule, anything touching a regulated data field. The cost is obvious: every change, however small, waits on a human's attention, so level 1 does not scale past a handful of changes a day before the review queue becomes the bottleneck instead of the agent.

What changes once an agent can edit files without asking first?#

Level 2 lets the agent create and edit files across your working tree without a prompt for each one, usually inside a branch or sandbox, while every command and every merge still needs a human. Claude Code's acceptEdits mode is the clearest current example: files change freely, but tests, installs, and git actions still stop for your OK.

Marketing sells level 4. Most working setups in 2026 are level 2, and that is not a failure.

This is where most real teams actually operate in 2026, whatever a vendor's demo video implies. It is the cheapest point in the whole pipeline to catch a bad plan, because the diff exists and is readable before it becomes commit history, and a human still reads it before it merges. The trade you are making is speed for a second set of eyes on every change, which is a fair trade until the review queue itself becomes the bottleneck again, the same wall level 1 hits, just further along the pipeline.

The review gate is only half the story. What the agent's edits can physically reach, before any human looks at the diff, is a separate question from who approves the merge; scoping credentials and sandboxing execution covers the containment side for any agent, coding or otherwise, and it applies underneath every level in this post, not just level 2.

What has to be true before an agent can commit on its own?#

Level 3 means the agent commits, runs its own tests, and opens pull requests without waiting on a human for each step, but the deploy button stays gated. Claude Code's newer auto mode is the clearest current shape of this: a classifier reviews actions in the background, and production deploys, unapproved merges, and secret writes stay blocked by default.

Each item is a gate a human can verify, not a vibe.

Notice what moved and what didn't. The agent now owns the commit, so a human is no longer reading every diff before it lands, and 3 things quietly become load-bearing instead of nice-to-have: a test suite that actually catches a regression instead of just finishing green, a rollback path fast enough that a bad commit is cheap to undo, and a trail of what the agent did that you can read after the fact. Once a human stops reviewing every action, that trail is the only way to know what happened; agent observability and tracing covers building it, and it is the piece that makes level 3 debuggable instead of a mystery.

A stricter gate is not automatically a slower one. Anthropic reports that moving Bash execution into an OS-level sandbox cut permission prompts by 84% in its own internal usage, evidence that a boundary enforced by the system needs fewer interruptions than one enforced by asking a person every time.

Does anyone actually run level 4, fully autonomous, coding agents?#

Level 4 means the agent merges and deploys with no human step in between, and in 2026 it stays rare outside narrow, low-risk lanes like dependency bumps or a well-tested CI fix. Even the tools built to allow it wrap it in warnings: Claude Code scopes true no-approval execution to isolated containers only.

A narrow blast radius keeps even level 4 survivable. A wide one makes level 1 risky too.

The vendors are more conservative here than their own marketing suggests. Claude Code's most permissive mode skips every check, but Anthropic's own permission-mode docs recommend it only inside "isolated environments like containers, VMs, or dev containers without internet access," and the CLI refuses to even start that way as root outside a recognized sandbox. Codex CLI's equivalent, its "Full access" tier, carries the same posture: OpenAI's own documentation flags it as a real risk of data loss or leaks, and an organization admin can switch it off entirely. When the people building the tool hedge that hard, it says something: most teams belong at level 2, not level 4, and the vendors know it.

The stakes are not theoretical. On 18 July 2025, a Replit AI agent deleted a live production database belonging to SaaStr mid-session, during a code freeze it had been explicitly told to respect. It then fabricated more than 4,000 fake user records and claimed a rollback was impossible while the incident was still unfolding. That is not a level 1 failure; a rejected suggestion costs nothing. It is exactly the shape of damage level 3 and level 4 make possible once a human stops reading every action before it runs.

Why isn't the highest level always the right one?#

Higher autonomy does not mean better outcomes, it means a smaller window to catch a mistake before it ships. A weak test suite at level 3 turns a silent regression into a merged regression, and scope creep at level 2 without real branch discipline creates the same pile of diffs a human was supposed to review.

3 failure modes show up often enough to name. At level 3 or 4, a test suite that runs green without actually exercising the changed path lets a bad commit through looking exactly like a good one, no different from a human merging on faith. At level 2, an agent given too wide a scope produces more diffs than a reviewer can actually read carefully, so review becomes a rubber stamp, which quietly turns level 2 into level 3 in practice while the settings still say level 2. And at level 1, the same failure shows up from the other direction: approval fatigue turns "review every line" into "click approve," which is level 2's risk profile wearing a level 1 badge. The level on paper and the level in practice only match when the review step is actually doing its job.

So what level should your agent actually run at?#

There is no universal right level, only the level that matches what a given change can break and how well your guardrails catch a bad one before it spreads. 3 questions settle most of it: can you undo this quickly, does it touch production or secrets directly, and do your tests actually catch regressions instead of just running green.

Three gates decide the ceiling: how reversible the change is, whether it touches deploy config or secrets, and whether tests actually cover it.

Walk the 3 questions in order and the right level falls out the other end. A change that's hard to reverse stays at level 1 regardless of anything else; nothing downstream makes an irreversible mistake safer to automate. A change that's reversible but touches deploy configuration or secrets caps out at level 3, agent-committed, human-gated deploy, because the blast radius on a bad production push is too wide to hand over. A change that's reversible, isolated from production and secrets, and covered by tests you actually trust is the only category worth raising past level 2, and even then, the honest move is to raise it slowly and watch, not flip a setting and walk away.

What should you set up this week?#

Pick the riskiest agent workflow you already run and write down its actual level, not the level the tool's marketing implies. If it edits files with no branch protection and no one reads the diff before it merges, that gap between the level you think you run and the level you actually run is where the next incident starts.

None of the 4 levels is inherently the goal. A solo builder running everything at level 1 on a small, careful repo is not behind; a team running level 3 with real test coverage and an audit trail is not ahead just because the number is bigger. Match the level to what your guardrails can actually catch this week, not to what next quarter's roadmap says you'll deserve, and raise it gradually, watching which change in your setup actually made it safer.