This kicks off Tier 2: Building Blocks — the next module after GenAI Foundations. ← Previous: Prompting Fundamentals (Foundations)

Back in Foundations, we covered the basics of prompting: be specific, show examples, treat the model like a capable-but-literal intern. That’s still true and still the foundation everything here builds on. But there’s a gap between “write a clear prompt” and “write the kind of prompt an experienced practitioner reaches for by habit.” That gap has a name: prompt engineering patterns — reusable techniques with actual names, because they solve specific, recurring problems.

Most people prompt like they’re typing into a search bar — a few keywords, hope for the best. The patterns below are what separates that from actually engineering the interaction.

Chain-of-Thought: Make It Show Its Work

Ask a model a multi-step reasoning question directly, and it sometimes jumps straight to an answer — skipping steps the way a rushed student does, and getting things wrong the same way.

Chain-of-thought prompting simply asks the model to reason step by step before answering.

“A store had 120 items. They sold 45% on Monday and 30 more on Tuesday. How many are left? Think through this step by step before giving your final answer.”

flowchart LR
    A[Direct question] --> B[Model jumps to<br/>an answer]
    C[Question + 'think step by step'] --> D[Model reasons through<br/>each step, then answers]

This works because of something we covered back in Foundations article 2: the model predicts one token at a time, using everything written so far — including its own output. Forcing it to write out reasoning first means each later step is conditioned on correct earlier steps, instead of the model trying to leap straight to a final number with nothing to check itself against.

Role Prompting: Give It a Lens, Not Just a Task

Telling a model who to be while answering shapes the response more than you’d expect.

“You are a senior security engineer reviewing this code for vulnerabilities.”

versus just:

“Review this code.”

The role doesn’t grant the model new knowledge — it’s still the same underlying model. What it does is narrow which parts of its training the response draws from, and shift tone, priorities, and vocabulary accordingly. A “senior security engineer” framing surfaces different concerns than a “helpful coding assistant” framing would, even reviewing the exact same code.

Self-Consistency: Don’t Trust the First Answer Alone

For questions with real ambiguity or reasoning risk, running the same prompt multiple times and comparing answers catches mistakes a single pass would miss.

flowchart TD
    A[Same prompt] --> B[Run 1: answer A]
    A --> C[Run 2: answer A]
    A --> D[Run 3: answer B]
    B --> E{Most common<br/>answer wins}
    C --> E
    D --> E
    E --> F[Final answer: A]

This isn’t something you’d do for every casual question — it’s a deliberate technique for high-stakes or error-prone tasks, where the cost of running the prompt a few extra times is worth catching an inconsistent or wrong result before it reaches a user.

Few-Shot, Revisited: Pattern Matching Over Description

We introduced few-shot prompting in Foundations, but it’s worth revisiting here as a pattern in its own right, because experienced practitioners lean on it constantly, not just as a beginner technique. Instead of describing a format, style, or edge case in words, you show 2-3 examples of exactly the input-output pairs you want. This matters most for tasks with a very specific output shape — a particular JSON structure, a house style, a classification scheme with unusual categories — where description alone leaves too much room for the model to guess wrong.

Putting Patterns Together

These aren’t exclusive choices — real prompts often combine them. A role-prompted, chain-of-thought request with a couple of few-shot examples baked in isn’t overkill for a high-stakes task; it’s normal practice. The pattern to build is: start simple, add a technique only when you see the specific failure it fixes. Chain-of-thought for reasoning errors. Role prompting for tone or focus drift. Self-consistency for tasks where being wrong is costly. Few-shot for rigid output formats.

Mental Model

Think of these patterns as tools on a belt, not a checklist to run through every time. A plain, well-specified prompt (from Foundations) is still your default — reach for chain-of-thought when the task involves reasoning, a role when tone or perspective matters, self-consistency when correctness is critical enough to check twice, and few-shot when the output shape is too specific to describe in words. You’re not making prompts fancier for its own sake — you’re matching the technique to the actual failure mode you’re trying to prevent.

Key Takeaways

  • Chain-of-thought prompting asks the model to reason step by step, reducing errors on multi-step problems.
  • Role prompting shifts tone and focus by telling the model who to be, without adding new knowledge.
  • Self-consistency runs a prompt multiple times and compares answers — useful for high-stakes or error-prone tasks.
  • Few-shot prompting (from Foundations) remains one of the most reliable patterns for locking down a specific output format.
  • None of these replace clear, specific prompting — they’re added on top of it, only when you see the specific problem they’re built to solve.

Next up in Tier 2: Getting Reliable Structured Output from LLMs — why “just ask for JSON” isn’t enough, and what actually works.