What is an autonomous coding agent?

An autonomous coding agent is one that continues working without a human approving each step: it plans, edits, runs tests, reacts to failures and iterates until it judges the task complete. Autonomy in practice is a spectrum rather than a property. Almost every real deployment sits somewhere between full supervision and full independence, with approval still required for a specific set of irreversible actions.

How autonomous can a coding agent safely be?

As autonomous as your reversibility allows. If every action the agent can take is isolated and revertible, a wrong run costs you a revert and long leashes are affordable. If it can touch production data, external services or anything with a side effect you cannot undo, autonomy has to stop at that boundary regardless of how capable the agent is. The limit is set by consequences, not by competence.

What goes wrong when nobody is watching an agent?

Three things dominate. It stops making progress while still appearing healthy, which no process-level health check detects. It completes the wrong task confidently, having interpreted an ambiguous instruction plausibly but incorrectly. Or it succeeds and then keeps going, improving adjacent things nobody asked about or reviewed. The first is an operations problem, the second a scoping problem, the third an instruction problem, and all three need different fixes.

How do you monitor an autonomous agent?

With an end-to-end probe, not a health check. Confirming that a process exists tells you almost nothing, because the expensive failure mode keeps the process alive. What works is periodically asking the agent to perform a small verifiable action and confirming it happened. Anything less can be satisfied by a completely stuck agent.

Should an autonomous agent be allowed to merge its own code?

Only where the entire path is reversible and covered by tests you trust, and even then a soak period before merge catches more than it costs. We use one on automated content changes: a pull request must be a set age before automerge picks it up, which turns "nobody reviewed this" into "nobody objected to this for a day". That is a weaker guarantee than review and a much stronger one than nothing.

Is Devin-style full autonomy realistic yet?

Realistic for bounded, well-tested, low-consequence work, and consistently oversold for everything else. The gap is rarely the model. It is that most codebases lack the verification an agent needs to know it succeeded, so the agent substitutes its own judgement about whether it is finished. Improving the test suite moves that boundary further than switching agents does.

Autonomous Coding Agents: What Autonomy Actually Costs

Autonomy is a spectrum, and it is worth being precise about where you are

"Autonomous" is used to mean everything from "runs three tool calls before checking in" to "opens pull requests unattended overnight". The distinctions matter because each step costs something specific.

Suggests. The human executes. No autonomy, no supervision cost.
Acts with approval. Each action is confirmed. The cost is your attention, paid continuously.
Acts within a boundary. Free inside a defined scope, approval required to cross it. This is where most productive work happens, and defining the boundary is the actual engineering.
Runs unattended, reports at the end. Requires detection of silent failure, because nobody is looking.
Runs continuously and self-recovers. Requires everything above plus a recovery policy that does not destroy work in progress.

Almost every honest deployment is level three with a level-four aspiration. Vendors mostly sell level five.

What only breaks when nobody is watching

Supervised agents fail in ways you notice immediately because you are there. Unattended agents fail in ways designed, apparently, to be missed.

Alive and silent

The single most expensive failure mode we have dealt with. The process is running, memory and CPU look normal, the logs are quiet, and no work is happening. Every process-level health check passes. The only thing that distinguishes this from an agent thinking hard is asking it to do something and checking that it did.

A specific variant is worth naming because it defeats the obvious fix: a supporting subprocess that never started. Restarting does not help, because the restart re-fails the same way, and you get a loop of a supervisor restarting an agent that will never come up. The cure was reconnecting the subsystem rather than restarting the agent, and the general lesson is that an escalation ladder whose rungs are all "try again" is one rung long.

Confidently complete

The agent finishes, reports success and is wrong. Unattended, this is worse than a crash, because downstream steps trust it. The mitigation is not better instructions; it is making success externally checkable, so that "done" is something a test asserts rather than something the agent believes.

Recovery that eats the work

The restart that clears the outage also discards an hour of correct reasoning. This is the tension at the centre of unattended operation: react too early and you destroy good work, too late and you burn the window. Our own thresholds landed at a nudge first and a restart only after several minutes of genuine silence, because we kept killing agents that were fine.

What makes autonomy affordable

Three properties, in order of importance:

Reversibility. If everything can be undone, a bad run is cheap and long leashes are rational. This is the whole argument, and everything else is detail.
Isolation. An isolated checkout means a wrong run cannot take anything else with it, and it is what makes running several agents at once possible rather than merely parallel.
External verification. A test the agent runs, and a probe someone else runs. The agent's own report is evidence of intent, not of outcome.

Where those three do not hold, the answer is not more supervision. It is less autonomy, at that specific boundary, permanently. Anything touching authentication, payments, data deletion or schema belongs on the approval side of the line no matter how good the agent gets, because the cost of being wrong does not shrink as capability grows.

A soak period is underrated

If an autonomous agent produces changes faster than humans can review them, the honest options are to slow it down or to accept unreviewed merges. There is a third that costs little: make automated changes wait. A pull request that must be a set age before it can merge converts "nobody reviewed this" into "nobody objected for a day", and in practice that catches a meaningful share of obviously-wrong work at close to zero cost. It is weaker than review. It is much stronger than a rubber stamp.

Autonomy is a bill, and supervision is how you pay it

Key Takeaways