Every one-line prompt ships with a spec you didn't write
Something I wish I'd understood earlier about working with coding agents: there is no such thing as dispatching without a spec. There's only choosing who writes it.
When you send an agent a one-liner like "fix the login timeout", the unstated parts don't stay undecided. The model fills every blank with defaults from its training data — the average project, the average convention, the average meaning of that sentence across every repo it has seen. Where your codebase matches the average, those fill-ins are invisible because they happen to be right. Where it doesn't, you get a diff that answers a question you never asked.
An intern who hits ambiguity tends to come ask. An agent mostly picks, and rarely flags the pick — a constraint that never made it into the context might as well not exist.
So we stopped asking "spec or no spec" and started asking two questions before every dispatch. How long would a wrong guess stay invisible? And how far is this task from the average project the model trained on? Fast feedback plus mainstream shape: one line, go. Slow feedback plus weird shape: write the contract, and budget the writing as part of the build.
The surprise was where our dispatches settled. We expected the extremes — one-liners for speed, full documents for safety. Instead almost everything landed in the middle: a one-liner plus one forbidden move ("don't touch the schema"), or three acceptance lines defining done from the outside. One negative constraint deletes the most expensive class of wrong guess, and it costs five words.
Replies
This matches something I noticed with test-writing prompts specifically. My codebase's testing convention is unusual so every one-liner defaults to the standard pattern and I only catch it in review, never before.
Genuinely useful reframe. I always treated "spec or no spec" as a binary decision made once at the start of a project, not something to ask per dispatch. Doing it per task instead of per project sounds like it would catch a lot more of the weird edge cases.
The negative constraint is powerful, but I’d pair it with one observable acceptance check. “Don’t touch the schema” prevents a costly move; “the timeout reproducer passes and existing session behavior is unchanged” tells the agent what success looks like from outside the implementation. I’d also make uncertainty explicit: require the agent to list assumptions before editing when a task touches an unfamiliar subsystem, then stop if any assumption affects data, auth, billing, or irreversible state. That keeps lightweight dispatches lightweight while turning silent guesses into reviewable decisions. A useful test is whether another engineer could reject the result from the acceptance lines alone, without reading the diff.
Distance from the average isn't a fixed property of your codebase, it's a running bill. Every deviation gets paid on every future dispatch, forever, either as a constraint you retype or a wrong guess you catch in review. I keep one naming convention that deviates on purpose, because the mainstream name reads backwards for our users, and agents reintroduce the mainstream one constantly. That bill is worth paying. Most of my others weren't.
Fast feedback, one line. Slow feedback and deliberate weirdness, write the contract. Slow feedback and accidental weirdness, delete the weirdness.
Where it falls apart is that you usually can't tell which kind of weird you have until an agent gets it wrong twice.