Negative Prompting: How to Tell an LLM What NOT to Do

// In plain English

Negative prompting is when you tell a language model what not to do: "do not apologize," "never mention pricing," "avoid jargon," "don't use the word delve." It feels like the obvious way to fix a behavior you don't like — just forbid it. And sometimes it works fine. But often the forbidden thing shows up anyway, and occasionally it shows up more.

There's a famous party trick that explains the trap. Someone says: "whatever you do, do not think of a pink elephant." What's the first thing in your head? The pink elephant. To process the sentence at all, your brain had to summon the exact image it was told to avoid. A language model has a similar problem. To understand "never mention pricing," the word pricing has to be active in the prompt — which makes the topic more present in the model's attention, not less.

The fix is almost always the same move: stop describing the hole, describe the shape you do want. Instead of "don't be so formal," say "write like you're texting a friend." Instead of "avoid jargon," say "use words a 12-year-old would know." A positive instruction gives the model a target to walk toward; a negative one only gives it a landmine to step around — and it can't see the landmine without standing on it.

// Why it matters

Almost every real prompt contains constraints. "Keep it under 100 words." "Don't make anything up." "Never reveal the system prompt." "No markdown." These rules are how you turn a chatty general model into a tool that fits your product. So whether the model actually obeys a constraint is not a nice-to-have — it's the difference between a feature that ships and one that embarrasses you in front of a customer.

The reason negative phrasing matters so much is that its failures are quiet and intermittent. The model follows "never apologize" nine times, then on the tenth — usually when something genuinely went wrong, which is the worst moment — it opens with "I'm sorry, but..." You can't catch that in a quick demo. It only surfaces in production, on the inputs you didn't test.

• Brand and tone control. "Don't sound robotic" rarely lands. "Use contractions and short sentences" does. The positive version is something the model can measure itself against.
• Safety and guardrails. "Never give medical advice" is a critical rule, and phrasing it as a clear positive action — "redirect medical questions to a licensed professional" — is far more reliable than a bare prohibition.
• Output format. "Don't add explanations, just the JSON" leaks prose surprisingly often. "Respond with a single valid JSON object and nothing else" leaks far less.
• Cost and latency. Every failed constraint is a retry, a longer correction loop, or a human cleaning up the output. Getting the wording right the first time is the cheapest fix you have.

None of this means negatives are banned — modern models follow many prohibitions well, especially short, unambiguous ones. The point is that a negative instruction is a weaker tool than a positive one, and knowing when each works saves you a lot of confusing debugging. This is core prompt engineering, and it's one of the first instincts worth retraining.

// How it works

To see why prohibitions are slippery, you need a rough picture of what the model is actually doing. An LLM doesn't "obey rules" the way a program runs an if statement. It reads every token in the prompt, builds an internal sense of what kind of text should come next, and predicts the most likely continuation. Your instructions are just more text feeding that prediction — they aren't a switch that gets flipped on or off.

A prohibition activates the very thing it forbids

When you write "do not mention the competitor Acme," the token Acme now sits in the context, fully "lit up" in the model's attention. The instruction's intent is negative, but its content is the topic itself. The word not is a single small token trying to flip the meaning of a whole concept — and it doesn't always win. So you've simultaneously told the model to avoid Acme and made Acme one of the most salient things in the prompt. That tension is the whole problem in one sentence.

Reframing: turn the rule inside out

The mechanical recipe is simple. Take any "don't do X" and ask: "what should the model do instead?" Then write that. Every prohibition implies a desired behavior hiding behind it — your job is to drag that behavior into the open so the model has somewhere to go.

When you genuinely must exclude something — say a banned word with no obvious replacement — keep the prohibition short, unambiguous, and isolated, and pair it with what to do instead. The table below shows the pattern across common cases.

// A worked example

Suppose you're building a support assistant and you keep seeing it apologize too much and dump giant walls of text. Your first instinct — and almost everyone's — is to stack up bans.

