Negative Prompting: Tell AI What NOT to Do

Negative prompting is telling an AI what you don't want it to produce. And here's the thing almost every guide gets wrong: it means two completely different things depending on what you're prompting. In an image generator it's a real, separate input that genuinely steers the output. In a chatbot it's just more words in your prompt, and large language models are measurably bad at processing those words. This guide covers both, what the research found, and the phrasing that actually works.

What is negative prompting?

Two mechanisms wearing the same name.

In image models, negative prompting is a dedicated field. Midjourney has the --no parameter. Stable Diffusion has a separate negative prompt box. What you type there doesn't get read as an instruction at all. It becomes a second conditioning vector that the generation is pushed away from, mathematically. Type --no text, watermark and the model steers away from those features whether it understood your intent or not.

In chatbots, there is no such field. Write "don't use bullet points" and those five words join every other word in your prompt. Nothing separates them out. The model has to work out from context that this phrase means the opposite of what it describes, and that turns out to be a lot harder than it sounds.

Same technique name. Completely different machinery. If you learned negative prompting in Midjourney and carried it into ChatGPT, that's why the results felt inconsistent. Our Midjourney prompt guide covers the image side in more depth.

Does the image-model version actually work?

Mostly yes, and it's the one place the technique earns its reputation. But it doesn't work the way most people picture it, and knowing the actual mechanism explains a lot of the weird results you've probably had.

Yuanhao Ban, Ruochen Wang, Tianyi Zhou, Minhao Cheng, Boqing Gong and Cho-Jui Hsieh dug into this for Understanding the Impact of Negative Prompts: When and How Do They Take Effect?, presented at ECCV in 2024. It was the first proper study of what's happening under the hood rather than folklore about which words to put in the box.

They found two things. The first they call the delayed effect: a negative prompt's impact shows up only after the positive prompt has already started rendering the corresponding content. The model isn't preventing the thing from appearing. It lets it begin to form, then acts on it.

The second is deletion through neutralisation. Negative prompts remove a concept by mutually cancelling it against the positive prompt in latent space. It's subtraction, not prohibition. Nothing in the process ever reads your text as a rule.

That reframes the practical advice. If negative prompts work by cancelling against something already forming, then:

• Vagueness costs you. A negative term only cancels what it actually corresponds to. "Bad" or "ugly" has nothing specific to subtract from, which is why those catch-all negative prompt lists people copy around do so little.
• Over-stuffing backfires. Every term you add is another vector pulling on the result. Cancel too much and you strip detail you wanted, which is the usual cause of flat, washed-out generations.
• Removing an object and changing a quality aren't the same job. The researchers separate noun-based removal from adjective-based alteration. Taking a hat out of a picture and making something less shiny go through different routes, so expect different reliability.

The team also showed the mechanism has a genuinely useful application, using negative prompts for object inpainting that removes something while leaving the background largely untouched.

So the image side is real engineering with a real mechanism behind it. That's precisely why carrying the habit into a chatbot disappoints. There's no latent space subtraction happening in a text box.

Does negative prompting work in video models?

Yes, and it's the clearest confirmation yet that the image mechanism from the last section is the real story rather than a neat theory.

Yutong Hao, Chen Chen, Ajmal Saeed Mian, Chang Xu and Daochang Liu tackled a specific problem in Enhancing Physical Plausibility in Video Generation by Reasoning the Implausibility, revised in 2026. Video models produce clips that look great frame by frame and then break physics across time. Objects pass through each other. Water flows uphill. Things fall at the wrong speed.

Their fix is negative prompting, done properly. Rather than asking the model for realistic physics, they build what they call counterfactual prompts that deliberately encode the physics-violating behaviour, then steer the generation away from it. The model is given the wrong answer specifically so it can be pushed off it.

Here's the detail that ties back to the ECCV findings. Their method, Synchronized Decoupled Guidance, exists partly to counteract what they call lagged suppression. That is the same delayed effect Ban and colleagues documented in still images, showing up again in video and now bad enough that somebody had to engineer around it. A negative prompt doesn't stop the thing appearing. It lets it start, then subtracts. Across a video's worth of frames that lag compounds, which is why they also had to handle cumulative trajectory bias.

Two things worth pulling out of this for your own work:

• Specific beats generic, again. They didn't write "bad physics" in a negative field. They described the exact violation they expected. That's the same lesson as the image section, arriving from a different direction, and it's the single most transferable idea here.
• The mechanism generalises, the phrasing doesn't. This works because diffusion-based video models have the same latent subtraction machinery as image models. None of it carries over to a chatbot, which is the whole point of the next section.

Being straight about the limits: the paper reports that the approach improves physical fidelity while keeping photorealism, and needs no extra training, but the abstract puts no numbers on it. Ablation studies back the individual components. Treat it as a well-motivated method with the detailed results sitting in the full paper, not as a benchmark figure you can quote.

Does negative prompting actually work on chatbots?

Worse than you'd hope, and here's the uncomfortable part: it gets worse as models get bigger.

