Prompt Engineering Patterns That Actually Work in Production

Pattern 1 — Role + task + constraints

Open the system prompt with three things, in order:

1. Role — "You are a senior tax accountant…"
2. Task — "…answering questions from US small-business owners."
3. Constraints — "Cite the IRS publication. Refuse questions outside US tax. Reply in plain English."

This anchors tone, scope, and refusal behaviour before any user input arrives.

Pattern 2 — Few-shot examples

Show 2–5 input/output pairs that look like the real task. Do this when:

• The output format is unusual (custom JSON, markdown table, ASCII diagram).
• The task is fuzzy ("rewrite for a 10-year-old") and a description alone misses.
• You need consistent style across calls.

Skip few-shot when zero-shot already works — examples are tokens you pay for every call.

Pattern 3 — Structured output

Ask for JSON, then validate it. Modern APIs support JSON mode or schema-constrained decoding so you do not parse free text. Pair it with a Pydantic / Zod schema and reject anything that does not validate.

Free-text outputs are demos. Structured outputs are products.

Pattern 4 — Chain-of-thought, but hidden

Letting the model "think out loud" improves accuracy on multi-step problems. But users do not want to read 800 tokens of scratchpad. Solutions:

• Ask for <thinking> then <answer> tags, render only the answer.
• Use a separate reasoning call that produces a plan, then a second call that produces the final output.

Pattern 5 — Refuse and retry

Tell the model what to do when it cannot answer: "If you do not know, reply exactly: I do not know. Do not guess." Then handle that string in code with a retry, a fallback model, or a clarifying question.

What to skip

• Magic phrases ("you are an expert!!!", "this is critical") — diminishing returns and embarrassing in logs.
• Wall-of-text system prompts — every paragraph runs on every call. Cut, then cut again.

From the field

The patterns above get you a working demo. What separates a demo from a product is treating prompts like code: version them, diff them, and never change one without an eval that confirms the change helped instead of quietly breaking three other cases. The single highest-leverage habit I've kept is a small set of real failure examples that I re-run on every prompt edit. It's unglamorous and it has caught more regressions than any "magic phrase" ever fixed. If you can't measure whether a prompt change is better, you're not engineering — you're decorating.