Getting Real Work out of a ModelLesson 24 of 72

Contents

Getting Real Work out of a Model

Lesson 24 of 72. Sign in to keep your place.

Module 3 · Teaching by example

Negative examples, and when they backfire

8 min read

The obvious idea, and its problem

If showing good output works, showing bad output should work too. Sometimes it does. Often it does something you did not want, and the mechanism is the one from the negative-instructions lesson: whatever you put in the context is in the context.

Paste three examples of the flabby corporate writing you hate, labelled “do not write like this”, and you have put three paragraphs of flabby corporate writing in front of the model immediately before asking it to write. The label helps. It does not fully counteract the demonstration.

The strongest form of this failure is with format. Show a malformed JSON example as a warning and you meaningfully raise the chance of getting malformed JSON, because the malformed structure is now the most recent structure in the prompt.

When negative examples do work

Three conditions, and they need to hold together.

The bad and good versions are paired. Never show a bad example alone. Show it next to its correction, so the transformation is what is demonstrated, not the flaw.

Text
Weak:  "We are pleased to announce the launch of our
        innovative new solution."
Better: "Our new invoicing tool is live from Monday."
Why:   name the thing, name the date, drop the announcement framing.

The good version comes last. Recency works for you here. End on what you want.

The flaw is specific and namable. “Too corporate” is not a flaw a model can avoid. “Opens with an announcement instead of the news” is.

Under those three conditions, a before-and-after pair is one of the most efficient teaching devices you have, because it shows both the error and the repair in the space of one example.

The stronger alternative for most cases

Rather than showing bad output, name the specific things to avoid as a checkable list, and show only good output.

Do not use these words: leverage, robust, seamless, journey, unlock, solution (as a noun for a product), delve.
Here is the tone we want:
[one real paragraph]

A word list is checkable: you can search the output for each item. “Not like the bad example” is not checkable by anyone, including you.

A case where negatives are necessary

Safety and correctness boundaries in automated systems. If a support bot must never promise a refund, “never promise a refund” plus a demonstration of the near-miss is more robust than either alone:

Text
Customer: "Will I get my money back?"
Correct:  "I'll pass this to the team who can authorise refunds and
           they'll reply today."
Not:      "Yes, we'll refund you." (never commit to a refund)

Here the risk of demonstrating the bad line is outweighed by the value of marking exactly where the line falls, and the correct version still comes first and last in the reader’s attention.

The reverse trick that is often better

Instead of showing bad output, ask for the critique as a separate step:

Draft the email. Then, below it, list anything in your draft that breaks these rules: [rules]. Then give the corrected version.

The model produces the flaw, identifies it, and fixes it, without you having supplied a single example of bad writing. This works well and costs one extra paragraph of output.

It is also honest about what is happening: the checking pass is doing the work, not a warning label attached to a demonstration.

The summary

Bad examples teach. That is the problem. Pair them with their corrections, end on the good one, name the flaw precisely, or skip them entirely in favour of a checkable list of prohibited specifics and a separate self-check pass.

A quick way to decide

Ask what the bad example is for.

If it exists to mark a line (the thing that must never be said, the format that will break a downstream system) keep it, pair it, annotate it. The precision is worth the risk.

If it exists to express your taste (this writing is flabby, this design is ugly, this reply is too cold) take it out. Taste does not transfer through a labelled negative; it transfers through positive examples of what you do want, plus a handful of specifics you can search the output for.

Nearly all the negative examples people put in prompts are the second kind wearing the clothes of the first.

Every lesson here is open. Your progress is recorded once you pass the AI, Actually Explained exam.

Check your understanding

A developer’s prompt includes a malformed JSON sample labelled “NEVER output this”. Output failures increase. Why?

Pick the one you would defend. Your answer stays private.

Next lesson · 9 minCapturing a voice from three samples

Stuck on something?Ask Asha, your AI tutor

How to cite: Addaly (2026) ‘Negative examples, and when they backfire’, in Getting Real Work out of a Model. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/prompting/showing-what-not-to-do (Accessed: 13 October 2026).