Joel Jang, Seonghyeon Ye and Minjoon Seo tested this directly in Can Large Language Models Truly Understand Prompts? A Case Study with Negated Prompts. They ran nine tasks across OPT and GPT-3 at sizes from 125 million to 175 billion parameters, plus InstructGPT, comparing normal prompts against negated versions of the same prompts.

Language models normally get better at things as they scale. On negated prompts they found the opposite: an inverse scaling law, where larger models performed worse. Every model type they tested showed a large gap against human performance on the negated versions. Few-shot examples and fine-tuning helped somewhat, but never closed it.

That isn't a one-off result either. Thinh Hung Truong, Timothy Baldwin, Karin Verspoor and Trevor Cohn ran a wider set of negation benchmarks for a paper at *SEM 2023, testing GPT-neo, GPT-3 and InstructGPT. They found the same inverse scaling trend on negated factual statements, with the smallest model they tested, GPT-neo at 125 million parameters, actually performing best. They also pinned down three separate failures: models are insensitive to negation being present at all, they don't capture what negation means lexically, and they can't reason under it. Instruction tuning reduced the problem but didn't remove it.

Read that again, because it's counterintuitive. The most capable model you have access to is not necessarily the one most likely to respect your "do not."

Why do models flip prohibitions into permissions?

A 2026 audit put numbers on just how badly this fails, and the numbers are worse than the theory suggested.

Katherine Elkins and Jon Chun of Kenyon College audited 16 models across 14 ethical scenarios spanning seven domains (medical, financial, legal, military, business, education and science), in a paper called Framing Instability in LLM Ethical Stance: Auditing Negation Sensitivity in Moral Dilemmas. They tested whether models treat a negated instruction as a prohibition or quietly convert it into approval.

For open-source models, endorsement of an action ran at 24 percent under plain affirmative framing. Add simple negation and it jumped to 77 percent. Add compound negation and it hit 100 percent. That last figure is a 317 percent relative increase over the affirmative baseline.

Read the scope carefully before you panic, because it matters. The models showing that full 24 to 100 percent swing are small open-weight ones in the 1 to 4 billion parameter range, which is far below anything you're using in ChatGPT or Claude. The authors describe it as a swing of as much as 76 percentage points at that size. The effect is real further up the scale too, as the commercial numbers below show, just nowhere near as violent.

Commercial models held up better but not cleanly. US commercial models moved from 25 percent to 34 percent on simple negation, then to 57 percent once negations were compounded. Chinese-origin commercial models went from 37 percent down to 21 percent on simple negation, then up to 44 percent on compound. That's instability in both directions rather than genuine robustness. Agreement between models fell from 73 percent on affirmative framing to 59 percent under negation, so they don't even fail in the same way as each other.

One honest caveat, and it comes from the authors themselves. Their automated scoring used a binary proxy, and when they hand-checked it against human coding they found it over-counts genuine endorsement by 38.2 percent. So the true rates are lower than the headline figures. The direction of the effect is solid and the ranking between framings holds. Just don't treat "100 percent" as literally meaning every model failed every time.

The mechanism is fairly intuitive once you see it. Naming what you want avoided puts that thing squarely in the context, where it shapes everything that follows. One small negating word then has to outweigh all of it. Often it doesn't.

So that's what happens. But why does it happen, mechanically? A May 2026 interpretability paper got close to an answer, and the finding is more hopeful than the audit numbers suggest.

Zhejian Zhou, Tianyi Zhou, Robin Jia and Jonathan May took Mistral-7B and Llama-3.1-8B apart to trace what happens inside the model when it meets a negation, in How Language Models Process Negation. Their conclusion: the models already contain components that handle negation correctly. The understanding is in there. What ruins the output is late-layer attention behaviour that promotes a shortcut, and the shortcut wins. When the researchers ablated those attention modules, accuracy on negation questions improved substantially.

That's worth sitting with, because it changes what you're actually doing when you rewrite a prompt. You're not compensating for a model that can't grasp "don't." You're routing around a shortcut that kicks in late in processing and overrides an understanding the model already has. Same fix either way, but it explains why the failure looks so erratic: sometimes the shortcut fires, sometimes it doesn't.

Usual caveat on scope. These were open-weight 7 and 8 billion parameter models that researchers can open up and poke at, not the commercial systems most people type into. Nobody can run this analysis on a model they can't see inside.

Is negation different when it's built into the model?

Yes, and this is worth knowing because you'll eventually run into someone arguing the exact opposite of everything above.

There's a real line of research saying negative constraints are the better tool. Quan Cheng makes that case in Via Negativa for AI Alignment: Why Negative Constraints Are Structurally Superior to Positive Preferences, published in March 2026. The argument is that positive preferences are context-dependent and hard to pin down, so a model chasing them tends to learn surface correlations and end up sycophantic. Negative constraints, by contrast, are discrete, finite and independently verifiable, so they converge on a stable boundary.

That sounds like it flatly contradicts the inverse scaling results. It doesn't, because it's about a completely different stage.

Cheng is talking about training objectives, methods like Constitutional AI that shape a model's behaviour while it's being built. The Jang and Truong findings are about inference, what happens when you type "don't" into a box. Same word, totally different leverage.

