I never let a coding agent run on autopilot

I have never turned on auto-accept. Not on a small project, not on a throwaway one, not at two in the morning when it would have saved me an hour. Every change an agent proposes gets read before it lands.

This is usually taken as caution, or as not trusting the tools. It is neither. It is that I have watched several people build on autopilot and I have not yet seen one of those projects arrive anywhere.

#The three ways it goes wrong

What is striking is that none of the failures are the ones people expect. The code compiles. It usually runs. The problems are one level up from correctness.

It overbuilds

Left to complete a task without interruption, an agent will produce the thorough version. Abstractions for cases that will not occur, configuration for choices nobody will make, a layer of indirection in front of something used once. Each individual decision is defensible and the accumulation is a codebase far larger than the problem, which one person then has to hold in their head.

It substitutes

You ask for one thing and receive a neighbouring thing, implemented confidently. Not a hallucination in the dramatic sense — a plausible adjacent solution, delivered with the same tone as the correct one. On autopilot this is accepted and built upon, and by the time it surfaces there are four things standing on top of it.

It does not ask

This is the expensive one. Given an ambiguous instruction, an agent resolves the ambiguity rather than raising it, because finishing is what it is for. It picks an interpretation and completes the work — and the work is unusable, not because it is bad but because it answers a question you did not ask.

#Who is the mind and who is the hands

The way I work is a straightforward division of labour: I am the mind. The agent executes. Something like seventy to eighty per cent of what I use it for is execution — I know what I want, I describe it precisely, it builds it, I check it.

The remaining share is different. There I am genuinely using it to think: what have I not considered, what breaks under load, what is a better structure than the one I have. That is real and it is valuable, and it is still directed. I decide when to open that conversation and I decide what comes out of it.

What being the mind means in practice is that the specification lives with me and not in the prompt history. Before I start I know what the product does, which features belong in it and which do not, what the interface should feel like, how someone signs in and out, which service gets called at which moment, and what a person is actually trying to accomplish when they arrive. None of that is delegated. It is the part that is mine.

The tool is not the thing that decides whether the product is any good. It never was.

#Make it ask you questions

The single most useful habit I have is not a prompt template. It is that I let the agent do a pass and then require it to come back with questions before continuing.

This directly attacks the third failure. An agent that has been told to surface its ambiguities instead of resolving them will produce a list, and that list is consistently the most valuable output of the session — because every item on it is a place where it was about to guess, and roughly a third of the guesses would have been wrong.

1. Give it the context and the goal, with the constraints stated.
2. Let it work.
3. Before accepting anything, ask what it had to assume and what it would do differently with more information.
4. Answer those. Then review the diff.

That loop is slower than autopilot on any single task and considerably faster across a project, because the expensive failure is never the fifteen minutes to fix a bug. It is the three days spent on top of a wrong assumption.

#Reading everything is how I learned anything

I read the diffs, the summaries the agent writes, the commit messages, and what happens on deploy. Some of that is control — it is a codebase I did not type, and reading is the only way I have an accurate picture of what is in it.

But most of it is learning, and this is the part I would defend to anyone who thinks people like me are not really engaged with what we ship. I did not come from a technical background. Nearly everything I understand about building software I learned by reading a change carefully enough to decide whether to accept it — which is a slower teacher than a tutorial and a considerably better one, because every example is from a system I care about and each decision has a consequence I will personally meet.

Autopilot removes exactly that. Two years of accepted diffs you never read leaves you with a large application and no more understanding than you started with, and the first serious problem is unrecoverable because you have no map.

#When I would not bother

It would be dishonest to pretend the setting has no legitimate use. For something genuinely throwaway — a script that runs once, an experiment that will be deleted, a prototype whose only job is to answer a question — the review has nothing to protect and I would let it run.

The line is whether anybody is going to depend on it. The moment something will be used by another person, hold data, be deployed anywhere public or be maintained by me in three months, the review is the cheapest part of the whole project.

Which tool it is makes very little difference to any of this. I work across several of them and the discipline is identical in each. The setting that matters is the same one in all of them, and it is the one I leave off.