How to Use Examples in AI Prompts: Few-Shot Prompting (2026)

You are reading Chapter 14 of 36 in the AI Bootcamp, AI Central's free course for professionals who want to use AI in their own work. The chapters build on each other, so if this is your first one, Chapter 1 is the place to start. All of them sit on the AI Bootcamp page, and three more arrive every week.

Few-shot prompting means showing the assistant one finished example of the output you want instead of describing it in adjectives. It is the fix for a prompt that keeps coming back the wrong shape when nothing in the prompt is actually wrong.

This chapter covers when to stop describing and start showing, how to choose an example that teaches the pattern rather than its own surface, how many examples each kind of job needs, and how to spot the point where the example has started writing the answer for you.

We publish AI systems like this for 300,000+ senior professionals at AI Central, and more of them live in the AI Central Library.

You wrote the instruction properly, all five parts of it, and you described the format you wanted in careful detail. What came back is still not shaped the way you meant, and nothing in the prompt is wrong.

Every adjective you use to describe a format is a guess about what the assistant will picture. Concise, formal, punchy, structured, executive: you know exactly what each of those means, because you have one specific document in your head as you type it. The assistant has an average of everyone else's.

The distance between your document and that average is the distance you keep trying to close by adding more words. Every extra adjective costs you a round trip.

If you have not built the five-part instruction yet, Chapter 13 puts it together. Bring the prompt from it that still is not returning the shape you wanted, because that failing prompt is the raw material for this one.

A description of an output and the output itself are two different objects, and only one of them is unambiguous. Most format arguments end the moment you stop describing and paste.

A description is words about the output you want. It is fast to write and often enough, it costs nothing to try first, and you can change one word and rerun. The cost is that every word is open to interpretation, it is silent about everything you forgot to mention, and you find out what it heard only after it answers.

An example is one finished output of the kind you want, pasted in whole. It settles format, length, ordering, level of detail, house punctuation and register at the same time, including the parts you would never think to specify because you have never had to say them out loud to a colleague. It costs you the time of finding a good one, and it copies what you show it, including your mistakes.

The professional habit is to start with the description and reach for the example the moment the description has failed twice.

Giving examples is called few-shot prompting. None is zero-shot, one is one-shot, and you will meet the term in every vendor document you read. The name matters less than the reflex: when you have described the output twice and it is still wrong, stop describing and start showing.

You have already done this once, on one narrow thing. Chapter 10 fixed writing that sounds like AI by handing the assistant a sample of your own, and our guide to humanizing AI writing covers that case on its own. This chapter points the same move at the rest: how a record should be laid out, how a borderline case should be decided, how much detail a summary is supposed to carry, what to write in a field when there is nothing to put in it.

Two things an example will not fix. It cannot make the assistant know something it does not know, and it will not stop it being confidently wrong about a fact. Examples fix shape. They do not fix truth.

Most people paste in whatever is open, or whatever they are proudest of. Both choices teach the wrong lesson, and the second one teaches it more convincingly. Four tests an example has to pass before you use it.

Pasting in the single best client memo you ever wrote sets a standard nothing in the batch will meet, and it teaches the particular flourishes of a piece that was unusual on purpose. Pick the one you would describe as fine. Fine is the standard you actually want held across 40 records.

Take a real job. You have a quarter of meeting notes, 40 of them, and you want each one turned into the same record: client, date, what was agreed, what is outstanding, who owns the next step. Three clean examples of well-run meetings will get you 30 good records and 10 improvisations, because 10 of those meetings ended with nothing agreed, or with two owners, or with a decision that quietly reversed one from the month before.

So show the record for the meeting where nothing was decided, with "none agreed" written into the field rather than the field deleted. That one sample does more work than the other two put together, because it is the only one that tells the assistant what to do at the moment it would otherwise invent something. The example showing what to do when a field is empty is worth three more clean ones.

Do not trim it to save space, do not swap the real names for placeholders unless placeholders are what you want back, do not clean it up first out of embarrassment. Every edit you make to an example is an instruction you did not mean to give, and the edits you make out of tidiness are the ones you will not think to look for later.

The most under-used example is the one you turned down. Paste a rejected version, label it clearly as rejected, and give one line of reason: this one is wrong because it summarises the discussion instead of recording the decision. That single line draws a boundary three more good examples cannot draw, because good examples only ever show the inside of the space, never its edge. Keep it to one, and keep the label attached to it.

None of this needs volume. One well-chosen example beats several near-identical ones, and the testing keeps finding the same thing: what improves the output is which examples you picked, not how many. Three redundant samples showing the same easy case teach one lesson, three times.

Examples are not uniformly useful. They help most on formats and categories and least on open writing, which is the opposite of where most people spend them. Read down until a line describes the job in front of you.