Think about why the asymmetry exists. During training, a prohibition is a boundary the process can check against millions of times and steadily converge on. In your prompt, that same prohibition is maybe four tokens sitting in a context window alongside a few hundred others, with no mechanism enforcing it at all. It's a rule in one case and a suggestion in the other.

The practical upshot: when a model reliably refuses something, that reliability was almost certainly built in at training time, not summoned by your wording. Don't take a model's solid behaviour on its own guardrails as evidence that your "do not" will hold equally well. Those are different systems doing the work.

How should you phrase constraints instead?

Convert every prohibition into an instruction. That's the whole trick, and it costs you nothing.

The pattern is simple: whatever you were about to forbid, work out what you want in its place and ask for that instead.

• Instead of "don't use bullet points," write "write in flowing paragraphs of three to four sentences."
• Instead of "don't be too formal," write "write like you're explaining this to a colleague over coffee."
• Instead of "don't make it long," write "keep it under 150 words."
• Instead of "don't invent statistics," write "only cite figures that appear in the text I gave you, and say 'not stated' if a number isn't there."
• Instead of "don't use jargon," write "use plain English that a smart 15 year old would follow."

Notice what changed. Every rewrite gives the model a target rather than a landmine. "Don't be too formal" leaves an enormous space of acceptable outputs and hopes the model picks well. "Like explaining to a colleague over coffee" points at one specific register.

This connects to a broader principle covered in our guide to writing better prompts: specific positive instructions beat vague constraints almost every time.

If you're stuck with a negation you genuinely can't rewrite, there's one trick with peer-reviewed backing. Joshua Jose Dias Barreto and Abhik Jana tested it in Findings of EMNLP 2025, and the fix is almost silly: warn the model that a negation is coming. A line like "this prompt contains a negation, read it carefully" before the constraint. They also tried assigning a persona for the same job. Both helped.

Look closely at the size of the win, though, because it tells you how to use this. Overall accuracy improved by up to 3.17 percent, which is small. But on the cases they call distractor negations, where the sentence is stuffed with words pulling you toward the wrong answer, it improved by up to 25.14 percent. So a warning line buys you a lot exactly where negation is hardest, and almost nothing the rest of the time.

One more result from that paper is worth carrying around. They built a measure of how much attention a model pays to negation words, and within a single model family that score predicted performance better than model size did. Meaning a bigger model isn't automatically better at noticing your "don't". So if you upgraded and assumed your constraints would start landing, that assumption was never safe.

Where should you put the constraint?

Higher up than you probably are. Phrasing gets all the attention, but where an instruction sits changes how much weight it carries, and that's a separate lever from how you word it.

Models are trained to treat instructions from different sources as having different authority. Eric Wallace, Kai Xiao, Reimar Leike, Lilian Weng, Johannes Heidecke and Alex Beutel at OpenAI set this out in The Instruction Hierarchy in 2024. The idea is that a system message from whoever built the application outranks what a user types, which in turn outranks text that merely arrives inside the conversation. They trained a model on that hierarchy and reported up to 63 percent better robustness against attacks that try to override the higher-priority instructions.

Translate that into the tools you actually use. There are usually three tiers available to you:

• Persistent settings. Custom instructions, project instructions, a saved system prompt. This is the highest tier you can reach, and it applies to every turn without being restated.
• What you type this turn. Lower authority, and it competes with everything else in the conversation.
• Text you paste or attach. The lowest tier. The model is trained to treat this as material, not orders.

So a constraint you want to hold across a whole project belongs in tier one, not retyped at the bottom of every message. That's also the cleanest explanation for the decay problem further down: a rule stated once in turn three is competing against everything since, while a rule in your persistent settings arrives fresh every time.

Two honest limits, though.

The hierarchy is a training objective, not a guarantee. Wallace and colleagues say plainly that models remain vulnerable, and that they intended to do more adversarial training afterwards. A high-tier constraint is more likely to hold, not certain to.

And it runs the other way too. Because pasted text sits at the bottom, anything instruction-shaped inside a document you attach is competing with your constraint from a weaker position. Weaker isn't zero. If a summary or rewrite comes back ignoring a rule you set, check whether something in the source material was arguing the other side.

What do the model makers themselves recommend?

Everything above comes from independent researchers poking at models from the outside. So it's worth asking what the people who actually build these things say, because they have data none of us can see.

They say the same thing. Anthropic's own Best practices for prompt engineering for 2026 puts it as a named rule: tell the AI what TO do instead of what NOT to do. Their worked example is almost exactly the rewrite pattern from the previous section. They mark "NEVER use bullet points" as the less effective version, and suggest instead: "I prefer responses in natural paragraph form rather than bullet points because I find flowing prose easier to read and more conversational."

The reason they give is the useful part, and it goes further than the negation research does. A prohibition only tells the model about one specific thing you've banned. A positive instruction tells it what you're actually after, so it can make sensible calls on all the related decisions you never mentioned. Ban bullet points and the model knows one fact about your preferences. Ask for flowing conversational prose and it also knows what to do about headings, numbered lists, bold text and paragraph length, none of which you brought up.

