How to Use Examples in Your Prompts Effectively

A developer spent two hours trying to get AI to consistently extract specific fields from a document. She added more context, clarified the task, specified the format three different ways. Nothing worked consistently. Then she added one well-chosen example. The next 50 outputs were correct.

Using examples in AI prompts is one of the most powerful techniques in prompt engineering -- and one of the most commonly misused. The difference between an example that helps and one that hurts comes down to a handful of structural decisions most people never think about.

Before: The Weak Prompt

Most people add examples as an afterthought:

Classify the sentiment of customer reviews as positive, negative, or neutral.

Example: "Great product, fast shipping!" - positive

Now classify: "The product works but the packaging was damaged."

What this does: Provides an example, but it's too simple to be informative. "Great product, fast shipping!" is unambiguously positive -- any model already knows this. The example doesn't teach anything about the cases that are actually hard.

Why It Fails

Examples fail for three reasons:

They demonstrate the easy cases. Useful examples demonstrate boundary cases -- the reviews that could plausibly be positive or neutral, the inputs that violate common assumptions, the edge cases where your classification differs from the model's default.

They demonstrate inconsistent formats. If your example shows "positive" but your task prompt says you want "POSITIVE" (caps) or JSON, the example and the instruction conflict. The model has to choose which to follow -- and it doesn't always choose the instruction.

They demonstrate too much at once. An example that mixes multiple variables (unusual vocabulary, complex structure, edge-case classification) teaches several things simultaneously. The model may learn the wrong lesson.

⚠️ Common mistake: Adding examples to a prompt and assuming they'll help. The wrong example can actively hurt -- by teaching the model a pattern you don't want, by creating format inconsistencies, or by anchoring the model to a domain that doesn't match your actual inputs.

After: The Improved Prompt

Classify the sentiment of customer reviews as: positive, negative, or neutral.

Classification rules:
- Mixed reviews (some positive, some negative aspects) = neutral
- Reviews about shipping/packaging only, not the product = neutral (unless extreme)
- Sarcastic positives ("oh great, another broken product") = negative

Examples (format: review -> classification -> reasoning):

Input: "Works as advertised but took 3 weeks to arrive."
Output: neutral
Reasoning: Mixed -- product satisfaction positive, shipping negative.

Input: "Yeah, because I definitely needed a third paperweight."
Output: negative
Reasoning: Sarcastic -- apparent positive language signals product failure.

Input: "Packaging was damaged but product inside was fine."
Output: neutral
Reasoning: Packaging-only issue, product functional -- neutral per classification rules.

Now classify (output format: classification only, one word):
Review: [input]

What this does: Three structural improvements. Examples demonstrate boundary cases rather than obvious cases. Examples include reasoning -- teaching the decision logic, not just the output. The output format is specified both in the examples and in the final instruction, eliminating format inconsistency.

Breaking Down Each Element

The reasoning field is the most important improvement. When you show the model why an input maps to a classification, it learns the underlying decision rule -- not just the input-output mapping. This generalizes dramatically better to novel inputs than reasoning-free examples.

Boundary case examples beat obvious examples every time. Don't show the model what it already knows. Show it what it might get wrong. Before choosing examples, ask: "What are the three inputs most likely to produce the wrong classification?" Those are your examples.

Format consistency between examples and instructions is non-negotiable. If example outputs are in one format and task instructions specify another, you're teaching the model to produce the wrong format. Example format must match task format, always.

⚡ Pro tip: For classification tasks, aim for at least one example per class, plus one boundary case for each class boundary. A three-class problem needs at least 5 examples: one clear positive, one clear negative, one clear neutral, one positive-neutral boundary, and one negative-neutral boundary.

Variations for Different Contexts

For generation tasks (writing, formatting, transforming): Use input-output pairs that demonstrate the transformation you want. Include a "bad output" example with a note explaining why it fails:

