Prompt patterns are tools, not status symbols. Teams often add few-shot examples and chain-of-thought prompts because they saw them in demos, not because their product problem demands them. That is how complexity debt starts.
Anchor yourself in prompt design as product design and eval before launch. Pattern choice without evaluation is superstition. If a pattern does not move your quality metrics on real cases, it does not belong in production.
Let’s separate the patterns clearly.
Few-shot prompting means giving the model a small number of input-output examples to imitate structure, tone, or decision style.
Chain-of-thought (CoT) means prompting the model to reason through intermediate steps rather than jumping directly to a final answer.
Both can help. Both can hurt.
Few-shot earns its keep when output form is the product.
If your assistant must produce a precise style with consistent sections, good examples can dramatically reduce drift. This is common in internal summaries, support response drafts, and structured coaching feedback.
Few-shot also helps when domain language has subtle conventions that pure instruction lines fail to capture. A pair of strong examples can communicate boundaries faster than five abstract constraints.
But few-shot fails when examples are narrow, stale, or biased toward a single context. The model starts pattern-matching surface traits instead of understanding intent. You get polished but wrong answers.
A practical rule: examples should represent the diversity of real inputs, not the easiest happy path.
Chain-of-thought earns its keep when the task truly requires multi-step reasoning or explicit tradeoff handling. Planning, diagnostic reasoning, and ranked recommendation tasks often improve when the model is asked to decompose the problem.
But chain-of-thought can also increase verbosity, latency, and user confusion if surfaced directly. Worse, it can create an illusion of rigor: a long reasoning trace that still lands on a flawed conclusion.
This is why pattern decisions must be tied to user need, not model behavior curiosity.
Ask three questions.
Does this user moment need transparent reasoning or just a useful answer?
Does the pattern improve decision quality on our golden set?
Is the added cost and latency justified by risk reduction?
If you cannot answer yes to at least two, skip the pattern.
There is another risk most teams underestimate: reasoning artifacts can amplify hallucination risk if they are treated as truth instead of process. The model can generate plausible intermediate steps that feel convincing while resting on weak evidence.
That is why lesson four should sit next to hallucination as a product problem. Hallucination is not a bug you patch once. It is a permanent property you design around.
In practice, that means combining reasoning patterns with explicit uncertainty behavior and evidence expectations. If a reasoning step lacks evidence, the assistant should say so and either ask for missing context or provide a bounded answer.
Case evidence reinforces this.
Perplexity’s search rewrite works when synthesis is tied to visible grounding and confidence-aware language. Pattern sophistication without grounding would collapse trust.
Linear’s summary approach is useful partly because it avoids over-engineering. It delivers concise utility where heavy reasoning traces would add friction without adding user value.
Pattern minimalism is often the mature move.
How do you decide pattern choice in a review?
Run an A versus B prompt test.
Version A uses basic structured instructions.
Version B adds the candidate pattern, either few-shot examples or chain-of-thought scaffolding.
Evaluate on the same golden set from eval before launch. Measure not only correctness, but also stability, latency, and reviewer confidence in outputs.
Then ask the strategic question: if this pattern disappeared tomorrow, would product quality materially degrade?
If no, remove it now.
Teams get into trouble when they keep every clever trick ever tried. Prompt bloat reduces maintainability and makes regression debugging painful.
There is also a policy layer to pattern usage.
In regulated or high-stakes contexts, you may choose to hide internal reasoning text from users while still using structured internal steps for quality control. The product decision is to expose outcomes and evidence, not verbose thought traces that users cannot verify.
This balance is central in vertical applications like Harvey’s legal AI, where trust depends on defensible output, domain boundaries, and auditability.
Few-shot has its own governance considerations.
If examples contain sensitive content or stale assumptions, you can unintentionally encode bad policy. Review examples with the same seriousness as instructions. They are specification inputs, not filler.
A hard-won guideline for teams: prefer the simplest pattern that clears the quality bar.
Simple prompts are easier to review, faster to run, and easier to debug across model updates. Advanced patterns should be earned by evidence.
You are building a product system, not participating in a prompt tournament.
One more practical distinction helps teams avoid confusion.
Few-shot is mostly about imitation control.
Chain-of-thought is mostly about reasoning process control.
Do not use one when the other is needed. If your issue is output shape drift, add better examples before adding reasoning scaffolds. If your issue is weak tradeoff analysis, improve reasoning structure before adding more style examples.
Precision in diagnosis saves weeks of random iteration.
Finally, remember that users do not care which prompt pattern you used. They care whether the assistant helped them make a better decision with less risk and less effort.
Pattern choices should disappear into product quality.
That is the standard.
Rules from this lesson
- Use few-shot for output form control and domain nuance, not as a default habit.
- Use chain-of-thought only when multi-step reasoning quality clearly improves on evals.
- Choose the simplest pattern that clears your quality bar on real cases.
- Pair advanced patterns with uncertainty and evidence rules to contain hallucination risk.
- Remove any pattern that adds cost and complexity without measurable product gain.