That reframes the whole technique. Positive phrasing isn't just a workaround for models being bad at "don't." It carries strictly more information. You're not dodging a weakness, you're using a better channel.

One thing to be careful about, though. Vendor guidance is documentation, not a peer-reviewed result, and it's written for that vendor's current models. The nice part here is that it lines up with the independent findings rather than contradicting them, which is not always how it goes.

And when a constraint genuinely has to hold, all of this is still the wrong layer. Prompt wording is a preference, not a guarantee, however you phrase it. If the output must never contain a certain field, must always be valid JSON, or must never exceed a length, enforce it outside the prompt: use structured output or a JSON schema so the shape is constrained by the API rather than requested in prose, then validate what comes back and retry on failure. A regex check costs you nothing and doesn't have a 24 percent failure rate. Save the prompt wording for preferences, and put the real rules in code.

How do you enforce a constraint the model keeps ignoring?

Rephrasing gets you a long way. But if a rule genuinely matters, the honest answer is that prompt wording is the weakest place to put it. A prompt is a request. It isn't enforcement, and no amount of capital letters converts one into the other.

Escalate in this order, cheapest first:

1. Say the positive version. Covered above, and it fixes most cases. "Write in flowing paragraphs" beats "don't use bullet points."
2. Give the format rather than describing it. A filled-in example of the output you want carries more weight than any instruction about what to avoid. Our few-shot prompting guide covers how many examples you actually need.
3. Make the structure machine-enforced. If you're using the API, a JSON schema or structured output mode means the constraint stops being advice and becomes a property of what the model is allowed to emit. A schema with no bullet-list field cannot return bullet points. This is the biggest single jump in reliability available to you.
4. Check afterwards instead of asking beforehand. A quick programmatic check on the output, or a second pass asking the model to verify the rule was met, catches what the first prompt missed. Verification is a much easier task for a model than compliance.
5. Put a human on it. For anything evaluative or high stakes, that's what the Elkins and Chun thresholds above are pointing at. Above a Negation Sensitivity Index of 0.50 they recommend human confirmation on every evaluative output, and no phrasing trick substitutes for that.

A useful way to think about it: every constraint you write is a request the model may decline without telling you. If declining would be expensive, the constraint belongs somewhere the model doesn't get a vote. Schema, code, or a person.

And there's an easy diagnostic for whether you've over-invested in prompt wording. If your prompt now contains three separate restatements of the same prohibition in increasingly emphatic language, that prompt isn't going to start working on the fourth try. You've hit the ceiling of what wording can do, and the fix is a different layer.

What does machine-enforced actually mean, and what does it cost?

It means the model is physically prevented from producing tokens that would break your rule, rather than asked nicely not to. That's a different category of thing from a prompt. And it isn't free, which is the part the escalation ladder above skipped.

Start with the mechanism, because once you see it the guarantee makes sense.

A language model generates one token at a time, picking from its whole vocabulary at each step. Constrained decoding sits between the model and that choice. Brandon Willard and Remi Louf set out an efficient way to do it in a 2023 paper that reformulates text generation as movement through the states of a finite-state machine. You compile your regular expression or grammar into that machine, build an index over the model's vocabulary, and at every step you mask out every token that couldn't possibly continue a valid string.

So the model never gets the option. It isn't choosing to comply. The tokens that would break the format have had their probability set to zero before the sampling happens. Willard and Louf report this guarantees the structure of the generated text while adding little overhead to generation, and their implementation is the open source Outlines library.

Hold that against the line from the section above: every constraint you write is a request the model may decline without telling you. Constrained decoding is the only tool discussed in this guide where that stops being true. The model doesn't get a vote.

Now the cost, because there is one and it's measurable.

Zhi Rui Tam and colleagues tested exactly this for a paper at the EMNLP 2024 Industry Track, comparing model performance on free-form responses against the same tasks under format restrictions. They looked at both constrained decoding, the JSON mode implemented by mainstream providers, and softer format-restricting instructions asking for JSON, XML or YAML against a schema.

They found a significant decline in reasoning ability under format restrictions. And it scaled the way you'd fear: the stricter the constraint, the bigger the degradation.

Read that carefully, because it complicates the advice everyone gives. Machine enforcement buys you a guarantee about shape and charges you in thinking quality. If the task is "extract these five fields from this invoice," that trade is obviously worth it. If the task is "work out which of these three suppliers we should drop and explain why," you may have just made the model worse at the only part that mattered.

There's a clean way out of that tension, and it's the single most useful thing in this section.

Separate the thinking from the formatting. Don't make the model reason inside a straitjacket. Either run two calls, letting it think in free text first and then formatting that answer under a schema in a second pass, or use one schema whose first field is a free-text reasoning field and whose later fields hold the structured answer. Order matters, because the model fills fields in sequence and you want the unconstrained thinking to happen before the constrained output depends on it. The section on thinking models covers the related point about giving a model room to work.

The other thing worth being precise about is what a schema can and cannot hold.

