Why patterns over cleverness
The prompt engineering tips that go viral are almost all clever. The prompt patterns that ship in production are almost all boring. The reason is simple: production wants reliability across thousands of inputs, and clever prompts fail on the long tail.
What follows are five patterns that hold up under load. None of them are secrets — you'll recognize them all. What's worth internalizing is when each one is the right tool.
Pattern 1: Role-then-task framing
Start with who the model is, then what it does, then the constraints. This ordering matters — flipping constraints and role weakens instruction following on smaller models.
The role isn't fluff. 'You are a senior tax accountant reviewing a 1099' outperforms 'review this 1099' because it primes the model to reject inputs that don't match a real 1099 shape. Roles are cheap constraints.
Pattern 2: Explicit output schemas
For anything a downstream system will parse, always specify a JSON schema in the prompt and demand the model output only JSON. Modern models honor this well; older ones need reinforcement ('respond with JSON only, no prose, no code fences').
Even better, define the schema with Zod (or your equivalent) and pass the schema description into the prompt. Then validate the model's output against the same schema in code. When it fails, feed the validation error back and re-prompt once. This alone catches 90% of malformed outputs.
Pattern 3: Curated few-shot examples
Two or three real examples in the prompt outperform any amount of instruction prose for classification, extraction, or tone tasks. The trick is curation: examples should span the hard cases, not the easy ones.
Store your few-shot set in a version-controlled file, not scattered across prompts. When behavior regresses, the diff is where you look first.
Pattern 4: Refusal guards
When you need the model to refuse a category of input (unsafe, off-topic, malformed), say so explicitly with an example of the refusal. 'If the input isn't a resume, respond with exactly {"error": "not_a_resume"} and nothing else.' Without this, models improvise refusals in prose that break your parser.
Pattern 5: Self-critique passes
For reasoning-heavy tasks, a two-call pattern — generate then critique — beats a single-call chain-of-thought on real evaluations. The critique prompt gets the original prompt plus the first answer and is asked 'what's wrong with this?' Then a third call takes both to produce a final answer.
It's slower and more expensive. Reserve it for tasks where a wrong answer is expensive: legal, medical, financial, safety-critical.
When to use which
Most workflows need patterns 1-3. Add pattern 4 when the input is untrusted. Add pattern 5 only when correctness matters more than latency. Stacking all five on every prompt is overkill and makes prompts hard to maintain.