Review the Command Before It Runs

An assistant suggests a cleanup command. It looks right. There is a variable in it, and on your machine that variable is empty, so the path it expands to is not the directory you meant. If a human reads it first, this is a five second catch. If the tool runs it the moment it thinks of it, it is a restore from backup.

That gap is the entire design question for anything that proposes shell commands. The tool that writes the command should not be the tool that executes it unreviewed.

The failure mode is confidence, not malice

Nobody is worried the model is plotting. The realistic failures are duller and more common than that.

• A correct command in the wrong place: The right migration against the right database name, on the cluster you forgot you were pointed at.
• Shell expansion doing its job: Globs, an unquoted variable, a trailing slash. The command is valid. It just means something different on your machine than in the example it was patterned on.
• Stale context: The suggestion is based on how your project looked two steps ago, before the thing you just changed.
• Plausible invention: A flag that does not exist, or worse, one that exists and does something else.
• Irreversibility: Most commands are fine to get wrong. A few delete things, rotate credentials, or send something to customers. The cost is not evenly distributed, and the model does not feel the difference.

Notice that a human reviewer catches most of these instantly, not because they are smarter, but because they hold context the model does not have: which shell this is, which server, what you were actually trying to do.

Approval and review are not the same thing

Plenty of tools have a confirmation step, and plenty of those confirmations are worthless. If a dialog appears dozens of times an hour and says yes by default, you are not reviewing anything. You are clicking. The step exists so the vendor can say it exists.

Real review has properties a confirmation prompt usually lacks. The full command is visible, not a summary of it. It appears where you would have typed it, in the same font and the same context as the rest of your session, so it reads as a command rather than as a notification. You can edit it before it runs. And the thing that finally executes it is an action only you can take.

What a good review step looks like

This is the rule Anvil is built on. Commands the model suggests become buttons that type the command at your prompt and stop there. You still press enter. Destructive commands are called out as destructive in the same breath as being suggested, so the flag arrives with the suggestion rather than after it.

One keystroke is not much friction. What it buys is a terminal you can leave open on a production box, which is a different category of tool from one you have to close before you connect to anything that matters. The cost is fixed and small. The thing it protects against is rare and large.

It also matters that the suggestion is editable rather than take it or leave it. Most of the time a proposed command is nearly right, and the useful move is to change one flag and run it, not to reject it and start the conversation over. A review step that offers only yes or no quietly trains you to say yes.

Two supporting details matter more than they look. The context comes out of the live screen buffer at the moment you ask, not from an accumulating log, so what the model reasons about is what you are actually looking at, escape sequences already resolved. And the shell reports where each command starts and ends over OSC 133, the same convention editors and other modern terminals use, so "explain the last error" means that specific command, its output, and the code it exited with, rather than a guess against the last two hundred lines of scrollback. A review step is only as good as the accuracy of what is being reviewed.

Where the line actually sits

Requiring a human on every command is not a principle you can apply everywhere. Nobody reviews each line of a deployment script. So the line is not "never automate," it is drawn by two questions.

1. Is it reversible? Reading a file, listing processes, checking a status: run it. The downside of being wrong is a wasted second. Deleting, overwriting, publishing, sending, rotating a key: those deserve a person, every time.
2. Is it repeatable and already reviewed? A script that has been read once, committed, and run a thousand times is safer than a fresh command that has been read zero times. Automation is fine when the review already happened, upstream, on the thing being run.

What does not fit either test is the common case for an assistant: a novel command, composed just now, against a live system, that nobody has read. That is precisely where the keystroke belongs.

The part that is on you

A review step only works if reviews actually happen. If you are pressing enter on suggestions without reading them, the design has given you a safety property you are choosing not to use, and you have quietly moved to the more dangerous tool without deciding to.

Two habits keep it honest. Read the command out loud in your head, specifically the paths and the flags, which is where the damage lives. And when you cannot be bothered to read it, that is the signal to slow down, not to click faster. Fatigue is information about the tool, not just about you.

The takeaway

An assistant that runs commands on its own is trading a rare catastrophic outcome for a steady stream of small conveniences, and it makes that trade on your behalf without asking. We think the keystroke is worth keeping. Not because models are unreliable in some general sense, but because the review is cheap, the failure is not, and you are the only party in the loop who knows what you were actually trying to do.

If you are weighing how much autonomy to give tooling inside your own systems, we are happy to think it through with you.