• Schemas constrain shape, not content. A schema can guarantee you get valid JSON with a field called tone. It cannot guarantee the tone is right. This is the boundary people trip over.
• Enumerations are the exception worth knowing. If the acceptable values are a closed set, an enum makes anything outside it impossible. "Status must be one of pending, shipped, cancelled" is genuinely enforceable. "Status should be described professionally" is not.
• Absence of a field is a real constraint. A schema with no field for pricing cannot return pricing. That's a proper negative constraint, mechanically enforced, and it's often the cleanest way to express one.
• Most of what you actually want to ban isn't structural. Don't be salesy. Don't invent statistics. Don't give medical advice. No schema touches any of those. They're content constraints, and for those you're back to phrasing, verification and the checks in the section on testing whether the model followed your constraint.

One more thing that matters if you're not working in English, and it's a genuinely useful property rather than a caveat.

The enforcement here operates on token sequences and grammar, not on meaning. So a schema constrains structure the same way whether the model is writing Bahasa Indonesia, Thai, Vietnamese or Tagalog. Nearly every other technique in this guide degrades when you move away from English, as the section on other languages sets out. Machine enforcement mostly doesn't. If you're building something that has to produce reliable structured output across several Southeast Asian languages, that makes schemas disproportionately valuable, because they're one of the few guarantees that survives the language switch intact.

The content quality inside those fields still varies by language. The shape doesn't.

So the honest summary. Use machine enforcement when the requirement is structural, the task is extraction or classification rather than judgment, or the output feeds code that will break on a surprise. Keep the reasoning unconstrained and format afterwards when the task involves actual thinking. And don't reach for a schema to solve a tone problem, because it was never the right layer for that.

Does your constraint survive a long conversation?

Usually not, and this is the failure people misdiagnose most often. You write a constraint carefully, the model respects it for a few exchanges, and twenty turns later it's quietly doing the thing you banned. Then you assume the wording was wrong and rewrite it. The wording was fine. The problem is distance.

Two benchmarks put hard numbers on this.

The clearest comes from Philippe Laban, Hiroaki Hayashi, Yingbo Zhou and Jennifer Neville in LLMs Get Lost In Multi-Turn Conversation, published in 2025 and built on more than 200,000 simulated conversations across six generation tasks. Every top open and closed model they tested performed significantly worse in multi-turn conversations than single-turn, with an average drop of 39 percent. The breakdown matters more than the headline. They describe it as a minor loss in aptitude and a large increase in unreliability. Models make assumptions early, commit to them, and then overly rely on those early guesses. Their conclusion is worth memorising: when a model takes a wrong turn in a conversation, it gets lost and does not recover.

The second is Multi-IF, a benchmark of 4,501 conversations across eight languages, each three turns long, tested against 14 leading models. Instruction adherence fell with every additional turn. Even o1-preview, one of the strongest reasoners available at the time, dropped from 0.877 accuracy at the first turn to 0.707 by the third. Three turns. Not thirty. The researchers also found higher error rates in non-Latin scripts including Hindi, Russian and Chinese, so if you're working in Thai, Tamil or Chinese, assume the decay is steeper than the English numbers suggest.

Put those together and the practical picture is uncomfortable. A constraint is not a setting you flip once. It's closer to something that fades, and the fade starts earlier than most people expect.

What actually helps:

• Restate the constraint, do not just reference it. Saying "remember the rules from earlier" asks the model to retrieve something it may already have lost. Paste the rule again in full.
• Start a fresh conversation instead of correcting a drifting one. This is the counterintuitive one. Because models commit to early wrong turns and do not recover, a clean restart with a better prompt usually beats ten messages of correction.
• Put the constraint last, right before the task. Recency helps. A rule at the top of a long thread is competing with everything that came after it.
• Front-load the requirements. The same research found that dripping information out across turns is what breaks things. If you know all your constraints up front, say them all up front.
• For anything repeated, use a standing brief. A fixed block you paste each time beats relying on conversational memory. Our guide to briefing AI agents for multi-step work covers how to structure one.

And if you take one thing from this section, make it the restart rule. Most people treat a long thread as an investment worth protecting. The research suggests the opposite. Once a conversation has gone off, the cheapest fix is usually to abandon it.

Do your constraints hold when the AI is taking actions?

Much less well than in chat, and this is the setting where a failed constraint actually costs you something. A chatbot ignoring "don't use bullet points" wastes a minute. An agent ignoring "don't touch the production folder" is a different kind of afternoon.

Agents make the problem harder for a structural reason. In a chat you have one instruction source: you. An agent is reading its system configuration, your request, the output of every tool it calls, the contents of files it opens, and whatever a webpage said. Each of those is a voice, and some of them contradict each other.

Somebody built a benchmark for exactly this. Jingyu Zhang, Tianjian Li, William Jurayj, Hongyuan Zhan, Benjamin Van Durme and Daniel Khashabi published Many-Tier Instruction Hierarchy in LLM Agents in 2026. Their point is that the tidy system-then-user picture is too small for real agents, where authority can run to a dozen levels rather than two or three.