Example:
Input: [raw customer complaint]
Good output: [professional response that acknowledges without admitting fault]
Bad output (do not write like this): [overly apologetic response that implies liability]
Why bad: Over-apologizing creates legal exposure and sets false expectations.

What this does: Negative examples are often more powerful than positive ones -- they precisely define the boundary between acceptable and unacceptable outputs.

For extraction tasks: Show the full input, the correct output schema, AND what to output when a field is missing:

Example with missing field:
Input: "Invoice #INV-001 for $500. Payment due upon receipt."
Output: {"invoice_number": "INV-001", "amount": 500, "due_date": null}
Note: due_date is null because "upon receipt" is not a specific date.

What this does: Teaches the model the null-handling behavior explicitly -- not just the happy path.

⚡ Pro tip: When adding examples to an existing prompt that isn't performing well, add only one example at a time and test after each addition. More examples are not always better -- a well-chosen single example often outperforms three mediocre ones, and conflicting examples actively hurt performance.

⚡ Pro tip: Store your best-performing example sets in PromptABCD alongside the prompts they support. Examples that took you time to identify and validate are valuable assets -- they encode your task's edge cases and decision rules in a form the model can actually use.

Save and Reuse This

The example engineering approach described here -- boundary cases, reasoning fields, format consistency, negative examples -- applies to any prompt type. The specific examples change; the selection criteria don't.

Build a habit of adding a "why this example" note alongside each example you include in a prompt. This documents your reasoning, makes it easier to update examples when the task evolves, and helps teammates understand the edge cases you've already thought through.

How Many Examples Do You Actually Need?

The research on few-shot prompting (using examples in prompts) consistently shows diminishing returns after 4-6 examples for most classification and extraction tasks. Adding more examples beyond this threshold rarely improves performance and sometimes degrades it by making the prompt too long.

The practical implication: don't add examples until you need them, and don't add more than 6 unless you have strong evidence that specific additional examples improve performance on your actual inputs.

Here's a decision framework for example count:

Example count decision framework:
- 0 examples: Use for simple, unambiguous tasks where the model clearly knows what you want
- 1-2 examples: Use when format is non-standard or the task has a specific style requirement
- 3-4 examples: Use when the task has meaningful boundary cases the model might misclassify
- 5-6 examples: Use for complex classification with multiple edge cases or unusual domain vocabulary
- 7+ examples: Only with strong evidence from controlled testing that additional examples improve accuracy on your specific inputs

Rule: Add the minimum number of examples that produces acceptable accuracy. More is not better.

What this does: Gives you a principled framework for example selection rather than the common practice of adding examples until the output "looks right" on a few test cases.

⚡ Pro tip: If you're using more than 6 examples and still seeing accuracy problems, the issue is probably not the number of examples -- it's the quality of your task specification, the clarity of your classification rules, or a genuine capability limit of the model on this task type. More examples won't fix those problems. Better task definition will.

Once you've identified the right examples for a task, save them in PromptABCD alongside the prompt. Your example sets encode hard-won knowledge about your task's edge cases -- knowledge that's easy to lose when someone edits the prompt without understanding why specific examples were chosen.

Maintaining Your Example Library Over Time

Examples become outdated as tasks evolve. An example set that perfectly captures your classification logic in January may miss edge cases that appear by April as your data distribution shifts.

Build a quarterly example review into your prompt maintenance workflow:

1. Pull 20 outputs from the last 90 days that required human correction
2. For each corrected output, check whether your current example set would have prevented the error
3. If an error type isn't covered by any example, add an example for it
4. If an existing example is covering a case that no longer appears in real data, remove it

This keeps your example set tightly calibrated to your actual data distribution rather than to the distribution you imagined when you first wrote the prompt.

The most effective prompt libraries aren't written once and frozen -- they evolve with your data. PromptABCD's versioning makes this evolution trackable: you can see exactly what examples were in each version, and correlate example changes with output quality changes over time.