There’s a prompting instinct most people never shake: when the output isn’t quite right, add more description of what you want. More adjectives. More style cues. More detail about the goal.
It usually doesn’t work as well as you’d expect. Once you understand why, you stop doing it.
Why Positive Instructions Underperform
A language model generating text is always making choices — about structure, length, tone, which detail to include first, what to skip. When you say “write in a clear, engaging, conversational style,” you’ve technically given it instructions. But you haven’t narrowed the solution space much. “Clear, engaging, conversational” is satisfied by hundreds of different outputs, ranging from genuinely good writing to the blandest possible version of readable text.
The model doesn’t guess which of those hundreds of outputs you’d actually prefer. It defaults to the statistically safest one, which is usually the most generic.
Constraints work differently. “No bullet points, no summary paragraph at the end, never start a sentence with ‘Additionally'” eliminates whole regions of the output space. The model can’t fall back on its safe, boring habits if those habits are explicitly ruled out. What’s left, after enough specific constraints, is the territory where good outputs live.
What This Looks Like in Practice
Running a blog-publishing pipeline that generates and posts twice a week without human review makes this difference impossible to ignore. Early versions of the prompt had plenty of positive instruction: write in a personal voice, be specific, avoid generic observations. Output was fine, mostly. But every handful of runs, a post would drift — technically on-topic, zero specificity, the kind of writing that completes the assignment while saying nothing.
Adding more positive instruction didn’t fix it. Adding a short banned-patterns list did — specific phrases that show up in generic AI writing, structural habits like the tidy three-item recap, the confidence-building throat-clearing intro. The improvement was immediate. Not because the model became better at writing. Because it could no longer fall back on its defaults.
The same principle applies outside content generation. Writing a code prompt? “Handle errors properly” is underspecified. “Return an empty array on missing input, raise a ValueError on malformed input, never catch an exception and pass” leaves almost no room for the model to make the wrong call quietly. The constraint does more work than the instruction.
The Asymmetry Worth Understanding
Models are much better at avoiding a specifically-described failure than at hitting a vaguely-described success. The failure is concrete — you can point at it. The success is often a feeling, “I’ll know it when I see it,” which is exactly the kind of information a model can’t use.
This is why iteration works. You don’t know which constraints matter until you’ve seen the model fail in specific ways. A prompt built from zero actual failed outputs is built on assumptions about what will go wrong, and those assumptions are usually wrong. The real prompt improvement comes from running the thing, collecting outputs that aren’t right, and writing down precisely what’s wrong with each one. That list, almost verbatim, becomes the constraint section of your next prompt.
One real caveat worth naming: constraints can conflict. “Be concise” and “include a concrete example for every claim” will fight each other at some point, and the model will make a choice you didn’t anticipate. When a constrained prompt starts producing weird outputs, check whether two constraints are pulling in opposite directions. Resolving that conflict explicitly — “prefer brevity over examples when both can’t fit” — is itself a constraint, and it works better than hoping the model figures it out.
Where Positive Instructions Still Earn Their Place
None of this means positive instructions are useless. They still carry information the model needs, especially about domain, audience, and purpose. “You’re writing for a developer audience that already knows what an API is” is a positive instruction that genuinely narrows the output space — it tells the model not to define basic terms, not to add educational scaffolding, not to hedge technical claims for a lay reader.
The pattern that works: positive instructions establish context and intent, constraints eliminate failure modes. You need both. But if you have to pick which to invest more time refining, constraints usually have more leverage, because they’re acting on the specific ways your particular task tends to go wrong rather than the general shape of what you want.
Applying This Without Overthinking It
You don’t need to redesign every prompt from scratch. Next time an output frustrates you, instead of reaching for more positive description, write down exactly what’s wrong with it in one or two specific sentences. Then add that, negated, to the prompt.
“The summary felt generic” becomes “Do not include a summary paragraph. Do not restate the main point at the end.”
“It kept using vague claims” becomes “Every claim needs a specific example, number, or named tool — no abstract statements without a concrete referent.”
That’s most of what prompt improvement actually is. Not a framework. Not a formula you found in a thread. Just: see the specific failure, name it precisely, rule it out explicitly.
If your current prompts have a long description of what you want and almost no constraints on what you don’t, that’s the gap worth closing — and the fastest way to close it is to let the model show you what it defaults to when you leave it room.
