Practical Patterns
Role-play, Constraints, Step-Back & more
The Problem: You know Chain-of-Thought and Few-Shot, but everyday tasks often need simpler, more targeted patterns — role assignment, constraints, or reframing the question.
The Solution: 8 Practical Patterns for Every Day
These patterns are the building blocks of prompt engineering — small, reusable instructions you bolt onto almost any request to steer the model's behavior. Unlike heavyweight methods such as Chain-of-Thought or Few-Shot, each pattern targets one specific failure mode: Role-Playing activates the right domain knowledge by telling the model who it is, Constraints pin down length, format, and style so the output is usable as-is, Negative Instructions rule out the mistakes you keep seeing, and Step-Back forces the model to name the general principle before diving into the specific case.
How they work
An LLM predicts the next token from everything in its context, so the words you put in the prompt literally shift the probability distribution of the answer. A role like "You are a senior security engineer" biases the model toward the vocabulary, caveats, and reasoning style that appear near that phrase in its training data — you are not giving it new knowledge, you are selecting a region of what it already knows. Constraints work the same way: stating "answer in exactly three bullet points, no preamble" makes those tokens far more likely than a rambling essay. This is why the patterns are cheap and composable — they cost a handful of extra tokens and can be stacked. The main pitfall is over-constraining: pile on ten rules and the model starts dropping some, so add constraints incrementally and keep only the ones that change the output. Negative instructions can also backfire by priming the very thing you forbid ("don't mention price" plants the word "price"); prefer stating the positive behavior you want instead.
A worked example
Suppose a bare prompt "Review this function" returns a vague, encouraging paragraph. Layer the patterns: a role ("You are a senior Go reviewer"), a constraint ("list at most five issues, ordered by severity, each one line"), and a step-back ("first state what this function is supposed to guarantee, then check it against that"). The same model now produces a prioritized, concrete review. Start by mastering each pattern in isolation so you can tell which one fixed the output, then combine them — that habit is what separates reliable prompting from trial-and-error.
Think of it like a toolkit where each tool has its purpose:
- 1. Role-Playing: Assign expertise — "You are a senior engineer"
- 2. Constraints: Set boundaries — length, format, style
- 3. Step-Back: Start from principles, then solve
- 4. Rephrase & Respond: Let AI reinterpret for better accuracy
Where Are These Used?
- Daily prompting: Quick, targeted improvements to any prompt
- Content creation: Roles + Constraints for consistent quality
- Code review: Persona + Negative Instructions for thorough analysis
- Research: Step-Back + Emotion Prompting for deeper insights
Fun Fact: Research shows that adding emotional appeals like "This is very important to my career" can improve LLM performance by 8-10% on some tasks! This is called EmotionPrompt.
Try It Yourself!
Explore each pattern in the interactive example below and try the prompt templates.
8 simple but powerful patterns for everyday work with LLMs. Each solves a specific problem — select a pattern to learn more!
Role-Playing / Persona
Ask the model to "become" an expert in the relevant field
Model takes on a role and answers from that character's perspective, using relevant knowledge and style.
"You are a senior developer with 15 years of experience. Conduct a code review..."
SQL queries can be optimized in many ways. Use indexes, avoid SELECT *, optimize JOINs... (generic advice without depth)
As a DBA with 15 years experience: 1) EXPLAIN ANALYZE — profile first. 2) Covering indexes reduce IO by 80%. 3) For N+1 use batch loading. Example: CREATE INDEX idx_orders_user ON orders(user_id) INCLUDE (total);
| Pattern | When to use | Complexity |
|---|---|---|
| Role-Playing / Persona | Expert tasks, consulting | 1/3 |
| Constraint Prompting | Formatting, brevity | 1/3 |
| Negative Instructions | Style control, error avoidance | 1/3 |
| Step-Back Prompting | Learning, conceptual understanding | 2/3 |
| Directional Stimulus | Content steering, key topics | 2/3 |
| Graph Prompting | Dependency analysis, systems thinking | 3/3 |
| Emotion Prompting | Quality boost, detail increase | 1/3 |
| Rephrase and Respond | Ambiguous questions, accuracy | 2/3 |
These patterns are the building blocks of prompting. Master each one individually, then combine them for maximum effect (see the "Combining Techniques" lesson).
Frequently asked questions
What are prompting patterns and why do they matter?
Prompting patterns are small, reusable instructions you add to almost any request to steer the model. Each targets one failure mode: Role-Playing activates the right domain knowledge, Constraints pin down length, format, and style, Negative Instructions rule out repeated mistakes, and Step-Back forces the model to name a general principle before solving. They cost only a few extra tokens and can be stacked together.
How is role-playing different from few-shot and chain-of-thought?
Few-shot supplies examples and Chain-of-Thought asks the model to reason step by step — both are heavyweight. Practical patterns like Role-Playing are lighter: they don't add knowledge, they bias the model toward a vocabulary and style it already learned. A role such as 'You are a senior security engineer' selects a region of what the model already knows, which makes patterns ideal for everyday tasks where full few-shot is overkill.
How do I use constraints effectively in a prompt?
State concrete boundaries — length, format, and style, e.g. 'answer in exactly three bullet points, no preamble'. Those words raise the probability of a usable, on-spec answer. The common mistake is over-constraining: pile on ten rules and the model starts dropping some. Add constraints incrementally and keep only the ones that actually change the output.
Why do negative instructions in prompts sometimes backfire?
A ban can prime the very thing you forbid: 'don't mention price' plants the word 'price' in the context, and since the model predicts the next token from everything present, that word becomes more likely. It's usually more reliable to state the positive behavior you want — describe what the model should do rather than what to avoid.
Try it yourself
Interactive demo of this technique
Explain Docker for a beginner developer
Sure! Great question! Docker is a containerization platform that uses OS-level virtualization via cgroups and namespaces. It allows packaging applications into isolated containers for deployment...
Docker is a "box" for your application. Imagine: you're moving and pack an entire room into one container — furniture, clothes, everything stays in place. At the new location you open the container and everything works as before.
Docker works the same way: it packages your code, libraries, and settings into one container. This container works identically on your laptop, your colleague's machine, and the server.
Try it: docker run -d -p 5432:5432 postgres — database ready in 3 seconds.
Negative Instructions ("DON'T") are often more effective than positive ones — they prevent specific mistakes that LLMs make by default (jargon, verbosity, template phrases).
Lesson Quiz
1.What does the Role-Playing / Persona pattern achieve?
Create a free account to solve challenges
4 AI-verified challenges for this lesson
This lesson is part of a structured LLM course.
My Learning Path