If you have tried negative prompting, you have probably had the frustrating experience of telling a model not to do something and watching it do exactly that. The instinct is to write the prohibition more forcefully, in capital letters, repeated three times. That rarely helps and often makes things worse. The reason is that negative prompting works differently than people expect, and once you understand the few principles that govern it, you can get a reliable first result quickly without the trial-and-error flailing.
This piece is the fast path. It assumes you have access to a model and a behavior you want to suppress, and nothing more. It walks through the minimum prerequisites, a concrete first example, how to confirm the constraint actually worked, and the two or three mistakes that trip up almost everyone at the start. By the end you should have one negative constraint you can prove is changing outputs, which is a far better foundation than a dozen you merely hope are working.
What You Need First
A Specific, Observable Behavior
The single biggest predictor of success is choosing a behavior you can actually see in the output. "Be less annoying" is unworkable because you cannot point to it. "Do not start responses with a greeting" is workable because you can look at the first words and know instantly whether the constraint held. Start with something concrete and observable.
A Few Test Cases
You need three to five example inputs where the unwanted behavior tends to appear. Without them you are judging success on a single lucky output, which proves nothing. These cases are your evidence, and they take five minutes to assemble.
Try the Positive Version First
The Counterintuitive First Move
Before writing a single "do not," try describing what you want instead. If the problem is the model greeting users, the positive version is "begin every response with the answer." Models follow positive targets more reliably than they avoid negative regions, so this often solves the problem outright with no negative needed. This is the central insight from Trade-offs, Options, and How to Decide, and it belongs at the very start of your practice.
When to Reach for the Negative
If no clean positive framing exists, or if the behavior is a genuine prohibition you must block, then write the negative. Keep it to one sentence, stated plainly: "Do not include any pricing figures." Plain beats forceful β capital letters and repetition do not increase adherence and waste tokens.
Confirm It Actually Worked
This is the step nearly everyone skips, and skipping it is why people think negative prompting is unreliable.
- Run your three to five test inputs without the constraint and note how often the unwanted behavior appears.
- Run the same inputs with the constraint and count again.
- Compare. If the behavior dropped, the constraint works. If it did not, the constraint is not doing its job and you need to change approach, not volume.
This paired check is a miniature version of the discipline in How to Measure Negative Prompting: Metrics That Matter, and it turns guessing into knowing.
Where to Place the Constraint
A small detail with outsized impact is where in the prompt the constraint sits. A prohibition buried in the middle of a long instruction block gets less attention than one stated cleanly near the end, close to where the model begins generating. As a beginner you do not need a theory of placement, but you should know that if a constraint is being ignored, moving it to a more prominent position is worth trying before you conclude the constraint itself is wrong. Position is a free variable that costs nothing to adjust.
The Beginner Traps
Naming the Forbidden Thing
Telling a model "never mention the word jackpot" puts the word jackpot directly in its context, and weaker models sometimes echo it. When you can, describe the category positively instead of naming the forbidden item. If you must name it, test specifically for whether the model now repeats it.
Piling On Prohibitions
The day-one impulse is to write ten rules at once. Resist it. Add one constraint, prove it works, then add the next. A stack of unverified prohibitions is exactly the mess that makes prompts unmaintainable. The 7 Common Mistakes with Negative Prompting (and How to Avoid Them) piece catalogs the rest of these.
Assuming It Stays Working
A constraint that works today can stop working after a model update. You do not need to obsess over this at the start, but know that your test cases are reusable β re-run them whenever the model changes. The five minutes you spent assembling test inputs keeps paying off every time the ground shifts beneath you.
Judging on One Output
The final beginner trap is declaring victory after a single good output. Models are probabilistic; one clean response proves nothing because the next input might fail. This is precisely why the paired comparison across several inputs matters β it replaces a lucky anecdote with evidence. Get into the habit early of never trusting a constraint you have seen succeed only once.
A Complete First Pass
Put it together: pick an observable behavior, write three to five test inputs, try the positive framing, fall back to a single plain negative if needed, run the paired comparison, and confirm the violation rate dropped. That entire loop takes well under an hour and leaves you with a constraint you can defend. From there, the path forward is to add constraints one at a time with the same discipline, and to read Best Practices That Actually Work once you are ready to scale beyond a single prompt.
A Concrete First Example
To make the loop tangible, here is a complete first pass on a real behavior: a summarization assistant that keeps adding its own opinions to summaries.
Pick and Frame
The behavior is observable β you can read a summary and see editorializing like "this is a smart approach." Your three test inputs are three articles that tend to provoke commentary. You try the positive framing first: "Summarize only what the text states, attributing every claim to the source." You run it.
Measure
Without any constraint, all three summaries contained opinion. With the positive specification, two of three were clean and one still slipped. The positive framing helped substantially but did not fully solve it, so you add a single plain negative as a backstop: "Do not add evaluation, praise, or criticism of the content." You re-run the three inputs and all three come back clean.
Confirm and Stop
You now have evidence: editorializing went from three of three to zero of three across your test set. That is a defensible first constraint. The temptation is to keep going and add five more rules about tone, length, and structure right now. Resist it β add the next constraint only when you have a behavior to fix and the bandwidth to measure it. This single-constraint discipline is what the Best Practices That Actually Work guide builds on, and the Step-by-Step Approach to Negative Prompting walks the same loop in more detail.
Frequently Asked Questions
Why does the model ignore my negative instruction?
Usually one of three reasons: the behavior is not observable enough to enforce, the instruction is buried among too many other rules, or a positive framing would work better. Start by making the behavior concrete and trying the positive version.
Do capital letters or repetition make a constraint stronger?
No. They do not measurably improve adherence and they waste tokens. A single, plainly stated constraint outperforms a shouted or repeated one.
Should I always try the positive framing first?
Yes, as a default. Models follow positive targets more reliably than they avoid negative regions, so a positive specification frequently solves the problem without any negative at all.
How do I know my first constraint actually worked?
Run your test inputs with and without the constraint and compare how often the unwanted behavior appears. A drop proves it works; no change means you need a different approach, not a louder one.
Key Takeaways
- Pick a specific, observable behavior and assemble three to five test inputs before writing anything.
- Try the positive framing first; it often solves the problem without any negative instruction.
- If you need a negative, write one plain sentence β capital letters and repetition do not help.
- Confirm the constraint worked by comparing the unwanted behavior's frequency with and without it.
- Add constraints one at a time and avoid naming forbidden concepts, which can make the model repeat them.