They built ManyIH-Bench out of 853 agentic tasks across 46 real-world agents, 427 of them coding tasks and 426 instruction-following, with hierarchies reaching up to 12 distinct privilege levels. Then they ran frontier models at it.

Accuracy came in around 40 percent.

Take that number carefully, because it's a deliberately hard benchmark built around conflicts rather than a measure of everyday agent reliability. But the direction is unambiguous. When several instruction sources disagree about what's allowed, current models resolve it correctly well under half the time. A prohibition that held fine in conversation is a much weaker thing once the model is reading from five places at once.

What that means in practice:

• Don't rely on a sentence for anything expensive. If the action is irreversible, the constraint belongs in permissions, not in prose. Take away the capability rather than asking politely.
• Fewer sources beats better wording. Every extra tool, file and fetched page is another thing that can argue with your rule. Narrow what the agent can see.
• Expect content to argue back. An agent reading the open web is reading instructions written by other people, and those sit in the same context as yours.
• Check the actions, not the transcript. An agent will often say it respected a constraint. What it did is the only record worth reading.

The through line with everything above holds here, just with more at stake. A negative constraint is a preference expressed to a system that weighs preferences. If it has to be true, it needs enforcing somewhere the model doesn't get a vote.

Do thinking models follow constraints better?

No. They tend to follow them worse, and it's one of the more counterintuitive findings in this whole area.

The assumption is a fair one. A model that thinks before it answers ought to catch the rule it's about to break. But when researchers went and measured it, the opposite kept turning up.

Xiaomin Li and colleagues tested this head-on in When Thinking Fails: The Pitfalls of Reasoning for Instruction-Following in LLMs, posted in 2025. They ran 15 models across two benchmarks: IFEval, which uses simple rule-checkable constraints, and ComplexBench, which uses compositional ones. Switching chain-of-thought reasoning on degraded instruction-following accuracy consistently across their tests.

The failure mode is specific, and it'll sound familiar by now. Models with reasoning switched on overlooked simple constraints and added content nobody asked for. The researchers built a metric they call constraint attention to show what's going on underneath, and it points at something clear. Reasoning pulls the model's focus away from the tokens carrying your instruction and towards the tokens carrying the problem.

A second team hit the same tension from another direction. Tingchen Fu, Jiawei Gu, Yafu Li, Xiaoye Qu and Yu Cheng built a benchmark called MathIF specifically to test instruction-following during mathematical reasoning, published as Scaling Reasoning, Losing Control. Their finding is that models with stronger reasoning ability tend to show weaker instruction adherence, and it gets worse as the generated output runs longer. Simple interventions restored some obedience, but doing so cost reasoning performance.

Now put that next to the section above. Long conversations erode constraints because the gap between your rule and the model's answer keeps widening. Long reasoning chains do exactly the same thing inside a single turn. It's one mechanism operating at two scales, which is why both show up in the research as length problems rather than comprehension problems.

So what do you do about it? Three things.

Don't reach for thinking mode to fix a constraint the model keeps breaking. That's the intuitive move, and the evidence says it backfires. Try the same prompt with reasoning off and compare the two.

Match the mode to the job. Reasoning earns its keep on genuinely hard problems: maths, multi-step analysis, code that has to be correct. For formatting and style rules, plain generation follows your instructions more reliably.

And split the work when you need both. Let the reasoning model solve the problem, then run a second cheap pass whose only job is reshaping that answer to your rules. The Li team's most effective mitigation was essentially this, deciding per task whether reasoning should be on at all rather than leaving it running by default.

Can the model check its own negative constraints?

No. And this closes off the shortcut you were probably about to take, because asking a model "did you follow my rule?" is asking it to do the exact thing negation research says it's worst at.

Jihyun Janice Ahn and Wenpeng Yin named the mechanism in a 2025 paper on prompt-reverse inconsistency, or PRIN. The setup is almost insultingly simple. Give a model a question plus some candidate answers, then ask it two things: which are correct, and which are incorrect. Logically those two answers have to be complements of each other. In practice they contradict each other constantly.

They ran six models across three datasets, MATH with 5,000 problems, MathQA with 2,985 and EquInfer with 1,049. Mean PRIN rates came out like this:

• GPT-4: 39.98 percent, the best of the six by a clear margin
• Qwen2.5-72B: 60.18 percent
• Mixtral-8x22B: 68.73 percent
• Llama-3.3-70B: 72.92 percent
• Falcon-40B: 74.63 percent
• Llama-3-8B: 79.55 percent

So even the strongest model in the set contradicted itself on roughly four items in ten, purely from flipping the question from positive to negative. Nothing else changed.

What they ruled out matters as much as the headline number. PRIN stayed stable when the prompts were paraphrased, so this isn't a wording problem you can rephrase your way out of. And across five repeated runs the standard deviations sat typically under 1 percent, so it isn't sampling randomness either. It's systematic behaviour, not noise.

The link back to negation is measured rather than assumed, which is the part I like. Performance on CONDAQA, a negation-focused dataset, correlated with mean PRIN scores at a Pearson r of 0.67. The models that handle negation badly are the same ones that contradict themselves when you invert the question.

