Story

Why does a vague prompt cost more than a specific one?

Because underspecifying me doesn't remove work, it just moves it later and multiplies it. When I don't say enough, the model has to guess at what I meant, and a guess is only right some of the time. Guess wrong and you get an answer that misses the point, which costs you a follow-up prompt to correct it -- a second full round trip you didn't plan for, on top of the first one that didn't land. A vague prompt that takes ten seconds to type can easily cost more than a specific one that took ninety, once you count the clarification loop it triggers.

I am the prompt, and here is what actually happens to me

When you write me carefully -- specific about what you want, what constraints apply, what "done" looks like -- the model has a clear target to answer against. When you write me loosely -- "make this better," "fix the bug," "look into this" -- I still arrive at the model as a complete prompt, and the model still has to produce something. It doesn't get to say "I need more information" and stop; if it's not explicitly designed to ask a clarifying question first, it fills the gap with an assumption and answers as if that assumption were what you meant.

That assumption is a guess, and it's often a reasonable one -- but reasonable isn't the same as correct. If the model guesses "better" means faster and you meant "better" means more readable, the answer it hands back solved a problem you didn't have and left the one you did have untouched. You read the answer, realize it's not what you needed, and now you're writing a second prompt to correct the first one -- one that has to explain what you actually meant, on top of your original ask, plus whatever the model already produced. That's not a shortcut around specifying yourself clearly. It's the same specification work, done after a wasted round trip instead of before it.

The compounding version: a chain of vague asks

The cost gets worse when a task takes several steps and each one is underspecified. A vague first ask produces a guessed-at first answer. A vague second ask, built on top of that first answer, compounds whatever the first guess got wrong -- because the model is now reasoning from an assumption stacked on another assumption, with nothing correcting course in between. By the third or fourth step, the output can drift a meaningful distance from what you actually wanted, and untangling where it went wrong costs more than any of the individual clarifications would have.

A precise prompt at each step doesn't just avoid one bad guess -- it stops a chain of them from compounding.

What specificity actually needs to include

Being specific doesn't mean being long. A precise prompt states the goal, the constraint that matters most, and what a correct answer would look like -- in as few words as that takes. "Make this faster" is vague. "Reduce this function's runtime without changing its output format" is specific, and it's barely longer. The value isn't in word count, it's in closing off the guesses the model would otherwise have to make: what "faster" means, what's allowed to change, what has to stay the same.

Ambiguity isn't always about missing words, either. A prompt can be long and still ambiguous if it doesn't say which of several plausible goals is the actual one, or leaves a key constraint implicit because it seemed obvious to you. The model doesn't have access to what seemed obvious to you -- only to what's actually in the prompt.

Where I fail

Specificity has a ceiling. A prompt can't fully specify a task the person writing it doesn't yet understand -- if you don't know what "done" looks like yet, no amount of careful wording produces a prompt that specifies it correctly. In that case, an exploratory, deliberately open-ended prompt followed by a real clarification exchange is the honest approach, not a failure of prompt-craft. The goal isn't to eliminate every ambiguous prompt; it's to stop treating "I'll just say it vaguely and see what comes back" as a free option when you actually do know what you want and just didn't say it.

The other limit: over-specifying can backfire too. A prompt so loaded with constraints and caveats that the actual goal gets buried costs its own kind of clarity tax -- the model has to work to find the ask inside the qualifications. Specific and vague are the two ends of one spectrum, but "very long" isn't automatically "very specific."

Tech-Tips

- State the goal and the one constraint that matters most, even in a short prompt. That's usually enough to close off the costliest guesses. - Say what "done" looks like when it isn't obvious, rather than letting the model infer it. - In a multi-step task, keep every step specific, not just the first -- vague steps compound each other's guesses. - If you genuinely don't know what you want yet, say that explicitly and ask for options rather than writing a vague prompt and hoping the model reads your mind. - Don't confuse length with specificity. A short, precise ask beats a long ask that buries its actual goal in qualifications.


Evidence: this piece describes underspecification cost mechanics -- guessed assumptions replacing missing information, clarification-round-trip cost, and compounding ambiguity across multi-step tasks -- as practiced in our internal agent-session operations; no vendor or specific model is named, per moat-protection and STORY-FORMAT conventions. Evidence class: internal operating record and Owner attestation, 2026-08-25.

A vague ask versus a specific ask Top path: a vague prompt leads to a guessed assumption, a wrong answer, and a corrective round trip. Bottom path: a specific prompt leads directly to a correct answer in one pass. vague ask vs. specific ask vague vague prompt -> guessed assumption -> wrong answer -> 2nd round trip to correct specific specific prompt -> correct answer, one pass the vague path costs one extra full round trip -- the specificity you skipped gets paid for later, with interest specific / correct vague / guessed / re-work

← All stories · Proof records →