Build with AI and trust what you make. Free guide, no signup

Show by example

Give AI an example or two and let it infer the shape for yours. Good when you can recognise a good answer but cannot generate one from scratch.

examples you givea dish you never gave itPastaserves 2, spaghetti, tomato1. boil 2. simmerSmoothieserves 1, banana, milk1. blend 2. pourClaudeCheese toastieserves 1, bread, cheese, butter1. butter the bread2. grill till golden
Show by example in one picture. Hand Claude a couple of genuinely different examples in the shape you want, here two recipe cards, and it writes a new one for a dish you never gave it, in the same shape. Two different examples teach the pattern, not one fixed layout.
I am defining [the thing: for example the user, the problem, or the promise].

Here are one or two definitions I think are good: [paste examples].

Using those as the shape and level of detail, draft one for my case: [describe your case]. Match the structure of the examples. Keep it to three short lines.

Copy this into your AI chat.

Replace the bracketed parts and paste one or two definitions you think are good. It drafts one in the same shape for your case, which you then run through Sharpen.

Doing this with Claude Code: Show by example

An example earns its keep in five ways: consistency, generalisation, exact shape, ambiguity and reasoning.

Consistency, hold the shape. Show one recipe card laid out as a title, then ingredients, then steps, and every card comes back in that same shape, run after run.

Generalisation, a dish you never gave it. Show a few genuinely different cards, a dinner, a dessert and a drink, and Claude can write a snack card it never saw, because the spread taught it the pattern and not one layout.

Exact shape, leave nothing to guess. Show one card with every field filled in, so the shape is there to copy rather than described.

Ambiguity, pin down the vague bits. Show what salt to taste means once, a pinch building to about half a teaspoon for this soup, and Claude reads the next loose instruction the same way.

Reasoning, the why and not just the result. Show why a pinch and not a spoonful, because more would overpower it, and Claude picks up the principle instead of copying one amount.

Common questions

  1. When should I switch from describing what I want to showing it?
    Use an example as the fallback. Start by describing what you want, and if that keeps giving mixed results, stop rewording the description and switch to showing the result you expect instead.
  2. Why does describing something drift?
    Plain words get read a little differently each time, so the output moves around. A concrete example removes that room and pins the thing down to one shape.
  3. How similar should my examples be to each other?
    Vary them rather than repeating one shape. A few genuinely different examples teach the underlying pattern, so Claude can handle a case you never showed it, where near-identical ones only teach that single case.
  4. Where should I start?
    Begin with the happy path, the normal case working as it should, then build from there. Keep each example concrete and narrow, because a broad example pins nothing down.
  5. Does showing by example help with the awkward cases?
    That is where it earns its keep. When the code trips on the odd one, the null, the empty or the boundary, hand over that single case as a worked example and let Claude fix just that.
  6. Does it work the other way round?
    Yes. When Claude does something you do not understand, ask it to show you with an example rather than explain it, and the reasoning usually becomes obvious.

Back to For developers. The craft around it is Working with AI.