Pebellslearn by building
0%
RoadmapsMatrixCoursesSandboxSign in
Prompt Engineering  ›  Lesson

Show Examples, Then Test and Iterate

Use Examples in your Prompt 15 minFew-shot examples teach format and edge cases by demonstration, and prompts improve by scoring every change against a fixed set of test cases while changing one thing at a time.

Show Examples, Then Test and Iterate

Tripmate has to turn messages like "need 2 seats blr→del sat morning" into clean search arguments. You describe the rules in the prompt, and it mostly works — until a user writes "day after tomorrow" or "Bengaluru" instead of "BLR". Two habits fix this: show the model examples, and test the prompt like code.

The rule

Show, don't just tell — then test on real cases and change one thing at a time.

Examples (often called few-shot prompting) teach by demonstration. A handful of input–output pairs shows the exact format, tone and edge-case handling faster than paragraphs of rules:

Convert the request into search arguments. Today is 2026-10-12 (Monday).

Request: 2 seats blr to del sat morning
Output: {"from": "SBC", "to": "NDLS", "date": "2026-10-17", "passengers": 2, "time": "morning"}

Request: going from Bengaluru to Mysuru day after tomorrow, just me
Output: {"from": "SBC", "to": "MYS", "date": "2026-10-14", "passengers": 1, "time": null}

Request: {user_message}
Output:

Choose examples that differ from each other — a city code and a full name, a weekday and a relative date — so the model learns the rule, not one surface pattern. Models copy what they see, including mistakes, so check each example is exactly right. Two to five good examples are usually enough; each one costs input tokens on every call.

Iteration is how a prompt gets good. Collect a set of real test messages, including awkward ones, and record what a correct output looks like for each. Run the prompt on all of them, look at the failures, change one thing, and run the whole set again.

The shortcut

Treat a prompt like a function with unit tests: a list of inputs and expected outputs. Never judge a prompt change by one lucky reply — judge it by the score on the whole set.

One round of prompt testingStep 1 of 4
  1. Build the test set

    Twenty real requests with the correct arguments written next to each, including "tmrw", "Bengaluru" and a request with no date.

The trap is changing several things at once, or testing only the case you just fixed. You will not know which change helped, and you may quietly break cases that used to work.

Drills

Answer fast — trust the rule.

quick drill

What does a few-shot prompt contain?

quick drill

All your examples use city codes like "BLR". What risk does that create?

quick drill

You change a prompt and one tricky message now works. What should you do next?

quick drill

One example in your prompt has a wrong date. What is the likely effect?

Remember

  • Show a few varied, correct examples; they teach format and edge cases faster than rules.
  • Shortcut: a prompt is a function — keep a test set and score every change on all of it.
  • Trap: changing several things at once, or testing only the case you just fixed.

Practice — level up

0/1 solved

Write your answer, then compare it with a rubric and a model answer.

ExplainPlan a prompt test

Your prompt turns messages like "2 seats pune to jaipur fri" into search arguments. Describe how you would build a test set for it, how you would use examples in the prompt, and how you would decide whether a change is an improvement.