Negative Prompting

Why this matters

Most prompt instructions tell the model what to do. Negative prompting is the inverse: telling it what not to do — exclude a topic, avoid a phrasing, never call a tool, don't apologize. You reach for it constantly without naming it, because real tasks have boundaries: "don't include PII," "no markdown," "avoid medical advice." Used well, negatives are the cheapest way to close off a failure mode you've actually observed.

But negatives carry a known hazard. Telling a language model not to do something forces the unwanted concept into the context, and the model conditions on everything in its context — including the thing you tried to suppress. This is the "don't think of an elephant" problem: the prohibition makes the elephant more salient, not less. In image generation the term "negative prompt" refers to a dedicated channel that genuinely subtracts a concept from the output. In text generation there is no such channel — a negative is just more text the model reads, so the effect is far less reliable. The empirical prompt-engineering literature is consistent on the direction here, even if the magnitude varies by model and task: positive instructions are generally more dependable than prohibitions.

How to use negatives well

Negatives are legitimately useful in three situations:

• Excluding a concrete, namable thing the model would otherwise reasonably include — a competitor's name, a deprecated API, a forbidden library.
• Suppressing a recurring stylistic tic you've seen in this model's outputs — opening with "Certainly!", over-hedging, restating the question before answering.
• Hard safety or policy boundaries where you want an explicit "never" on record even if it isn't perfectly enforced.

When you do write a negative, make it specific. "Don't be verbose" is weak — verbose is subjective and gives the model nothing to act on. "Do not exceed three sentences per answer" is enforceable. Vague negatives are nearly useless; precise ones are far better.

The core move: restate as a positive

Before committing a prohibition, ask whether it can be expressed as something to do instead. This usually produces a clearer, more reliable instruction because it gives the model a target rather than a void to avoid.

Instead of "Don't write long paragraphs," say "Write in paragraphs of two to three sentences."

Instead of "Don't use technical jargon," say "Explain each concept in plain language a non-engineer would follow."

Instead of "Don't make up sources," say "Cite only sources present in the provided documents; if none apply, write 'no source available.'"

Notice that the last example does more than rephrase — it gives the model a concrete fallback action. A prohibition leaves a gap; a positive instruction fills it, which is exactly what reduces the unwanted behavior.

A worked example

Suppose you're building a support assistant and you keep seeing it recommend phone support, which your company doesn't offer. The instinct is:

Never tell the user to call us. We have no phone line.
Do not mention phone support.

This puts "phone," "call," and "phone support" directly into context. Some models will dutifully avoid it; others will surface a phone number anyway, primed by the very words you used. The more robust version names the desired behavior and supplies the alternative:

When a user needs human help, direct them to live chat
(available 9am-6pm ET) or email support@acme.com.
These are the only two support channels Acme offers.

Now there's nothing to forget to avoid — the model simply has the right answer to give. The exclusion is achieved as a side effect of a complete positive instruction.

Pitfalls

• The elephant effect. Long lists of "do not mention X, Y, Z" can increase the chance those topics appear, especially in smaller or less instruction-tuned models. If you find yourself enumerating forbidden topics, that's a signal to invert the framing.
• Negatives don't compose well. A wall of "don'ts" gives the model a shape of the gap but no picture of the goal. Three positive instructions almost always outperform ten prohibitions.
• Vague negatives are noise. "Don't be unhelpful," "avoid bad formatting" — these aren't actionable. Either make them concrete or delete them.
• It varies by model. Larger, well-aligned models follow explicit negatives more reliably than older or smaller ones. Don't assume a "never" you wrote once still holds when you swap models — re-test it.
• Don't rely on a negative for safety-critical exclusion. If a topic absolutely must not appear, a prompt-level "don't" is a soft control. Pair it with output filtering or validation rather than trusting the instruction alone.

The practical rule: write the positive instruction first. Reach for a negative only when the thing you want to exclude is specific, namable, and has no natural positive restatement — and when it matters, verify the model actually obeys it rather than assuming it does.