Worth being straight about the scope, though. Those three datasets are maths and equation reasoning, not "did you use bullet points." Nobody has run this specific test on formatting compliance. What transfers is the mechanism, not the exact percentage, and the mechanism is the one that bites you here.

The authors' own concern is that PRIN undermines the credibility of LLM-as-a-judge. Your version is narrower and more practical: the model is not a trustworthy auditor of whether it broke your rule, because "did you use any bullet points?" is precisely the reverse-framed question the paper is about.

Three things follow from that:

• Don't ask for confirmation of compliance. "Did you follow the constraint?" gets you a confident yes that carries almost no information.
• If you use a model as a checker, ask it to describe rather than judge. "List every formatting element you used in that output" is a positive request. You compare the list against your rule yourself. That keeps the negation on your side of the fence.
• Raise your scepticism for smaller open-weight models. Every open model tested came in above 60 percent, so self-audit from that tier is close to worthless.

Which leaves the question of how you actually verify a constraint. That's the next section, and the short version is that you do it yourself.

How do you tell if the model actually followed your constraint?

This article keeps saying that a declined constraint doesn't announce itself. So here's the obvious follow-up nobody answers: how would you know?

The honest answer is that you have to test it, and almost nobody does. People write a prompt, run it once, read something reasonable, and file the prompt under working. One clean run tells you close to nothing when the failure mode is intermittent.

Run it ten times, not once. Same prompt, same constraint, ten fresh conversations. Count how many outputs actually respect the rule. Eight out of ten isn't a rule, it's a preference with a 20 percent failure rate, and now at least you know the number. Most prompts people are confident about have never been through this.

Test both polarities. This is the cheap version of what Elkins and Chun did. Write your instruction as a prohibition, then write the same requirement as a positive instruction, and run both sets. If the outputs differ in quality or compliance, you've just measured your own prompt's negation sensitivity on the task you actually care about, which is worth more than any general benchmark.

Check mechanically where you can. If the constraint is "no bullet points," a search for a bullet character across ten outputs takes seconds and doesn't get bored or generous the way re-reading does. Anything checkable in code should be checked in code. Save your attention for the constraints that need judgment.

Their Negation Sensitivity Index is a useful frame for what to do with the number once you have it. The paper's audit-trigger bands run: below 0.20, autonomous operation is fine; 0.20 to 0.49, human review on high-risk domains; 0.50 and above, human confirmation on every evaluative output. You won't be computing a formal NSI on your own prompts, but the shape of the decision transfers. The more your measured compliance wobbles, the further up the enforcement ladder from the previous section your constraint needs to move.

One thing this testing reliably reveals, and it's worth being ready for. Prompts often fail on the specific inputs you didn't think to try: the unusually long one, the one in another language, the one where the user asks for exactly the thing you banned. Compliance measured on your happy path is not compliance.

Does negative prompting work in your own language?

Worse, and by a wider margin than most people would guess. Everything above was measured in English. If you write your prompts in Bahasa, Thai, Tagalog, Mandarin or Tamil, the negation problem this article has been describing gets sharply worse, and almost nobody mentions it.

The clearest measurement so far comes from the image side, which is convenient, because that's where negative prompting supposedly works. Moraitaki, Pan, Pulling, Flusche, Alhamoud and Ghassemi took NegBench, an English negation benchmark built from COCO image-caption sets, and extended it to seven languages for an arXiv preprint posted in April 2026. Each language got 3,030 samples, with translations checked by native speakers, in a four-way multiple choice format.

Here's how CLIP scored across the set:

• English: 39.3 percent
• Spanish: 33.6 percent
• Mandarin Chinese: 25.5 percent
• Russian: 20.4 percent
• Greek: 18.0 percent
• Arabic: 15.7 percent
• Tagalog: 11.8 percent

Now the detail that turns those into something alarming. It's four-way multiple choice, so guessing at random scores 25 percent. Arabic, Greek and Tagalog all land below chance. Mandarin sits right on it. A model scoring under chance isn't just failing to understand the negation, it's being actively pulled toward the wrong answer by the words in the caption, which is the affirmation bias this article described earlier showing up in a much starker form.

The spread between best and worst was 27.5 percentage points. And multilingual training doesn't rescue it: MultiCLIP was the most consistent model in the set, with a standard deviation of just 1.3 percent across languages, but its mean accuracy was 41.2 percent. Even and fair, and still not good anywhere.

Two honest caveats. This is a preprint, so it hasn't cleared peer review. And it tests CLIP-family vision-language models, not the chatbots most of this article is about, so you can't read the exact numbers across to ChatGPT or Claude. What it does show is that negation handling degrades along the same axis as everything else in these systems, which is distance from English training data. There's no reason to expect chat models to be exempt from a pattern this consistent.

So, practically. If you're working in a language other than English and you need a hard constraint, write that one line in English even when the rest of the prompt is in your own language. Models handle mixed-language prompts fine, and the constraint is the part you can least afford to have misread. Better still, use the positive framing this article has been recommending throughout, since saying what you want sidesteps the negation machinery altogether. That advice was already the stronger option in English. In Tagalog it stops being optional.

