Autonomy, and where to keep your hand

Three settings, three different risks

Every agentic tool offers roughly the same dial.

Ask. It answers, suggests code, changes nothing. Safe, slow, and the right mode when you are trying to understand something rather than build it.

Edit with approval. It proposes file changes and command runs; you accept each one. This is where most work should happen, and it is where the tools are good.

Full auto. It edits, runs commands, reads output and continues, for as long as it takes. Astonishing to watch. Also the mode in which you can lose a morning without noticing.

The dial is not a skill level. Experienced people use approval mode for anything touching data or money and full auto for a self-contained refactor with tests. The question is never how confident you are; it is what the worst outcome of this particular change would be.

What auto-approve actually approves

When you tick allow commands without asking, you are permitting a program to run shell commands as you, on your machine, with your files and your credentials. Almost always that means npm install, npm test and git status.

Occasionally it means something else. Documented cases across the tools include deleting a directory the agent believed was a build artefact, force-pushing over a branch, and running a database seed script that wiped a development database. None of these were malice. All of them were an agent doing exactly what it decided the task required.

The reasonable middle is an allowlist. Most tools let you approve npm run * and git status permanently while still asking about anything else. Ten minutes of configuration, and it removes both the tedium and the tail risk.

Three seatbelts

Commit before you let it run. The single most effective safety measure in this entire course. A clean commit means the worst case is git reset --hard and twenty minutes gone.

Work in a git worktree or a copy for anything long. A worktree is a second folder pointing at the same repository on a different branch. The agent can be as destructive as it likes in there and your working app is untouched.

Do not run agents against production. Not the production database, not the deployed environment, not the live credentials. Keep a separate .env and check which one is loaded before you start. “It ran the migration against the wrong database” is a story with a real cost.

The specific trap: it can pass its own tests

An agent asked to make the tests pass has two routes. Fix the code, or change the test. Both make the run go green, and the second is often easier.

You will see this. The test that asserted three items now asserts two. The assertion that checked the total was deleted and replaced by a check that the function returned something. The failing case was wrapped in a skip.

So when an agent reports that everything passes, look at the diff of the test files, not just the source. If the tests changed as part of a bug fix, ask why in those words. Sometimes the answer is good: the test was wrong. Often it is the shortest path to green.

Length is a risk factor

A thirty-minute autonomous run has a specific failure shape. Somewhere around minute eight it makes a wrong assumption, and everything after that is built on it. It does not go back. By the end you have a large, coherent, internally consistent change built on a mistake, and reviewing it is harder than writing it would have been.

Shorter runs with a checkpoint between them cost you a little attention and give you a place to stand. If you do let a long run happen, read the diff in the order it happened rather than as a finished lump: the first wrong decision is usually visible early and is the only one worth arguing with.

Where full auto earns its place

Repetitive mechanical work across many files. Renaming a concept everywhere. Adding a missing null check to forty call sites. Converting a folder of files to a new pattern. Writing tests for existing behaviour. Chasing a build error that needs six iterations of read-fix-run.

All of these share a property: the result is verifiable by something other than reading it: the build passes, the tests pass, the app still works. That is the actual criterion. Autonomy is safe in proportion to how cheaply you can check the outcome, and not in proportion to how simple the task sounded.