"Don't mention competitors." "Never use bullet points." "Do not apologise." "Don't make up information." Prompts in production are full of prohibitions, usually added one at a time after something went wrong. And many of them do not work reliably: the model mentions the competitor anyway, slips into bullet points, apologises in a slightly different phrasing.
This is not because models ignore instructions. It is because negative instructions are a weak way to describe the behaviour you want. This guide explains why "don't" instructions misfire, what research has found, and how to rewrite them into instructions that models follow more consistently, plus when to stop relying on prompts at all.
Why negative instructions misfire
They name the thing you want to avoid
"Don't mention our competitor Acme" puts "Acme" into the context, making it more available, not less. This is the language-model version of "don't think of a pink elephant." The instruction raises the salience of exactly the content you want absent.
They don't say what to do instead
"Don't use bullet points" rules out one format but does not choose another. The model must guess the alternative, and under pressure, with a long list of items to present, it falls back on the format it was most strongly trained towards.
Negation is harder to process
Research has found that models handle negation less reliably than affirmative statements. Jang et al. (2022), "Can Large Language Models Truly Understand Prompts? A Case Study with Negated Prompts," reported that models performed markedly worse on negated versions of task instructions, and that larger models were not consistently better at them. Models have improved since, but negation remains a weaker signal than a clear positive description.
They compete with training
Many prohibitions fight behaviours that were strongly reinforced in training, such as apologising, hedging, summarising at the end, or offering further help. A single "don't" line competes with millions of training examples.
They accumulate and conflict
Long lists of prohibitions grow by incident. Over time they contradict each other or the main instructions, and the model has to choose which to break.
Five rewrites that work better
| Negative instruction | Positive rewrite |
|---|---|
| Don't use bullet points. | Write in short paragraphs of two to three sentences. |
| Don't make up information. | Answer only from the documents provided. If they don't contain the answer, say "I couldn't find that in our documentation." |
| Don't be verbose. | Keep answers under 100 words. Lead with the answer in the first sentence. |
| Don't mention competitors. | If asked about other products, describe our product's relevant features and suggest the comparison page at /compare. |
| Don't apologise. | When something went wrong, acknowledge it in one sentence and move straight to the fix. |
The pattern: describe the target behaviour concretely, including what to do in the situation that triggered the prohibition.
Rewrite 1: describe the format you want
Replace format prohibitions with a template or a specific description. A literal example of the desired output is often the strongest signal.
Rewrite 2: give an acceptable alternative
Most prohibitions guard against a situation: the user asks about a competitor, the documents don't answer, the request is out of scope. Write instructions for that situation, with a specific response. Models comply more easily when there is a good path to follow.
Rewrite 3: define scope instead of listing exclusions
Instead of listing every forbidden topic, describe what the assistant is for and give one standard response for everything else: "You help with billing and account questions for Acme Invoicing. For anything else, say you can only help with billing and account questions and suggest contacting support@…"
Rewrite 4: make it measurable
"Be brief" and "don't ramble" are unmeasurable; "under 100 words" is a rule you can check in an eval. Measurable instructions also make prompt reviews faster, because everyone agrees what compliance looks like.
Rewrite 5: show, sparingly
One example of the desired behaviour in the tricky situation often beats several rules. Avoid examples of the *wrong* behaviour; models can copy them as easily as good ones. See few-shot examples that don't backfire.
When a negative instruction is fine
Some prohibitions are clear, short and do not name tempting content: "Do not include personal data in the summary," "Never ask for passwords." These often work, especially combined with a positive alternative ("If the user shares a password, tell them to change it and do not repeat it"). Keep negatives for genuine boundaries, phrase them simply, and pair each one with what to do instead.
When to stop relying on the prompt
Some rules are too important to leave to instructions at all:
- Security and permissions: enforce in code; prompts can be overridden; see how to red-team an LLM chatbot.
- Hard content rules such as never outputting certain identifiers: add an output filter or validator.
- Format requirements for machine-readable output: validate and repair in code.
- Brand terms and banned phrases: check outputs with a simple filter and regenerate if needed.
The prompt shapes behaviour most of the time; code guarantees it when it matters.
Auditing your existing prompt
- List every "don't," "never" and "avoid" in the prompt.
- For each, find the eval cases that test it. If none exist, add them.
- Rewrite each as a positive instruction with an alternative behaviour.
- Run your eval set with the old and new versions; compare violation rates for each rule.
- Move any rule that still fails too often into code.
- Delete rules that no test depends on and that don't change behaviour.
For where behaviour rules belong in a complete prompt, see anatomy of a production system prompt, and for finished examples written in this style, see system prompt templates for production.
A worked example
Here is a typical "incident log" section from a support prompt, followed by a rewrite.
- Don't use bullet points.
- Never mention competitors.
- Do not make up refund policies.
- Don't be too long.
- Don't say "unfortunately".- Write in short paragraphs; keep answers under 120 words.
- Answer only from <docs>. If <docs> doesn't cover the question, say so and offer a human agent.
- If asked about other products, explain the relevant features of ours and link /compare.
- When something went wrong, acknowledge it once, then give the next step.The rewrite is shorter, every line describes an action, and every line can be tested.
Frequently asked questions
Why do LLMs ignore "don't" instructions?
Negative instructions name the unwanted content, which makes it more salient, and they don't specify what to do instead. Negation is also processed less reliably than positive statements, and some prohibitions fight strongly trained habits.
How should I write instructions for an LLM?
Describe the desired behaviour concretely and measurably, give a specific response for the situations you're worried about, define the assistant's scope rather than listing exclusions, and use a short example where needed.
Are negative prompts ever useful?
Yes, for short, clear boundaries that don't name tempting content, especially when paired with a positive alternative. Critical rules should also be enforced in code.
What should I do if the model keeps breaking a rule?
Rewrite it as a positive instruction with an alternative behaviour, add eval cases for it, and if it still fails too often, enforce it with a validator or filter in code.
