It followed your example instead of your instruction

You wrote it plainly. Keep responses under 100 words. Then, because every prompting guide says to give examples, you pasted one underneath — a reply you had been pleased with, copied in whole. The next answer came back at four hundred words, in your example's voice, with your example's three-paragraph shape and its little closing summary. Your instruction was not misunderstood. It lost.

Nothing warned you. There is no line in the output saying "two of your inputs disagreed and I picked the second one". The model read a description and a demonstration, they contradicted each other on a property you never thought to check, and the demonstration won. This failure is almost never diagnosed, because the thing that overrode your rule is the thing you added to make the rule work.

A description is a claim. An example is a completed instance

Every instruction you write describes an output that does not exist yet. "Under 100 words" is a property. "Formal tone" is a property. The model has to work out, from the description, what a satisfying instance would look like.

An example skips that step entirely. It is a finished instance of the task, already correct by your own assertion. OpenAI describes what the model does with one in a line: "The model can extrapolate from these examples how it should respond for other prompts." Google says the same about Gemini — the model identifies patterns and relationships from the examples and applies them when generating.

Then Google says the part that should stop you: "In fact, you can remove instructions from your prompt if your examples are clear enough in showing the task at hand."

Read that backwards. If a good set of examples can replace your instructions, a bad set can replace them too — silently, and without your consent. That sentence is published as an argument for examples. It is equally an argument for auditing them.

What an example shows is all of itself

Here is the part no guide states outright. You added the example to demonstrate one property. The model has no way to know which one.

An example is a single artefact, and every observable thing about it is on display at once: its length, its register, its formatting, its level of detail, the depth of its explanation, the domain it happens to be about, and any incidental content that came along for the ride. All of it is being shown as correct, because you presented it as correct.

Anthropic's prompting guidance names the failure while recommending the technique — examples should be diverse enough to "Cover edge cases and vary enough that Claude doesn't pick up unintended patterns." Unintended patterns is this article compressed into two words. The same page notes that even the styling of your prose leaks: removing markdown from a prompt reduces markdown in the reply. If the formatting of instructions leaks, a demonstration does not leak, it pours.

The fingerprint: the output matches your example on a dimension you never mentioned anywhere — its length, its headings, its tone — while missing something you did mention.

Override one: the rule moved and the example did not

This is the standard end-state of any prompt that has been maintained. Someone tightens a rule. Nobody looks below it.

Six months ago the rule said "aim for a paragraph or two", and the example under it is two paragraphs. Last month the rule became "one sentence, no preamble". The example is still two paragraphs, still being read as a certified-correct output. You now have a prompt that describes the new policy and demonstrates the old one.

The fingerprint: the output obeys a version of your own policy that you can find in your version history. It is not random and not wrong-in-a-new-way. It is precisely, consistently out of date — which is what hides it, because it reads as the model having a stubborn opinion rather than as you handing it a stale instruction.

Override two: you demonstrated more than you meant

You wanted the shape. The model took the content.

The distinction between "this is the shape I want" and "this is the content I want" exists only in your head, and you did not write it down anywhere. Both readings explain the artefact you supplied equally well.

So the placeholder company in your sample email starts appearing in real emails. The example's user_id field survives into a schema that no longer has one. The one worked case you happened to choose becomes the case the model steers back towards. Google warns about the general form: include too many examples and the model may start to overfit its responses to them.

The fingerprint: specifics from your example turn up in output where they make no sense — a name, a domain, a field, a topic that was only ever incidental scaffolding.

Override three: two examples that disagree

Add a second example on a different day and you have created a rule with two conflicting definitions, and nothing anywhere that will report the conflict. Examples that disagree are worse than no examples, because the model does not stop and ask which one governs. It picks. OpenAI's GPT-5.6 prompting guidance is blunt about the cost: "GPT-5-class models follow prompt contracts closely, so conflicting rules can create more instability than missing detail." Anthropic says the equivalent about layered instruction files — if two rules contradict, one may be chosen arbitrarily.

Instability is the word to hold. A contradiction does not produce a consistent compromise; it produces a coin flip that lands differently across runs, which you will misread as ordinary sampling variance rather than a defect in your prompt.

The fingerprint: the behaviour alternates between two states, each internally coherent, neither one drifting. Real randomness looks messy. A contradiction looks like two tidy answers taking turns.

The contradiction test

One check finds all three, it takes ninety seconds, and no tool will do it for you.

Cover your prose. Read only the examples. Ask: if these were the only instructions I had been given, what would I conclude the task is?

Write that conclusion down as one sentence, in the voice of someone who has never seen your rules. Then uncover the prose and compare, property by property: length, tone, format, depth, structure, subject matter. Every mismatch is a live disagreement, already in your prompt, already being resolved without you.

Do it per property rather than as an overall impression. "The example broadly matches the rules" is the judgement that lets a stale one survive for a year — because it does broadly match. The disagreement is always on one axis, and usually the axis you would not have thought to look at.

A rules file is where a stale example lives longest

Everything above gets worse the further the example sits from the person reading the output. A prompt you typed this morning is still in view. A rules file is not.

