Prompt Engineering · ~7 min
A rule says "do it this way" and trusts the model to interpret. An example says "produce exactly this." Pick the wrong one and the agent invents its own intent.
Rules generalize. Examples anchor. That difference is not stylistic — it is a function of which kind of failure you are trying to prevent. Match the vehicle to the failure and the agent follows; mismatch it and the agent fills the gap with its own guess.
Each vehicle is cheap in one way and fragile in another.
So the question is never "which is better?" It is "which failure am I preventing — a misread, or an over-fit?"
Use a rule for behavioral constraints where the output space is large, compliance is binary, and any reasonable interpretation is acceptable:
Never commit directly to mainKeep functions under 30 linesUse an example when format or structure matters precisely and a misinterpretation produces clearly wrong output — file naming, commit-message structure, output schemas. Examples are also strong for anti-patterns: pair "don't do this" with a concrete instance rather than describing the prohibited shape abstractly.
The most dependable pattern is both at once: state the rule, then show one example. The rule gives a generalization to apply; the example gives a concrete reference to check against.
One example is usually enough. Multiple examples shift the agent's focus from the rule to the pattern of the examples themselves — it begins to interpolate between cases rather than apply the constraint uniformly.
Several near-duplicate examples push the model to average across them — producing outputs that sit between the cases you showed instead of obeying the constraint they share. For a constraint rule, one well-chosen example suffices; pile on more and you trade a clean boundary for a blurry midpoint.
For format and style constraints inside a codebase, pointing at existing code beats reproducing an inline sample. A hint is a reference, not a reproduction.
| Inline code sample | Hint equivalent |
|---|---|
A 30-line UserRepo class pasted in full | "Follow the repository pattern in src/repos/UserRepo.ts" |
| A full example middleware function | "Use the existing middleware in src/middleware/auth.ts" |
Hints win on two counts. They stay current: an inline sample freezes the moment it is written and drifts as the real code changes, while a hint points at whatever the file says today. And they are cheaper: a 30-line example loaded every session draws on the context budget for every task, including unrelated ones — a hint costs one line. The one case for an inline sample is a genuinely novel pattern with no existing example; once any file implements it, replace the sample with a hint to that file.
Rules and examples engage different machinery. GPT-3 established that models infer tasks from demonstrations alone, without fine-tuning or explicit rules (Brown et al., 2020). Mechanistic work traces this to induction heads — attention heads that find an earlier occurrence of the current token and copy what followed it (Olsson et al., 2022). An example supplies a template to replicate; a rule asks the model to derive the intended output space by inference. Combining the two engages both: the rule limits the interpretation space, and the example collapses the residual ambiguity to a specific format.
Retrieval practice — recall, don't peek
Question 1The characteristic failure mode of a rule is that it…
Question 2An example is the right vehicle when…
Question 3Showing several near-duplicate examples tends to make a model…
Question 4A hint to existing code beats an inline sample mainly because it…
Question 5 · spaced recall from Lesson 5For coding agents on SWE-bench, the only individually beneficial rule type was…