The honest case for agents that only suggest

The industry settled this argument by acclamation somewhere around 2024. Agents that act won, agents that suggest lost, and the remaining question was how much autonomy to grant rather than whether to grant it.

I’ve been using both for long enough to think the settlement was premature, and that the case for suggest-only is stronger than its reputation. Not on safety grounds. On output quality.

Where the value actually lands

The useful thing an agent gives you is rarely the code. It’s the second option.

When something proposes a change and you read it, one of three things happens. You take it, which saves you the typing. You reject it, which cost you fifteen seconds. Or, and this is the valuable case, you read it, notice it’s solving a slightly different problem than the one you had, and realise your problem was underspecified.

That third outcome is worth more than the first two combined and it only exists at the moment of review. An agent that writes to disk and moves on has skipped straight past it. You get the diff eventually, but you get it after nine other decisions have been stacked on top, at which point re-opening the question costs enough that you won’t.

Autonomy shifts review to the worst possible moment

There’s a timing asymmetry here that took me a while to see clearly.

Reviewing one proposed change, in context, while the problem is still live in your head, is cheap. You know what you were trying to do. You know what you rejected five minutes ago and why. The evaluation is nearly free because all the context is already loaded.

Reviewing eleven changes across six files after the fact is a completely different activity. Now you’re reconstructing intent from a diff, which is the same work as reviewing a stranger’s pull request, and it’s slow, and it’s the kind of work people do badly at four in the afternoon.

Autonomous agents don’t remove the review. They defer it, batch it, and hand it back to you at the point where you’re least equipped to do it well. That’s not a safety concern, it’s a throughput one.

What suggest-only is genuinely worse at

The honest other side, because the trade is real.

Anything mechanical and wide. Renaming a concept across forty files, applying the same transformation to every handler, migrating a call signature. There is no value in reviewing occurrence nineteen of a change you approved at occurrence one, and a suggest-only tool makes you do exactly that. This is where autonomy earns its keep and it earns it decisively.

Anything with a fast, trustworthy feedback loop. If your test suite is genuinely comprehensive and runs in ninety seconds, letting something iterate against it unsupervised is straightforwardly better than being in the middle of that loop. The tests are doing the review, and they’re better at it than you are for that specific class of error.

And exploratory throwaway work, where you want six variants of an approach and intend to bin five of them. Reviewing code you’re about to delete is a waste of a perfectly good afternoon.

The rule I’ve settled on

The question isn’t how much autonomy the tool should have. It’s whether you already know what correct looks like.

If you can state the acceptance condition precisely enough that something else could check it, let the agent run. The condition does the reviewing.

If you can’t, if “correct” is a judgment you’ll only be able to make once you see the thing, then suggestion is the right mode, because the judgment has to happen and it happens best while you still remember what you wanted.

Most interesting work is the second kind. Most work that gets demoed is the first, which is a large part of why the settlement went the way it did.

The part nobody advertises

There’s a quieter benefit to the suggest mode that doesn’t fit on a slide: you learn more.

Reading a proposed change while the problem is fresh teaches you something about the problem. Reading a completed change after the fact mostly teaches you about the change. Over a year that difference compounds into a real gap in how well you understand your own codebase, and I’ve watched it happen to people who were shipping perfectly well the whole time.

That isn’t an argument for refusing autonomy. It’s an argument for noticing what you’re buying with it, which is throughput, and what you’re paying, which is the part of the loop where you were paying attention.

More field notes on agentic coding

This piece is one entry in a running series on how AI coding tools change day-to-day engineering work. For more practical notes on agentic coding specifically, browse the full set at /blog/tag/agentic-coding/. For the wider view across every tool in the stack, the AI coding tag collects the whole archive in one place.