Cursor project rules and CLAUDE.md are both loaded into context automatically at the start of a session, both version-controlled, and both edited by several people across many months. Every property that makes them useful also makes them the perfect host for an example that stopped being true. Cursor's own guidance says to point at real files instead: "Reference files instead of copying their contents—this keeps rules short and prevents them from becoming stale as code changes". Anthropic's advice for CLAUDE.md is to review the files periodically and remove instructions that have gone out of date. Both are documented practices because staleness is the expected outcome, not an unlucky one.

Keep this separate from the other rules-file failure. If your rules never seem to apply at all, that is a matching and loading problem with its own diagnosis. This one is the opposite: the file loads perfectly and teaches the wrong thing, consistently, on every request.

The fingerprint: every developer on the team gets the same wrong house style, and it is a style the codebase abandoned. Nobody suspects the rules file, because the rules file is obviously being read.

Why "here is a bad answer, do not do this" produces the bad answer

The counter-example is the trap that catches careful people, because it feels like extra rigour.

You paste the output you hated and label it, in prose, as the thing to avoid. But you have just added a complete, concrete, fully specified instance of the task to the prompt — and prose labelling is exactly the weaker signal this whole page is about. Anthropic states the preference directly for Claude Sonnet 5: "Positive examples showing how Claude can communicate with the appropriate level of concision tend to be more effective than negative examples or instructions that tell the model what not to do." Its general prompting guidance says the same thing: tell the model what to do rather than what not to do.

So show the corrected version. If you genuinely need the failure on the page — because it is subtle and you want it recognised — label it structurally rather than in a sentence. Anthropic recommends wrapping examples in <example> tags so they can be told apart from instructions; a <bad_example> tag carries its label inside the artefact, where a paragraph three lines above does not. Which layer that label belongs in — your message, a system prompt, a project file — is a separate decision.

Make the example minimal, then vary everything you did not mean

Two habits fix most of this, and they are both about reducing what the example accidentally asserts.

Make it minimal. Strip the example to the smallest artefact that still carries the property you are demonstrating. If you are showing structure, the content should be obvious filler. If you are showing tone, the subject should be trivial. Every detail left in is a claim you are making without meaning to.

Then vary the rest. Across a set of examples, hold constant only the property you intend to teach, and deliberately vary everything else — lengths, subjects, domains, levels of complexity. This is what Anthropic's advice to make examples diverse is actually for: variation is how you tell the model which single property was the point. Anthropic suggests three to five examples as a working range. (Checked 23 August 2026 — treat any such figure as a number that moves.)

And delete on a schedule. Every time you change a rule, look immediately below it and check whether the demonstration still agrees. OpenAI's guidance for slimming a prompt is to trim examples that do not change behaviour and keep only those that "encode a product requirement or correct a measured gap" — an example that survives because nobody deleted it meets neither test.

When to write no examples at all

Zero-shot is an underrated default, and the cases where it wins are identifiable in advance.

Use it when the task is one the model has plainly seen a million times — summarise, translate, extract, reformat — because your example adds no information about the task and every one of its incidental properties as noise. Use it when you cannot make the example minimal, because a large example is a large pile of unintended assertions. Use it when what you want is a constraint rather than a pattern: "under 100 words" is checkable prose, and a demonstration only muddies it.

And use it with reasoning models, which frequently need no examples at all and can be actively confused by a set that disagrees with the instructions — that argument belongs to the reasoning-model decision and is not re-run here.

OpenAI reports that leaner system prompts — fewer repeated instructions and examples — improved internal coding-agent eval scores by roughly 10–15% while cutting tokens substantially, and says to validate that on your own workload rather than take the range on faith. (Checked 23 August 2026.) Google's guidance points the other way and recommends always including few-shot examples. Both are honest, and the reconciliation is the thesis of this page: examples are a very strong signal, and strong is what makes a wrong one expensive.

The decision list

When output disagrees with an instruction and you cannot see why:

1. Look for a demonstration before you rewrite the description. Rephrasing a rule that an example is overriding produces a better-worded rule that still loses.
2. Run the contradiction test. Cover the prose, read only the examples, write down what task they describe. Compare property by property, not as an overall impression.
3. Date the example against the rule. If the rule was edited more recently than the example beneath it, assume they disagree until you have checked.
4. Ask what else the example is asserting. Length, tone, format, depth, domain, incidental content — you chose one of those on purpose and shipped the rest by accident.
5. Check whether two examples conflict. Behaviour that alternates cleanly between two coherent states is a contradiction, not variance.
6. Convert every negative example into a positive one. If you must keep the failure, label it structurally, inside the artefact, not in a sentence above it.
7. Cut the example and re-run. The fastest test of whether an example is helping is deleting it. If the output improves, it was never teaching what you thought.

This generalises past prompts entirely. It is true of the fixture your test suite copied from a bug report, of the seed row that taught your team the wrong column convention, and of the one file everybody clones when starting a new service. Wherever anything learns from a completed instance rather than a stated rule, the instance wins — and the instance is the thing nobody updates.