A common reaction to a bad model output is to add a line to the prompt: "Do not do X," often with a sample of X. Sometimes this works. Often it makes the problem worse or simply moves it. Understanding why helps you decide when a negative example is worth including.

Why "don't do this" can backfire

A prompt is context the model conditions on. When you include an example of the unwanted output, you put those exact words, structure, and tone into the context. Models are pattern continuers, so a vivid bad example can raise the odds of similar text appearing, especially when the surrounding instructions are weak or the negation is easy to miss.

Two failure modes show up repeatedly:

  • Anchoring. You show a too-chatty preamble as the thing to avoid, and outputs now begin with a paraphrase of it.
  • Over-correction. You warn against being verbose, and answers become terse to the point of dropping required details.

Negation also scales poorly. Ten "never" rules compete with each other, and the model has to satisfy all of them while doing the actual task.

What to do instead

State the positive target. Replace "don't write long explanations" with "answer in at most two sentences, then stop." A concrete target gives the model something to aim at, not merely something to dodge.

Use contrast pairs deliberately. When a negative example is genuinely needed, present it beside a corrected version, clearly labeled, so the lesson is the difference between them. A lone bad example teaches the wrong thing; a pair teaches the boundary.

Constrain the format, not the sin. If the concern is extra commentary around JSON, enforce structured output or a strict parser rather than instructing the model not to add prose. Mechanisms beat pleading.

Handle the leftovers in code. Some behaviors cannot be fully prompted away. A post-processing check that rejects or repairs the output is more reliable than a longer prompt.

How to decide

Treat each added negative instruction as a hypothesis. Run your eval set with and without it, and look at both the failure it targets and the ones it might create. If the failure rate does not drop, remove the line. Prompts accumulate warnings the way codebases accumulate workarounds, and pruning them is part of keeping the prompt understandable.