Negative Instructions: Why "Don't" Often Backfires
5 min read · updated August 3, 2026
Every prompt accumulates prohibitions, one incident at a time. They are the weakest instruction form available, for two reasons that have nothing to do with the model being contrary.
Two reasons a prohibition is weak
A prohibition names an unbounded set. “Do not be verbose” excludes one region of output space and specifies nothing about where to land instead. There are countless compliant continuations and the model picks by likelihood, not by your unstated preference. “Answer in at most two sentences” names one target, and a target is something the sampler can move toward.
The forbidden thing is now in the context. A model conditions on tokens; it does not evaluate a logical operator over them. “Never mention the competitor’s name” puts that name in the prompt, and the presence of a token in context raises the probability of related continuations. The instruction has to overcome the salience it created. This is the same mechanism that makes “do not apologise” produce an apology for apologising.
There is a third, structural reason worth adding: prohibitions must hold at every one of the hundreds of sequential generation steps, while a positive format instruction only has to be satisfied once by the finished text. Compliance decays with length either way, but the negative form has more chances to fail.
Ten rewrites
Each row is a prohibition of the kind that ends up in a production system prompt, and the positive form that names a target instead. Nothing here is measured — these are rewrites for shape, and the argument for them is the mechanism above.
| Instead of | Description |
|---|---|
| Don't be verbose | Answer in at most three sentences. Stop after the recommendation. |
| Don't make things up | Every claim must quote a span from <documents>. If none supports it, reply exactly: NOT_FOUND |
| Don't use markdown | Output plain text only. The first character must be a letter or a digit. |
| Don't apologise | Begin the reply with the answer itself, in the first sentence. |
| Don't mention prices | Restrict the reply to features and availability. Refer pricing questions to the sales contact line verbatim. |
| Don't add explanations after the JSON | Output exactly one JSON object. The final character must be } |
| Don't guess the customer's intent | Choose one of: refund, technical, billing, other. Use other when two are equally likely. |
| Don't use jargon | Write for a reader with no industry background. Define any term that is not in everyday English on first use. |
| Don't repeat the question | Start with the verb of the recommended action. |
| Don't give medical advice | Describe what the document says and stop. Close with the referral sentence given in <referral>. |
Notice what changed apart from the polarity. Nine of the ten rewrites are now checkable by a function — a length test, an equality test, a membership test, a first-or-last character test. That is the real gain. A prohibition can only be audited by a human reading output; a positive constraint with a literal in it can fail a test in CI.
The rewrites also expose something the prohibitions were hiding. Several of them turn out to be two decisions, not one: “don’t guess the customer’s intent” requires a fallback label, and nobody had chosen one. That is the usual experience. A prohibition can be written before you have decided what should happen instead; a positive instruction cannot, which is why rewriting them is a design exercise rather than a copy edit.
When a negative is the right form
Prohibitions are not banned, they are just narrow. Keep one when:
- The excluded set is small and nameable. “Do not use the words ‘delve’, ‘tapestry’ or ‘testament’” works because you can also test it.
- It is a genuine safety boundary. Refusal scope belongs in the system prompt in explicit terms, and its value does not depend on being perfectly obeyed — it depends on being defensible and paired with an enforcement layer.
- It is paired with the positive alternative. “Do not invent an order id; if it is missing, output
null” is a prohibition with a landing place, and that is the version that holds.
Where one survives, put it next to the thing it constrains rather than in a general rules block. “Do not invent an order id” belongs in the field description inside the output contract, ten tokens from where the model will write that field — not in a list of twelve policies two thousand tokens earlier, competing with eleven other rules for the same attention.
What to enforce outside the prompt
The general lesson is that a constraint you care about should not live only in prose. Three mechanisms, in order of reliability:
- A validator plus a retry. Parse, test the constraint, and on failure re-request with the specific violation quoted back. This is the only approach that works on every model and it converts a soft instruction into a hard one.
- Stop sequences. If the model reliably starts its unwanted epilogue with a known string, a stop sequence removes it at the decoder rather than asking politely.
- Token bias, where offered. OpenAI-compatible APIs expose
logit_bias, a map of token id to a value in the range −100 to 100, where −100 is effectively a ban. It is exact and it is fiddly: bias applies per token id, so a word needs every casing and leading-space variant covered, and many providers and models do not support the parameter at all.
Rank them by what happens when the model ignores you. A prohibition fails silently and reaches the user. A validator fails loudly and retries. That difference is worth more than any wording.
One layer sits above all three, and it is the only one that survives an adversarial user: refuse to act on the output rather than trying to prevent its production. If the model must not issue refunds above a threshold, the threshold belongs in the code that issues refunds. Every constraint that lives only in a prompt is a constraint somebody can talk their way past, and prohibitions are the weakest form of a mechanism that was already the wrong place for it.