What you are transferring is register, and one real piece carries register completely. A second one often makes things worse rather than better. Stack up four and you start transferring the specific moves of those four pieces instead.

The meeting records above, a standard client update, a weekly summary that always has the same five fields. One example establishes the shape. The second and third establish which parts of that shape are fixed and which are allowed to move, which one example on its own can never tell it.

Spend them one per category rather than three on the easy category and none on the two that are hard to tell apart. This is where examples earn the most: showing it four decided cases outperforms any amount of describing where the line between buckets sits.

Past about five, the returns do not just flatten. Independent testing and the vendors' own documentation both report accuracy going down again, because a long stack of samples starts teaching their surface rather than their pattern. If you are at five examples and the output is still wrong, adding a sixth is the least likely thing to fix it. Nine times in ten the examples are fine and the task sentence is ambiguous.

The vendors converge on this. Anthropic's guidance says include three to five. Google's warns that too many make it overfit to your samples. OpenAI's says add them only when a plain instruction has failed.

Two mechanical points that cost nothing. It weights what it read most recently, so put your strongest example last. And keep the formatting between examples strictly identical, down to the punctuation and the order of the fields, because any variation between your own samples is read as a signal that variation is allowed.

This technique has a real failure mode, and it looks like success, which is what makes it expensive. An example is the most concrete object in your prompt, and concrete objects get copied. Not the pattern underneath the example, which is what you meant, but the surface of it: the sentence rhythm, the vocabulary, the particular turn of phrase, sometimes the name of the specific client who happened to be in the sample.

The most costly version is anchoring on a number you never intended to set. If the example you pasted pulled four risks out of a contract, you have taught it that this task returns about four risks, and the next contract comes back with four risks in it whether the document contains three or eleven. Nothing looks wrong on the page. You get a clean, well-formatted, confident answer that is missing seven things, and you will only find that out by reading the source yourself.

The third version shows up on creative work. Ask for 10 subject lines with one sample attached and you will often get 10 variations of the sample rather than 10 options, because the example has fixed the range as well as the format. That is a fair trade when you want consistency and a bad one when you want choice, and knowing which of the two you are asking for is the whole skill.

The fixes are small. Say in one line what the example is there to demonstrate and what it is not: this shows the field order and the level of detail, not the length or the subject matter. Deliberately vary everything you do not want copied, so if length is not the lesson, make your examples visibly different lengths. And on anything open-ended, run it once with the example and once without, then compare the two rather than assuming the version with more effort in it won.

One more, worth knowing before you meet it. On the deeper thinking settings, a stack of examples has been reported to do worse than a single clean instruction, apparently because the effort goes into matching the shape of the samples instead of working the problem. For now, treat a long example stack and a heavy reasoning mode as two tools that do not always want to be used together.

Before: you describe the format you want, the reply comes back the wrong shape, and you add another adjective and run it again.

After: you paste one finished sample chosen against the four tests, you write the line saying what it demonstrates and what it does not, and the format is settled in one paste instead of another round of adjectives.

The chapter has three exercises and takes about 15 minutes: pick the example and write down why it is typical rather than your best, write the two lines that have to travel with it, then run your Chapter 13 prompt twice, once as it stands and once with the example pasted in above it.

Two things carry into Chapter 15: the example you tested with the line saying what it demonstrates, and one question you have asked that came back confident and wrong. Chapter 15 stops working on the shape of the answer and starts working on how the answer gets reached. For the wider set of prompting moves this one sits inside, read the 26 principles of prompt engineering, keep our free AI cheat sheets beside you while you work, and the rest of the syllabus lives in the AI Central Library.

Giving the assistant one or more finished examples of the output you want, inside the prompt, instead of describing that output in adjectives. No examples is zero-shot, one is one-shot. A single paste settles format, length, ordering, level of detail and register at once.

One for open-ended writing in your own voice, two to three for a fixed format you run repeatedly, three to five for sorting things into set categories. Past about five the returns flatten and can reverse. If it is still wrong at five examples, the instruction is the problem, not the count.

Four tests. It is typical rather than your best work, it includes the awkward case such as a missing field, it is complete exactly as you would send it, and it is labelled with what it shows. An example that fails any one of the four will teach something you did not intend.

One, and only if you label it as rejected and give a one-line reason for the rejection. A labelled counter-example draws the edge of the space, which good examples never do because they only ever show the inside of it. Unlabelled, it is just a bad example.

Because the example is the most concrete object in the prompt, so its surface gets copied along with its pattern: the rhythm, the phrasing, even the number of bullets it happened to contain. Write one line saying what the example demonstrates and what it does not, and deliberately vary anything you do not want copied.