Why Telling AI Not to Do Something Fails

Telling AI not to do something is the least reliable instruction you can write. You asked for no bullet points and the answer came back in bullet points, which is neither defiance nor a bug you can report. Negative instructions underperform because the thing you named is now sitting in the context, weighted and available, while the word not carries far less force than the concept it is meant to cancel. What does work is describing the output you want instead of the output you are trying to prevent.

What happens when you write do not

Two things, and they pull in the same unhelpful direction. First, mentioning a concept makes it more available to the model, exactly as telling a person not to think about a red door introduces a red door. Second, negation is genuinely difficult for these systems in a way that has been measured rather than assumed.

Researchers examining language models against negation benchmarks found that models classify affirmative sentences well and struggle markedly with negated ones, leaning on surface cues rather than a stable representation of what negation does, and that fine-tuning on negated examples improves the score without producing generalisation. A 2025 study from MIT reached a similar conclusion for vision-language models, which could not reliably handle queries containing negation words. Model quality has improved a great deal since; the asymmetry between do this and do not do that has not gone away.

Vendor guidance says the same thing without the citations. Anthropic's prompting documentation lists tell Claude what to do instead of what not to do as its first technique for steering output format, with the example of replacing do not use markdown with a description of the prose you want.

The conversion table

Most negative instructions have an obvious positive twin. The rewrite is usually longer, which is the price.

The pattern is consistent: a negative instruction defines an infinite space of forbidden outputs, a positive one defines a small space of acceptable ones. The second is a target the model can aim at.

The exception that genuinely works

There is one shape of negative constraint worth keeping: a short, closed, checkable list. Not a description of a quality to avoid, but specific items something else can verify afterwards.

Forbidden terms, do not appear anywhere in the output:
  leverage, synergy, best-in-class, cutting-edge

After writing, scan your answer for each term above and
rewrite any sentence containing one. State "scan clean"
on the final line.

That works for two reasons. The list is finite, so the model has a definite thing to check rather than a vibe to avoid, and the output ends with an assertion your code can test. If the final line is missing, you reject and retry. A negative constraint you can verify is a constraint. One you cannot is a hope.

Why this matters more with agents

In a chat, a violated instruction costs you a reroll. With an agent that edits files or calls tools, the same failure lands in your repository. Do not touch the tests is the most expensive four words in the genre, and the reason an agent changes code you never asked it to touch is often that the boundary was phrased as a prohibition rather than as a scope.

Rewriting the boundary as a positive scope also gives you something to check mechanically. Confine every change to these two files is a rule a script can enforce against the diff. Do not go wild is not.

A five-minute rewrite drill

1. Open the prompt you use most often and highlight every do not, never, avoid and without.

2. For each one, write the sentence describing what should happen instead. If you cannot, you have found an instruction you never really specified.

3. Delete the original negative unless it belongs on a checkable forbidden list.

4. Run both versions over the same ten inputs and count violations rather than reading impressions.

People are routinely surprised by how many of their negatives were never real requirements, just irritations from one bad output months ago that calcified into the prompt. Clearing them out tends to do more for output stability than any clever addition, which is the same lesson behind getting consistent output every time and behind most of what makes fixing a bad prompt work. If you are building the habit from scratch, the wider discipline of prompt engineering is where the rest of it lives.

Common questions

Do negative instructions ever work?

Often enough to be misleading. A single clear negative in a short prompt usually holds. The failure rate climbs with prompt length, with the number of simultaneous constraints, and across long agent sessions, which is exactly when you are least likely to be watching.

Should I put constraints in the system prompt instead?

That helps with persistence but does not change the mechanism, and a negative in a system prompt is still a negative. Put the positive version there. The difference between system and user prompts is about durability, not about how instructions are interpreted.

What about safety rules that have to be prohibitions?

Enforce those outside the prompt. A rule that genuinely must hold belongs in code: a filter, a permission boundary, a validation step. Anything phrased as an instruction is a strong preference, not a guarantee, and treating it as a guarantee is how systems fail quietly.