Most of the “prompt engineering is dead” takes miss the point. The art hasn’t gone away; it’s just matured. The five-line “act as a…” prompts still get shared on LinkedIn, but the professionals who actually use AI every day have moved on to something more durable: a small set of patterns that work across models, across tasks, and across the inevitable next version of whatever you’re using today.
This guide walks through ten of those patterns. Each one has a name, a structure, an example, and a “use it when” rule. By the end you’ll have a working toolkit you can reach for without thinking, plus a framework for inventing your own.
If you’re completely new to prompting and want the basics first (what a prompt is, why it matters, what a token is), AI Foundations has a structured module on it. If you want to go deeper on the systems side, meaning how these patterns fit into RAG, agents, and full workflows, AI Systems covers that.
The premise: patterns, not magic
A prompt isn’t a spell. It’s a specification. The model is doing roughly what you’d do if you had a very capable, very literal junior assistant: read the spec, do the work, hand it back. Your job is to write a good spec.
The patterns below aren’t clever tricks. They’re disciplined ways of writing specs that turn out to work well across models. You’ll recognise most of them as good practice in any context: clear instructions, examples, constraints, context, format. The AI just makes the cost of bad prompts visible.
One framing before we start: every prompt has six building blocks. Role, task, context, format, constraints, and examples. Every pattern below is a different way of arranging those six blocks. Once you see that, you can invent patterns.
Pattern 1: The structured brief
Use it when: you’re asking for something non-trivial and you want consistent, reusable results.
The simplest pattern, and the one you’ll use most. State the role the model should play, the task you want done, the context it needs, the format you want back, the constraints that apply, and optionally an example.
Role: You're a senior product marketer writing for a B2B SaaS audience.
Task: Write a 150-word product description for our new analytics feature.
Context: The feature is "Cohort Insights." It tracks user retention by acquisition
channel. Our main competitors don't have this. Our audience is growth and
product teams at companies with 50–500 employees.
Format: Three short paragraphs. Lead with the benefit, then the mechanism,
then a one-line call to action. No bullet points.
Constraints: No jargon. Avoid "leverage," "unlock," and "seamless."
Don't mention competitors by name.
Example: [paste a previous description you liked]Why it works: it leaves nothing to interpretation. The model can’t guess wrong about audience, length, tone, or what to avoid. If you find yourself rewriting the same prompt over and over, this is the pattern to invest in.
The structured brief also ages well. Six months from now, when you’re reaching for the same prompt, you’ll still know what every line was for. A clever one-liner feels fun in the moment and turns into a black box the third time you use it.
Pattern 2: The example-driven spec
Use it when: you want a specific style or structure and you can show rather than tell.
Models are pattern matchers. Three good examples will outperform three paragraphs of style guidance. When the format or tone is hard to describe, show it.
Here are three customer-support reply openings I like. Match this tone and
structure for the new ticket below.
Example 1: [paste]
Example 2: [paste]
Example 3: [paste]
New ticket: [paste customer message]
Reply: [model writes]The examples do the work. “Match this tone” is the instruction; the examples are the definition. This is why teams that maintain a prompt library of “good outputs” get better results than teams that maintain a prompt library of “good instructions.” The output is the spec.
Pattern 3: The constraint sandwich
Use it when: the model is producing what you want but with too much fluff, hedging, or filler.
Most “AI sounds like AI” complaints are constraint failures. The model defaulted to a generic style because you didn’t specify a different one. Fix it by stating the constraints twice, once before the task and once after.
Write a 100-word product update email announcing our new dashboard.
Constraints: under 100 words, no adjectives not earned by a fact, no exclamation
marks, no "we're excited to announce," no marketing clichés. Lead with what
changed for the user, not what the company did.
After drafting, re-read your draft and remove any sentence that doesn't carry
new information.
Update email:The closing “remove any sentence that doesn’t carry new information” is doing real work. It’s a self-review instruction baked into the prompt. Try it once and you’ll see why every prompt in this guide ends with a quality gate.
Pattern 4: The chain of thought
Use it when: the task involves reasoning, math, planning, or any multi-step thinking.
The simplest chain-of-thought pattern is just asking the model to think out loud before answering.
Before answering, write out your reasoning step by step. Then give your
final answer.
Question: [paste]For most models, this is a free 10–30% accuracy boost on anything non-trivial. The reason is mechanical: the model is generating tokens sequentially, and forcing it to spend tokens on intermediate reasoning gives it room to catch its own errors.
You can also direct the shape of the reasoning. “List assumptions, then check each one against the data” produces different output from “think step by step then answer.” When the model is reasoning in a domain where you know the right structure (root cause analysis, risk assessment, debugging), telling it the structure usually beats telling it to think freely.
Variations worth knowing:
- “Think step by step, then check your work.” Forces a second pass.
- “Plan first, then execute, then verify.” Three phases for complex tasks.
- “What would change your answer? Then re-answer.” Useful for forecasting and estimation.
The mistake people make with chain of thought is asking for the reasoning and then ignoring it. Read it. The model will often catch a bad assumption in the middle of its own reasoning, and that’s the value.
Pattern 5: The role + persona
Use it when: the model needs to produce domain-specific output (legal, medical, financial, technical, etc.) and you can’t provide enough context to substitute.
The “you are a…” opener isn’t magic, but it’s a useful pointer for the model. It tells the model which slice of its training data to lean on.
You are a senior financial analyst at a mid-market PE firm. You're reviewing
a portfolio company's quarterly results before the partner meeting.
Draft a 200-word summary of the attached numbers, structured for an LP update.The role works best when combined with Pattern 1 (structured brief). On its own it’s mostly cosmetic. With structure, format, constraints, and audience context attached, it becomes a real spec.
A useful guardrail: don’t pick a role that lets the model off the hook for accuracy. “You are a confident expert” can produce confident hallucinations. “You are a careful expert who flags uncertainty” produces more reliable output. The role shapes the tone of the uncertainty, not the uncertainty itself.
Pattern 6: The multi-pass refinement
Use it when: the first output is 80% right and you need a reliable way to get to 95%.
One prompt is rarely the final draft. The pattern is to plan for refinement explicitly.
Pass 1: Draft. Use Pattern 1 to get a structured first draft. Pass 2: Critique. “Critique this draft. What’s weak? What’s missing? What’s over-explained?” Pass 3: Rewrite. “Rewrite using only the critique that improves the result.” Pass 4: Tighten. “Cut 20% of the length without losing any information.”
You can do this in one prompt:
Draft a [deliverable].
Then critique your draft for [criteria].
Then rewrite based on the critique.
Then shorten by 20% without losing information.
Final version only:For high-stakes work (a board memo, a customer-facing document, a published post), the four-pass version is worth the extra tokens. For routine work, even pass 2 + pass 3 pays for itself.
Pattern 7: The format lock
Use it when: you need parseable, structured output (a table, JSON, a CSV, a list with specific fields).
Most models default to prose. If you want a table, ask for a table. If you want JSON, give the schema. If you want a CSV, specify the columns.
Output a Markdown table with columns: Customer, Plan, Last Login, Risk Score.
Use "—" for missing values. Sort by Risk Score descending.
Data: [paste]Or for parseable output:
Return a JSON array of objects with these fields: name (string), category
(one of "bug," "feature request," "question"), urgency (one of "low," "medium,"
"high"). Include only the items mentioned in the input.
Input: [paste customer feedback]
Output:Format locks fail when you forget to specify what to do with missing data, ambiguous cases, or items that don’t fit the schema. Add a one-line “if data is missing, write ’—’; if the category is unclear, choose the closest match” and your error rate drops by half.
A second common failure: asking for JSON in prose and getting JSON embedded in a sentence that explains the JSON. Be explicit: “Output only the JSON. No prose before or after. No code fences.” The cleaner your format lock, the less post-processing you’ll do.
Pattern 8: The context stack
Use it when: the model needs more than the immediate prompt: relevant documents, prior conversation, background knowledge.
Most production AI tools are really good at this because RAG does the work for you (see What is RAG? for the pattern). When you’re prompting directly, the equivalent is to attach the relevant context explicitly.
I'm going to paste three documents. Treat them as the source of truth for
this conversation. Don't use any other knowledge to override them.
Document 1: [paste]
Document 2: [paste]
Document 3: [paste]
Now answer: [paste question]The discipline: say what the documents are, say the model should treat them as authoritative, and say what to do when they conflict. Without those three lines, the model will sometimes lean on its training data instead of the documents, and you’ll get confident-sounding answers that contradict the source.
For long-running work, the equivalent is a “context preamble” you paste at the start of every conversation: who the user is, what the project is, what the model’s role is, what style to use. This is one of the cheapest quality improvements available.
Pattern 9: The negative prompt
Use it when: the model is producing what you don’t want, repeatedly, and you can’t get it to stop with positive instructions alone.
Sometimes the fastest path to a good output is naming the bad outputs you want to avoid.
Write a customer testimonial template for a B2B SaaS company.
Avoid: marketing buzzwords ("game-changer," "revolutionary," "cutting-edge"),
vague claims ("saved us so much time"), generic openings ("In today's
fast-paced business world"), hyperbolic adjectives ("absolutely amazing").The pattern works because most of what makes AI output feel like AI output is a small number of overused defaults. Name them, and the model has a target to avoid. This pairs well with Pattern 3 (constraint sandwich): the constraint sandwich is for length and fluff, and the negative prompt is for specific recurring failures.
Keep a running list of “things I keep having to ask the model not to do.” After a few weeks you’ll have a personal style guide that you can paste into any prompt.
Pattern 10: The verification loop
Use it when: the output matters and being wrong is expensive.
The pattern is to make verification part of the prompt, not a separate step.
Answer the question below.
After answering, do the following:
1. Identify the single claim in your answer most likely to be wrong.
2. State what would have to be true for that claim to be wrong.
3. Re-state your answer with appropriate uncertainty.
Question: [paste]Or for a structured deliverable:
Produce the analysis below.
Before finalizing, run this check:
- Every numeric claim is sourced from the input data
- Every recommendation is grounded in a finding, not an assumption
- Every assumption is named as an assumption
- The conclusion follows from the body, not from a generic template
If any check fails, revise. Output only the final version.This is the pattern that separates “I use AI for some stuff” from “I use AI for high-stakes work.” Verification is built in, not bolted on. Most errors from AI use aren’t hallucinations; they’re unverified outputs. A verification loop catches most of them.
Choosing the right pattern
You don’t use all ten at once. Most prompts combine two or three. A useful heuristic:
- Single task, low stakes: Pattern 1 (structured brief) is enough.
- Style or format matters: add Pattern 2 (example-driven).
- The model is hedging or rambling: add Pattern 3 (constraint sandwich) or Pattern 9 (negative prompt).
- The task involves reasoning: add Pattern 4 (chain of thought).
- You need a specific persona or domain voice: add Pattern 5 (role).
- The output is going to a customer, a board, or the public: add Pattern 6 (multi-pass refinement) and Pattern 10 (verification loop).
- The output needs to be machine-readable: add Pattern 7 (format lock).
- The model needs more than the immediate prompt: add Pattern 8 (context stack).
The deeper question, when to use prompting at all versus RAG versus fine-tuning, is what AI Systems covers end-to-end. Prompting is the right starting point for almost everything. RAG is the right next step when the model needs to know things it wasn’t trained on. Fine-tuning is for niche cases when neither prompting nor RAG is enough. That diagnostic (prompting first, RAG second, fine-tuning rarely) saves most teams months of misdirected work.
A note on what’s changed
The “prompt engineering is dead” discourse is mostly a reaction to the fact that small, fiddly prompt tweaks matter less than they did a year ago. Models are smarter: they tolerate vague instructions, infer format from context, and follow complex multi-step instructions better than they did a year ago.
That doesn’t mean patterns are dead. It means the floor has risen. The patterns that matter now are the durable ones: structured briefs, examples, constraints, chain of thought, verification. These will outlive whatever model is on the front page of the news this month.
If you want to build this skill properly, as a working vocabulary you reach for without thinking rather than a list of tricks, AI Foundations has a structured module on prompting fundamentals. If you want to take it into production systems, AI Systems is the natural next step.
Both are self-paced, lifetime-access, and built for people who don’t write code. Pick the one that matches where you are.
Have a prompt pattern you reach for that I didn’t cover? Tell us; the best ones usually come from practitioners who’ve found something that works in their domain.