Your few-shot examples quietly became your spec

A lead engineer at a travel booking company was chasing a bug that made no sense to him. The output format of one of their AI features had changed across the board. No code had shipped. No instructions in the prompt had been touched. Yet every result now came back structured differently than it had the week before.

The cause was one example.

The examples were doing the real work

Their prompt had the usual two parts. A block of instructions telling the model what to do, and then three or four worked examples showing input and the desired output. Someone on the team had noticed one example looked a little dated, so they updated it. New input, new output, tidier formatting. It seemed like housekeeping. They committed it and moved on.

That single example had been carrying the output format for the whole feature. The instructions said “return the result,” in prose, without ever pinning down the exact shape. The model learned the shape from the examples. When the example changed, the model followed the new one, and the format shifted everywhere.

The instructions were not the spec. The examples were the spec, and nobody had written that down. The team thought they were editing a sample. They were editing the contract.

Examples define behavior more forcefully than instructions

This is the part that surprises people. A model weighs a concrete example more heavily than an abstract instruction. You can write “always return valid JSON with these fields” in the instructions, and a single example that shows a slightly different structure will often win. The model pattern-matches to what it sees demonstrated, not to what it is told in the abstract.

That makes few-shot examples the most load-bearing part of many prompts, and the part teams treat most casually. Instructions get discussed and reviewed. Examples get pasted in from a demo, tweaked when they look stale, and swapped without much thought. All the while they are quietly setting the behavior the instructions only gesture at.

Once you see the examples as specification, you change how you handle them.

Choose examples deliberately. Each one should demonstrate a behavior you actually want, including format, tone, and how to handle a hard case.
Cover the shapes that matter. Include an example of the tricky input, not only the easy one, because the model learns the edge from what you show it.
Change them like code. An edit to an example goes through review, because it can move behavior across the whole feature.
Test after an example change. Run the sample and confirm the output shape held, the same way you would after a logic change.
Keep instructions and examples in agreement. When they conflict, the example usually wins, so do not let them drift apart.

The goal is to stop editing examples as if they were decoration. They are the clearest statement of what you want the model to do, which makes them the spec whether you meant them to be or not.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week engagement priced at $2,500, we read a prompt’s examples as carefully as its instructions, because in most prompts the examples are where the real behavior is defined. We check that each example earns its place, that they cover the hard inputs, and that changing one goes through the same review as any other production change.

An example casually swapped is a spec silently rewritten. Treat the examples as the contract they already are, and the mysterious format change stops happening.

The instructions say what you meant. The examples say what the model does.