Teach by Example: How to Show AI What Good Looks Like

This is a follow-up to our previous article, Shaping the Output, where we covered the second principle of prompt engineering: telling the AI how to deliver. Before that, The Direction Stack covered how to give it clear direction. Today we're tackling the third principle from Prompt Engineering Basics: teaching by example.

So you've written a prompt with a clear role, a clear task, and a clear format, and the answer still comes back a little off. The tone is close, but it isn't yours. The length is fine, but the rhythm is wrong. You add another line of instructions, then another, and now you're writing a whole paragraph describing a vibe you could have just shown in five seconds.

That's what examples are for. Instructions tell the AI what you want. Examples show it. And when the two disagree, the examples win almost every time.

Zero-shot, few-shot, and why it matters

When you give the AI instructions and nothing else, that's called zero-shot prompting. It has to build its whole idea of "good" from your description, and descriptions lose a lot in translation. "Short, punchy and professional" means one thing to you and something pretty different to a model trained on the entire internet.

It's like describing a song to someone instead of just humming it. You can say "upbeat, kind of folky, builds at the end" all day. Hum eight bars, and they've got it.

When you include a few samples of the desired output, that's few-shot prompting. Now the AI isn't guessing at "punchy." It can see exactly how long your sentences run, where you put the verb, whether you use numbers, and what you leave out.

Here's the difference in practice. Say you need release notes for your app.

The zero-shot version:

Write release notes for these changes: dark mode on the settings page, faster search, fixed a crash when importing CSV files.

You'll get something usable, but it'll probably come with a headline, an intro paragraph, a few emojis, and a closing line thanking your amazing users. And every run looks a little different.

The few-shot version:

Write release notes for these changes in the same style as the examples.

Examples:

• Search is faster. Results for large libraries now load in under a second.

• Fixed a bug where tags disappeared after renaming a folder.

• You can now duplicate a prompt from its menu.

Changes: dark mode on the settings page, faster search, fixed a crash when importing CSV files.

Now the AI knows the format (one line each), the voice (plain, no hype), and the structure (what changed, then what it means for you). You didn't have to explain any of that. The examples carried it.

What makes a good example

Not every example teaches the right thing. The AI copies whatever pattern is strongest, so you want the strongest pattern to be the one you actually care about.

Use real ones. The best examples are outputs you've already used and been happy with: a product description that converted, an email that got a reply, a commit message your team liked. Made-up examples tend to be generic, and generic examples teach generic output.

Vary them on purpose. If all three of your examples are exactly two sentences long, every answer will be exactly two sentences long. If they all start with "We," so will everything else. Vary the stuff you don't care about so the AI locks onto the stuff you do.

Cover the tricky case. If there's an edge case that trips the AI up, put one example of it in. One example of how to handle a missing value or an awkward input is worth more than three examples of the easy path.

Label them clearly. Put your examples in their own section, marked as examples, and keep them separate from the real input. Otherwise the AI can mistake your samples for content it's supposed to work on.

Show it what bad looks like, too

This one gets overlooked. Sometimes the fastest way to get what you want is to show the AI what you DON'T want.

Regular expressions are a great example. Describing a pattern in words is hard. Listing a few strings that should match and a few that shouldn't is easy, and it gives the AI something to test against. That's exactly how the Regex Builder prompt in our developers collection works. You paste in should-match and should-not-match examples, and the prompt tells the AI the pattern has to pass every one of them.

The same idea works for writing. The Brand Voice Guide prompt in our marketers collection asks for two example sentences of each voice trait done right, and two of it pushed too far. "Confident" is vague. "Confident, not cocky," with an example of each, is something a writer (or an AI) can actually follow.

How many examples you actually need

Honestly, fewer than you'd think. Two to five covers most tasks.

One example is risky, because the AI tends to copy it too literally. You'll get the same structure, sometimes the same words, with your new content swapped in. Two or three gives it enough to find the pattern without memorizing one instance.

Past five, you're mostly just paying for tokens. The exception is sorting or tagging, where you want at least one example per category so the AI sees what each label looks like.

When examples backfire

Examples are powerful, which is exactly why they can cause problems.

The AI copies content, not just style. If your example tagline mentions "teams," don't be surprised when every new tagline mentions teams. Keep the subject of your examples different from the task, or vary it across examples.

Examples override instructions. If your instructions say "keep it under 20 words" and your examples run 35, you're getting 35. When the output ignores an instruction, check whether an example is quietly contradicting it.

Old examples age badly. An example from before your product changed, or before your brand voice changed, will keep pulling the output back to the old version. Treat examples like any other part of the prompt and update them.

Examples work for images, too

Image tools have their own version of this. Instead of describing a style in words, you can hand the tool a reference image and let it pick up the lighting, palette, and composition from that. In Midjourney, that's a style reference, and most of the other major image tools now have some form of image reference alongside the text prompt.

The same rules carry over. A single reference gets copied closely. A couple of references that share the style you want, but show different subjects, teach the style without locking in the subject.

Keep the examples that work

Here's the part nobody really talks about: the examples are the expensive part. The instructions take a minute to write. Finding three outputs you're genuinely happy with, that cover the tricky case and vary in the right ways, takes a lot longer. Sometimes it's weeks of real use before you know which outputs were actually good.

Which is why it's kind of wild how often people throw them away. The prompt that worked lives in a chat history somewhere, the examples that made it work are buried in the same thread, and next month you're starting over from a blank page.

A better habit is to keep them together. When a few-shot prompt works, save it with its examples, and turn the parts that change into variables so the next job is fill-in-the-blanks instead of a rewrite. In Musebox, that's a saved prompt with an {{examples}} variable, or the examples written right into the template when they don't change. Either way, the next time you need it, you're starting from something that already works.

And if you don't have your own examples yet, you don't have to start from zero. Our prompt collections are organized by role, from writers to developers, and each one has 26 to 30 prompts picked for real work. Save the ones you use, add your own examples, and they're yours.

The bottom line

Direction tells the AI what to think about. Format tells it how to deliver. Examples show it what good actually looks like, and they're often the difference between output you tweak and output you use.

Use real examples, vary them on purpose, cover the tricky case, and keep the ones that work.

In the next article, we'll cover the fourth principle: checking the work, and how to test a prompt so you know it'll hold up the tenth time you run it, not just the first.