The agent picks OpenAI’s API to transcribe some audio. You don’t want that — you have Whisper running on your own cluster, and you’d rather not ship audio to a third party. So you type “no, don’t use OpenAI.” The agent apologizes, agrees, and reaches for… AssemblyAI. Still wrong. You type “no” again. It tries Deepgram. You are now three turns deep and the agent is walking a random path through the space of speech-to-text vendors, because every turn you have told it where not to go and never once told it where to go.
This is the most common way I waste turns with a coding agent, and it took me an embarrassing number of sessions to see the shape of it.
”Not that” is an enormous space
A rejection carries one bit of information: the last thing was wrong. That is genuinely useful — but it is also almost all you’ve given the agent. Everything that is “not the rejected thing” is still on the table, and for most decisions that set is huge. There are a dozen transcription vendors. There are twenty ways to do auth. There are infinite refactors that are “not the one you just did.”
When you say only “no,” you are asking the agent to guess again from a barely-narrowed space. It will guess confidently, because that is what these models do, and it will frequently guess in a direction you like even less than the first one. You have spent a turn and bought yourself a fresh problem.
The fix is one clause long:
A rejection that names the alternative re-steers in a single turn. A rejection without one buys another guess.
Here is what that looks like in my own transcripts, again and again:
- “Don’t use OpenAI. Use the Whisper instance running on the cluster.”
- “No need for an API lookup — checking the profile picture is a free signal, use that.”
- “Don’t use middleware for auth. Have the page itself ask for the password.”
None of those is longer than the bare “no” would have been by more than a sentence. Each one collapses the search space to a single point. The agent does not have to guess what I meant, because I told it.
Why the asymmetry is brutal at scale
With a single interactive session — a pet — a content-free rejection is merely annoying. You catch the second wrong guess, you sigh, you finally say the thing you should have said the first time. The cost is a couple of turns and a little of your patience.
Run the same habit across a fleet and the cost stops being linear. A vague correction is information you didn’t write down, and the input is the plan. When a cattle worker misreads the task, it doesn’t pause to ask — it runs to completion in some “not what you wanted” direction, fails validation, and the task goes back on the queue for the next worker to misread differently. A rejection you’d have typed interactively never even reaches them. The only thing that reaches a stateless worker is what you committed to the plan, the bead, the standing rule. So the discipline you build interactively — name the alternative, don’t just veto — is the same discipline that makes a written task unambiguous enough to hand to a worker you’ll never talk to.
This is why I think of it as one practice with two surfaces. Interactively, “don’t X, do Y” saves you a turn. In a plan, “don’t X, do Y” saves you a failed run multiplied by however many workers hit the ambiguity before you noticed.
The tell: when you reach for “no,” you know the answer
Here is the part that makes this actionable. Almost every time I catch myself typing a bare “no,” I already know what I want instead. The right answer is right there — I just didn’t type it, because rejecting felt faster than specifying. It isn’t. The half-second I saved by typing “no, don’t do that” I pay back with interest on the next turn when the agent guesses again.
So the rule I hold myself to now is mechanical: if I’m about to reject something, I am not allowed to send the message until it contains the alternative. If I genuinely don’t know the alternative yet, that’s a different and more honest message — “stop, I need to think about the right approach here” — and it should not masquerade as a correction. A correction implies I know the target. If I know the target, I should say it.
There’s a softer version of the same failure that’s worth naming: the rejection that’s technically a redirect but points nowhere useful. “No, do it properly.” “That’s not what I meant.” “Be more careful.” These feel like instructions and contain none. “Properly” is not a destination. If the agent could infer “properly,” it would have gone there the first time.
What it costs
Almost nothing, which is exactly why it’s hard. The whole tax is a moment of thinking before you hit enter instead of after the agent guesses wrong. You have to convert the vague dissatisfaction you feel — “ugh, not that” — into the specific thing you’d prefer, in the same breath. The feeling arrives before the specification; the work is refusing to send the feeling on its own.
The one real cost: sometimes you’ll discover, in the act of trying to name the alternative, that you don’t actually know what you want. That is not the practice failing. That is the practice doing its most valuable job — surfacing, for the price of one unsent message, that the problem was underspecified in your own head before it was ever underspecified to the agent.
The question I now ask
Before I send a correction — interactive or written into a plan — I ask:
If the agent does the literal opposite of what it just did, will that be right?
If yes, a plain “no” is fine; the space really is binary. That case is rare. Far more often the answer is “no, the opposite is also wrong,” which means the space is wide, which means a bare rejection is about to cost me another guess — and the alternative I’m failing to type is already sitting in my head, waiting to be sent.
— Jed
Background: The plan is the prompt — why the information you don’t write down is the information that costs you, multiplied by every worker that hits the gap. And Pet agents vs. cattle agents — the model that makes the asymmetry visible.