Prompt AI With an Example of What You Don't Want
Show the model a bad example and it often copies it. Labelling, pairing and ordering are what turn a negative example into a useful one.
Describing what you do not want rarely lands. Showing it works far better, and it also has a specific way of going wrong: paste in a bad example on its own and the model will often produce something closer to it, not further from it. If you want to prompt AI with an example of what you don't want and actually get a different result, the example has to be labelled, paired, and positioned. All three matter, and the positioning one surprises people.
Why a lone bad example backfires
Anything in the prompt is context, and context is what the model imitates. It does not have a separate mental bin for things it saw and should avoid. A three-paragraph sample of prose you hate contributes three paragraphs of style signal, and the single line telling it not to do that has to outweigh all of it.
Usually it does not. The sample is long, concrete, and stylistically vivid; the prohibition is short and abstract. Length and specificity win. You end up having demonstrated the failure mode in high fidelity and objected to it in passing, which is roughly the opposite of the intent.
The effect is strongest on style and structure, weakest on factual content. Pasting a wrong fact and saying it is wrong works reasonably well. Pasting prose you dislike and saying you dislike it often produces more of that prose.
How to prompt AI with an example of what you don't want
Fixing this is mechanical.
Label before, not after. Put the tag immediately above the example, never below it. The model reads in order, and text that arrives unlabelled is processed as material before any later correction applies to it.
Always pair it. A bad example alone gives a direction to move away from with no destination. A bad and a good example together define an axis, which is the thing the model can actually act on.
Put the good one last. Whatever sits closest to the instruction has the most influence on what comes next. End on the target, not on the failure.
That third rule is the one people get wrong most often, because the natural way to write it is here is the problem, here is the fix, now go. Reverse it. Show the problem, show the fix, and make the fix the last thing before your instruction.
What a contrastive pair looks like
Concretely, for a tone problem:
Rewrite the release note below.
AVOID, this is the failure mode:
"We're thrilled to announce an exciting new capability that empowers teams
to do more of what they love."
TARGET, match this:
"Scheduled exports now run hourly. Previously they ran once a day at 02:00 UTC."
Release note to rewrite: <text>Two short examples do more than a paragraph of adjectives, and the contrast carries information neither one carries alone. The reader can see that the axis is not just formal versus casual, it is concrete-and-specific versus enthusiastic-and-vague. No list of style rules conveys that as efficiently.
When to reach for it
Negative examples are a targeted tool, not a default. They earn their tokens in three situations:
The model keeps making the same mistake and describing the mistake has not worked. You have evidence that the abstract instruction is not landing.
The difference you care about is hard to name. Most tone and register problems are like this. You know it when you see it and cannot write the rule.
You have a real artefact of the failure. An actual bad output you got is a better example than one you invent, because invented bad examples tend to be cartoonish and the model avoids the cartoon rather than the real thing.
When the rule is easy to state, just state it. "No bullet points" beats a demonstration of bullet points every time, costs nothing, and cannot anchor. Save the contrastive pair for the cases where you genuinely cannot articulate the difference, and check first that the problem is not simply a badly specified prompt, which no amount of exemplification will rescue. If you are reaching for this repeatedly against the same target, that is a sign the constraint belongs in a style guide the model carries between prompts rather than in every request. The broader toolkit sits in prompt engineering, and vendor guidance on using examples is worth reading before you lean on this one heavily.
Common mistakes
Mistake | What happens | Fix |
|---|---|---|
Bad example, no good one | Model drifts without a destination | Always pair |
Label after the example | Unlabelled text already absorbed | Label above |
Bad example placed last | It anchors hardest | End on the target |
Bad example much longer | Length outweighs the correction | Match the lengths |
Invented cartoon failure | Avoids the cartoon, not your problem | Use a real bad output |
Matching the lengths is underrated. If your bad example runs two hundred words and your good one runs twenty, you have weighted the prompt ten to one toward the thing you are trying to avoid, whatever the labels say.
FAQ
Does telling AI what not to do actually work?
Stating a rule works well when the rule is easy to name. Showing an example of the failure works well only when it is labelled and paired with a good example. A bad example on its own frequently makes the output worse, because everything in the prompt is material to imitate.
How many negative examples should I include?
One, paired with one positive. More than a single contrasting pair dilutes the signal and spends context on failure modes, and multiple bad examples increase the anchoring risk that makes the technique backfire in the first place.
Why does the model copy the example I said to avoid?
Because it has no separate category for text it should not imitate. Your example contributes style signal in proportion to its length and vividness, while the prohibition is short and abstract. Pairing and ordering are what rebalance that.
Should negative examples go in the system prompt?
Only for constraints that apply to every request. A contrastive pair that is specific to one task belongs in that task's prompt; putting it in the system prompt applies the anchoring risk to everything you do afterwards.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
