Few-Shot Examples: Showing Instead of Telling

Some output styles are nearly impossible to describe. Try writing instructions for how your team titles bug reports, or how your brand phrases a product update. You'll end up with a paragraph of rules that the model follows in letter and misses in spirit. Show it four good examples instead and it often gets the pattern on the first try.

That's few-shot prompting: including a handful of input-and-output examples (each one a "shot") so the model learns your format by imitation. It's one of the most effective tools you have, and one of the easiest to misuse: models copy examples too faithfully, borrow details from them, and quietly drift when the examples go stale. In this lesson you'll choose, format, and maintain examples for a real Deskmate feature, and learn how to catch a model that's imitating the examples instead of learning from them.

When examples beat instructions#

Current models follow written instructions well, so start without examples (a zero-shot prompt) and add them only when instructions fall short. They tend to fall short in four situations:

• House style. A format with many small conventions: capitalization, ordering, what to abbreviate, what to leave out. Each is easy to show and tedious to specify.
• Fuzzy boundaries. Judgment calls where the line is hard to put into words, like which product area an ambiguous ticket belongs to.
• Unusual formats. Anything the model hasn't seen often in training, such as an internal notation or a compact log format.
• Tone. "Warm but brief" means different things to different writers. Three sample replies mean one thing.

They're a poor fit when the task needs reasoning the examples can't show (examples teach the shape of an answer, not how to get there), when a schema can enforce the format directly, or when the examples would be so long that you're paying for thousands of extra tokens on every call.

The feature for this lesson: Deskmate auto-titles every incoming ticket. Customers write subjects like "HELP!!!" or "question", which make the ticket list useless. Deskmate rewrites each one into the support team's internal convention. Here's the convention written as instructions:

Write an internal title for the ticket. Start with the product area (Billing, Login, Reports, Integrations, Account, or Other), then a colon, then a short description in sentence case. Describe the problem or request concretely, not the customer's emotion. Keep any invoice or order IDs exactly as written. If there are several issues, title the most urgent one and add "(+N more)". If the ticket isn't in English, add the language in parentheses. Stay under 70 characters.

It's a decent spec, and a model will follow most of it. What it can't convey is judgment: how concrete "concrete" is, which of two issues counts as more urgent, how much to compress. Those are much easier to show.