Vague instructions don’t produce random results. They produce the statistically safest interpretation of what you asked — which is almost never what you actually wanted.
Understanding why this happens is more useful than just knowing it does. And the fix is different from what most prompting advice tells you.
The Mechanism, Not the Symptom
When you give a language model a goal like “write something professional” or “make this better” or “summarize this clearly,” it doesn’t freeze up. It fills the gap. It finds the most common pattern in its training data that satisfies the surface-level instruction, and produces that.
This is why every vague “write me a bio” prompt returns something that sounds like it was pulled from a LinkedIn template graveyard. Not because the model is lazy — because “professional bio” has a very strong prior in training data, and without a concrete constraint to push against, the model gravitates toward it. The same thing happens with code (you get the most common solution to a class of problem, not necessarily the right one for your specific situation), emails (you get formal and polite, even when you needed blunt), and plans (you get thorough and hedge-everything, even when you needed fast and decisive).
The failure isn’t random. It’s predictable. Which means it’s fixable.
What “Vague” Actually Looks Like in Practice
The sneaky part is that vague prompts often feel specific when you write them. A few examples of prompts that seem fine but aren’t:
- “Improve the tone of this email.” Improve toward what? Warmer? More assertive? Less wordy? The model will pick one — probably whichever is most common for the email type it thinks it’s looking at.
- “Give me ideas for my project.” What kind of ideas? Execution ideas? Positioning ideas? Names? Risk-mitigation ideas? You’ll get a broad list that feels helpful but rarely contains the one angle you actually needed.
- “Make this shorter.” By how much? Cut what — filler, or actual content? The model will trim things that look optional to it, which is not the same as what’s optional to you.
In each case, the model does something. It just does its version of the task, not yours.
The Fix Isn’t Adding More Adjectives
When a prompt doesn’t work, the instinct is to pile on more description — “write something really professional and engaging and not too formal.” This rarely helps, because those are still vague. “Engaging” is a direction, not a destination.
What actually narrows the output space is one of three things:
A concrete negative example. “Don’t start sentences with ‘I’.” “Avoid bullet points.” “Don’t include anything that sounds like a mission statement.” Models are genuinely better at avoiding a described failure than optimizing toward a described ideal — because the failure is easier to define precisely. Running automated pipelines without a human reviewing every output taught me this the hard way: the prompts that held up over dozens of runs were the ones with explicit ban lists, not the ones with aspirational style guidance.
A specific output shape. “Three sentences, no more.” “One concrete recommendation, not a list of options.” “Return only the revised paragraph, nothing else.” Shape constraints cut off a huge range of possible outputs before the model even starts filling in content.
A concrete success criterion. Instead of “make it sound natural,” try “a colleague reading this in 10 seconds should immediately know what action I’m asking them to take.” That’s something the model can actually test against while generating.
Vagueness Compounds Across Multi-Step Tasks
A single vague prompt produces a mediocre output. But when you’re chaining prompts — using one output as the input to the next step — vagueness compounds. A slightly off first pass leads to a second pass that corrects toward the wrong target, and by step three you’ve drifted somewhere neither you nor the model intended.
This matters most for anything with multiple stages: draft to edit to refine, or research to outline to write. The constraint you skip at step one causes a larger problem at step three, and it won’t be obvious what went wrong.
The practical fix: lock down what “done” looks like at each step before moving to the next one. Not in general terms — specifically. “This draft is ready for editing when it has exactly one call to action and no hedging language.” That kind of thing.
One Thing Worth Being Honest About
Tighter prompts take more upfront effort. Writing a good negative-example list means you have to already know, at least roughly, what failure looks like for that task — which means you probably need to run it badly once first. This is annoying but not avoidable. The useful knowledge about what to constrain comes from watching an unconstrained version go wrong.
So the actual workflow isn’t “write a perfect prompt from scratch.” It’s: run a vague version, see exactly how it fails, translate that specific failure into a constraint, add it to the prompt. One or two cycles of this usually gets you somewhere stable. More than that and you’re probably fighting a different problem — the task itself might not be well-defined, not just the prompt.
A Quick Test Worth Running
Take any prompt you use regularly. Ask yourself: if the model interpreted this in the least useful way that still technically satisfies the words, what would that output look like? If you can picture it clearly — if there’s a recognizable bad version the prompt technically allows — that’s your constraint target. Write down what’s wrong with that bad version and add it as an explicit exclusion.
The output won’t be perfect after that. But it’ll fail in a narrower, less predictable way, which means you’re making progress.
Most prompting advice skips this step because it requires sitting with a bad output instead of chasing the next technique. Do it anyway — it’s where the actual signal is.
