Negative Constraints vs Positive Specifications

"Don't be too long" vs "≤ 80 words"

Negative constraints ("don't," "avoid," "never") tell the model what to subtract from infinite possibility. Positive specifications ("do this," "≤ 80 words," "start with the verdict") tell it what to construct. Models are dramatically better at construction than subtraction.

Why subtraction fails

Telling a model "don't use the word 'unfortunately'" can make it more likely to produce the word, because attention has been allocated to it. "Open with the result, not an apology" achieves the same intent positively, by giving the model something to do instead of something to avoid.

When negative constraints earn their place

Safety policies ("do not provide medical dosages") — required, even though they're negative.
Format anchors after a positive spec ("output JSON only — no preamble, no markdown fences").
Drift breakers in long prompts ("do not begin with 'I'd be happy to help'").

The pattern: lead with positive specifications, follow with the few negatives that name the failure modes you actually see.

Code

Refactor: negative-only → mostly positive·markdown

# Before — five "don't"s, no "do"
Don't be too verbose.
Don't apologize.
Don't repeat the question.
Don't use markdown headers.
Don't include disclaimers.

# After — positive spec + targeted negatives
Return one paragraph, ≤ 100 words.
Open with the verdict in the first sentence.
Use plain prose; no markdown headers, no fenced code.
If the answer is uncertain, append a single sentence beginning with "Confidence:".

Negative Constraints vs Positive Specifications

"Don't be too long" vs "≤ 80 words"

Why subtraction fails

When negative constraints earn their place

Code

External links

Exercise

Progress

Comments 0