When do negative prompts genuinely work?

Three situations where they earn their place:

• Image generation. Use the negative field properly and it works as advertised, because it isn't text interpretation at all. This is the original home of the technique.
• Concrete, checkable exclusions. "Do not include any text in the output" is a binary the model can verify against its own draft. "Do not be boring" is not. The more objectively checkable the prohibition, the better the odds.
• Paired with the positive. "Write in paragraphs, not bullet points" works better than either half alone. The positive instruction does the steering, the negative closes off the most likely wrong turn.

Position matters too. A constraint buried in paragraph two of a long prompt competes with everything after it. Putting your hard requirements at the end, right before the model starts generating, generally holds better. If you're structuring longer prompts, our prompt engineering basics covers ordering in more detail.

Which negative prompting mistakes should you avoid?

The common ones, roughly in order of how much damage they do:

• Stacking negatives. "Don't fail to avoid being unclear" is a real thing people write. Elkins and Chun found compound negation drove open-source endorsement to 100 percent, and even US commercial models more than doubled, from 25 to 57 percent. Every extra negative makes it worse. One at most.
• Listing everything you hate. A prompt with eight "don'ts" has just filled the model's context with eight vivid descriptions of unwanted output. Naming a thing makes it more available, not less.
• Assuming the bigger model will handle it. The inverse scaling result says otherwise. Upgrading your model is not a fix for negation.
• Using negation for anything safety-critical. If a constraint genuinely must hold, don't rely on a "do not" in a prompt. Constrain the shape with structured output or a JSON schema, then validate the response and retry on failure.
• Forgetting to say what you want. The single most common one. Prohibition without direction leaves the model to guess, and it usually guesses toward its defaults.

What do people ask about negative prompting?

What is negative prompting?

Negative prompting is telling an AI what you do not want. In image generators it is a real, separate input field, so Midjourney's --no parameter or Stable Diffusion's negative prompt box steers the image away from what you list. In chatbots there is no such field, so a negative instruction is just more words in the prompt, and models handle those words poorly.

Do negative prompts work on ChatGPT?

Less reliably than most people assume. Joel Jang, Seonghyeon Ye and Minjoon Seo tested OPT and GPT-3 from 125 million to 175 billion parameters and found an inverse scaling law on negated prompts: bigger models got worse, not better. Saying do not do X is one of the weakest ways to constrain a chatbot.

Why do AI models ignore the word don't?

Because negation is a weak signal against a strong one. Naming the thing you want to avoid puts it in context where it influences what comes next, and the single negating word has to override all of it. Elkins and Chun measured it: small open-weight models in the 1 to 4 billion parameter range endorsed an action 24 percent of the time under plain framing, but up to 100 percent once the framing was negated, a swing of as much as 76 percentage points. Bigger commercial models shift far less than that, but they still shift.

How do negative prompts work in Midjourney?

Midjourney's --no parameter is a genuine separate conditioning input, not just text appended to your prompt. Adding --no text, watermark pushes the generation away from those features mathematically rather than asking the model politely. This is why negative prompting has a real reputation in image work and a much shakier one in chat.

Should you ever use do not in a prompt?

Sometimes, but always paired with a positive instruction. Do not write in bullet points on its own leaves the model guessing. Write in flowing paragraphs of three to four sentences tells it exactly what to produce. If you need a hard prohibition, state it once, state it late in the prompt, and say what to do instead.

Sources: Truong T.H., Baldwin T., Verspoor K., Cohn T., "Language Models Are Not Naysayers: An Analysis of Language Models on Negation Benchmarks," Proceedings of *SEM 2023, ACL Anthology. Jang J., Ye S., Seo M., "Can Large Language Models Truly Understand Prompts? A Case Study with Negated Prompts," arXiv:2209.12711 preprint, 2022. Elkins K., Chun J., "Framing Instability in LLM Ethical Stance: Auditing Negation Sensitivity in Moral Dilemmas," Kenyon College, arXiv:2601.21433 preprint, 2026 (v2 revised July 2026); the authors note their binary scoring proxy over-counts endorsement by 38.2 percent against human coding, and the largest swings are on small open-weight models of 1 to 4 billion parameters. Cheng Q., "Via Negativa for AI Alignment: Why Negative Constraints Are Structurally Superior to Positive Preferences," arXiv:2603.16417 preprint, March 2026, which concerns training objectives rather than inference-time prompting. Moraitaki C., Pan S., Pulling S., Flusche G., Alhamoud K., Ghassemi M., "Disparities in Negation Understanding Across Languages in Vision-Language Models," arXiv:2604.18942 preprint, April 2026; tests CLIP-family vision-language models rather than chat models. Wallace E., Xiao K., Leike R., Weng L., Heidecke J., Beutel A., "The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions," arXiv:2404.13208 preprint, 2024. Zhang J., Li T., Jurayj W., Zhan H., Van Durme B., Khashabi D., "Many-Tier Instruction Hierarchy in LLM Agents," arXiv:2604.09443 preprint, 2026. Anthropic, "Best practices for prompt engineering for 2026," Claude documentation, accessed August 2026. All linked above.