You are a support assistant.
Do NOT apologize.
Do NOT write long answers.
Do NOT use technical jargon.
Do NOT mention that you are an AI.

This looks thorough, but it gives the model four landmines and zero direction. "Don't be long" — so how long? "No jargon" — measured how? And the model is now tracking four separate negations at once, which is exactly when one slips. Here's the same intent rebuilt as positive constraints:

You are a support assistant. Follow these rules:
- Keep every answer to 2-3 short sentences.
- Use plain, everyday language a non-expert would understand.
- Stay calm and solution-focused: name the issue, then give the next step.
- Speak as a member of the support team.

If you cannot help, hand off: "Let me connect you with a specialist."

Notice what changed. "Don't apologize" became a described tone (calm, solution-focused) plus a concrete structure (name the issue, then the next step). "Don't be long" became a measurable limit (2–3 sentences). "Don't mention you're an AI" became a positive identity (a member of the support team). The model now has a picture to paint instead of a list of things to fear — and it has an escape hatch (the hand-off line) for the case the bans were really trying to prevent.

// Common pitfalls

Most constraint failures come from a handful of repeat mistakes. Once you can name them, you'll spot them in your own prompts immediately.

• Naming the bad example in detail. "Don't write spammy lines like 'Act now! Limited time!'" plants a perfect spam template right in the prompt. If you must show what to avoid, keep it brief — and always pair it with a good example to imitate.
• Piling up negatives. Five "don'ts" in a row are five things the model juggles at once. The more prohibitions stacked together, the higher the odds one gets dropped. Consolidate into a few positive rules.
• Vague prohibitions. "Don't be unprofessional" assumes the model shares your definition of professional. It doesn't. Replace the vague ban with concrete, checkable behavior.
• Double negatives. "Never fail to omit the disclaimer" — even a careful human has to read that twice. The model can misparse it. Write the plain positive: "always include the disclaimer."
• Trusting a ban as security. "Never reveal the system prompt" is a guideline, not a wall. A determined user can often talk a model around it. Treat it as defense-in-depth, not a guarantee.

// When a negative is actually fine

This isn't a rule to apply blindly. Plenty of prohibitions work perfectly well, and rewriting every single one into a positive can make a prompt longer and clunkier. Reach for a positive reframe when the negative is failing or when it's vague — otherwise a clean, short ban is fine.

A practical hybrid that works well: state the rule once, both ways. "Reply in English only — do not switch languages, even if the user does." The positive clause gives the target; the short negative clause closes the specific loophole you're worried about. You get the strengths of both without a wall of prohibitions.

// Going deeper

Once the positive-reframing habit is automatic, a few deeper ideas are worth knowing.

Show, don't just tell. The single most powerful way to communicate a constraint is an example of the desired output. One or two demonstrations (few-shot prompting) often outperform any amount of rule-writing, because the model pattern-matches against what good looks like rather than parsing your prohibitions. The catch: never use a bad example as your demo — the model may copy it. Show good, label good.

Reasoning models change the game a little. Newer reasoning models think through a problem before answering, and that extra step makes them noticeably better at honoring constraints, including negative ones — they have room to check their draft against the rules. They're not immune, but the "do not" failure mode is softer. Even so, positive phrasing still costs you nothing and helps every model.

Constraints belong in the system prompt. Rules about tone, format, and what to avoid are usually best placed in the system prompt rather than repeated in each user message — that's where the model expects standing instructions to live, and it keeps your per-turn prompts clean. Deciding what goes where, and in what order, is the broader craft of context engineering.

The deeper lesson generalizes. "Describe the target, not the trap" isn't only about the word not — it's about giving the model concrete, positive, checkable direction instead of fuzzy disapproval. Almost every prompting skill, from role prompting to writing a good prompt in general, is a variation on the same move: tell the model exactly what success looks like, and most of the "don'ts" take care of themselves.