Chain-of-Thought, few-shot, role assignment, self-consistency. What the research says, what the 2025 Wharton study found that complicates the consensus, and how to use each one without wasting tokens.
The original article this was meant to improve contained the instruction “Expand each step with examples, pros/cons, and concepts — aiming for depth (500+ words here)” — never deleted, published as-is. I found it on first read. So let’s start over with something actually useful.
Prompt engineering has a real research foundation. It also has a lot of vibes-based advice that circulates endlessly because it sounds authoritative. I’m going to separate those. Every technique below has a named source. Where the research is contested or nuanced, I’ll say so — because the 2025 data complicates some of what’s been confidently asserted about Chain-of-Thought for the past three years.
- What actually causes bad outputs
- Chain-of-Thought — proven, but not universally
- Zero-shot vs. few-shot — the real tradeoff
- Role assignment — when it helps, when it doesn’t
- Self-consistency — for when accuracy matters more than speed
- Structural principles that apply to everything
- Common mistakes worth naming specifically
- A prompt workflow you can actually reuse
Before techniques, a diagnostic. Most bad AI outputs trace to one of four things:
Ambiguity in the goal. “Write a marketing email” is not a goal. “Write a 200-word re-engagement email for customers who haven’t purchased in 90 days, tone conversational, single CTA to a 20%-off landing page” is a goal. The difference in output quality is not subtle.
Missing context the model needs but you forgot to include. You know your audience is enterprise IT managers. The model doesn’t, unless you say so. You know the previous version of this document was rejected for being too technical. The model doesn’t.
Format mismatch. You wanted a table. The model gave you prose. This is almost always solvable by specifying the format explicitly, not by rewording the content request.
Wrong tool for the task. Chain-of-Thought helps with multi-step reasoning. It does not help with generating creative marketing copy or extracting structured data from text. Using the right technique for the wrong task doesn’t just fail to help — it can actively hurt, as the 2025 Wharton research shows.
The honest summary
Per Lakera’s 2026 guide: “Clear structure and context matter more than clever wording — most prompt failures come from ambiguity, not model limitations.” That’s the whole thing. Every technique below is in service of reducing ambiguity in a specific way.
02 —Chain-of-Thought: Proven, But Not Universally
Chain-of-Thought is the most researched prompting technique that exists. Wei et al. (2022) showed that prompting a 540B-parameter model with just eight reasoning-chain exemplars achieved state-of-the-art accuracy on the GSM8K math benchmark — surpassing even fine-tuned GPT-3 with a verifier. The original finding is real. Eight examples. State-of-the-art math. That’s striking.
But here’s the 2025 update that most prompt engineering guides still haven’t processed. The Wharton Generative AI Lab (Meincke, Mollick, Mollick, Shapiro, June 2025) found that CoT requests require 20–80% more time and significantly more tokens — for often negligible gains in accuracy on modern reasoning models. On Gemini Flash 2.5, CoT actually decreased performance at the 90% and 100% accuracy thresholds by 7–13%.
The nuance: CoT helps non-reasoning models on tasks that require multi-step logic they wouldn’t otherwise work through. It provides smaller-to-no benefit on models that already reason by default (o3, o4-mini, Claude 3.5+), and can introduce variability that causes errors on questions those models would otherwise answer correctly.
The zero-shot version of CoT — just appending “Let’s think step by step” to your prompt — was established by Kojima et al. (2022). It works on a wide range of tasks without requiring you to construct examples. Start here before building out few-shot exemplars.
# What you're doing: eliciting step-by-step reasoning without examples Task: A subscription starts at $120/year. After year one, it increases 15%. After year two, it increases another 8%. What is the cost in year three? Instruction: Work through this step by step before giving the final answer.
# What you're doing: showing the model the reasoning pattern you want, # not just the answer format Example 1: Q: If a server processes 1,200 requests/hour and 3% fail, how many fail per day? Reasoning: 1,200 requests/hour × 24 hours = 28,800 requests/day. 28,800 × 0.03 = 864 failures/day. A: 864 failures per day. Now answer: Q: If a server processes 850 requests/hour and 4.5% fail, how many fail per day? Reasoning:
03 —Zero-Shot vs. Few-Shot: The Actual Tradeoff
Few-shot prompting provides 2–5 examples in your prompt to teach the model a pattern through demonstration rather than instruction. The foundational result is from Brown et al. (2020) — GPT-3’s original paper — which showed strong accuracy gains from the first 1–2 examples, with diminishing returns beyond 4–5. More examples costs tokens linearly. Accuracy gains flatten. Quality of examples matters more than quantity.
What few-shot is actually good at: enforcing output format. If you need JSON, YAML, a specific table structure, a particular tone — showing the model two or three examples of exactly what you want is almost always faster than trying to describe it in words. The model pattern-matches to your examples in ways that abstract description rarely achieves.
The 2025 research update: a fact-checking study at COLING 2025 (Pisarevskaya & Zubiaga) found that just 10 well-chosen few-shot examples allowed a Gemini-1.5 model to nearly match a fine-tuned specialist classifier’s F1 score — 95% vs 96.2%. That’s a meaningful result: few-shot with good examples can approximate fine-tuning for some tasks.
# What you're doing: enforcing JSON structure through demonstration, # not through describing the schema Example 1: Input: "Sarah joined Anthropic as a research scientist in March 2024." Output: {"name": "Sarah", "company": "Anthropic", "role": "Research Scientist", "date": "March 2024"} Example 2: Input: "Mark left his position at Google DeepMind last quarter." Output: {"name": "Mark", "company": "Google DeepMind", "role": null, "date": "last quarter"} Now extract: Input: "Dr. Wright was appointed CTO of Stripe in February." Output:
“Bad examples hurt worse than zero examples. The model pattern-matches to what you show it — including your mistakes. Start zero-shot, add examples only when zero-shot fails at something specific.”
Editorial synthesis — sources: Brown et al. (2020) GPT-3 paper; Mem0 few-shot prompting guide (2026); IBM zero-shot vs. few-shot analysis
04 —Role Assignment: When It Helps, When It’s Theater
“Act as a senior data engineer with 15 years of experience in distributed systems.” You’ve seen this. It works — sometimes. Here’s what’s actually happening and when it stops working.
Role assignment primes the model to weight certain vocabulary, reasoning patterns, and knowledge domains more heavily. If you’re asking about database optimization, “act as a senior DBA” genuinely shifts the response toward more technical depth and domain-appropriate assumptions. That’s useful.
Where it becomes theater: generic role assignments on specific tasks. “Act as an expert” without specifying what kind of expertise, for what audience, with what constraints — that’s noise. The model already knows it’s supposed to try its best. Vague role assignment doesn’t add information; it just takes up tokens and makes you feel like you did something.
The more effective pattern: instead of assigning a role, assign a perspective and audience. “Explain this as if to a non-technical product manager who needs to present it to the board” is more constraining and more useful than “act as an expert communicator.”
# VAGUE — adds little value Act as an expert and explain machine learning to me. # SPECIFIC — actually constrains the response usefully Explain gradient descent to a software engineer who understands Python but has no statistics background. Use a concrete code analogy rather than mathematical notation. Aim for 200 words. # PERSPECTIVE + AUDIENCE (often more effective than role) You're explaining this to a CFO who asked "why is our ML model suddenly less accurate?" She understands P&L but not model drift. Give her a plain-English diagnosis and one concrete next step.
05 —Self-Consistency: For When Accuracy Matters More Than Speed
Self-consistency was established by Wang et al. (2022): generate multiple responses to the same question using different reasoning paths, then select the most consistent answer across those paths. It’s majority voting applied to reasoning chains.
This works because language models are stochastic — the same prompt with the same model produces slightly different reasoning paths across runs. Some paths land on the right answer for the right reasons. Some land on the right answer for wrong reasons. Some get it wrong. The consistent answer across multiple independent attempts is more likely to be correct than any single attempt.
The cost: you’re making multiple API calls for the same output. If you’re doing this at scale, token costs multiply directly. This technique makes sense for high-stakes decisions — medical interpretation, financial analysis, legal reasoning, anything where the cost of a wrong answer exceeds the cost of extra API calls.
In practice without API access: you can manually implement this by asking the same question three different ways and seeing where the answers converge. Tedious. But for a decision that matters, worth it.
06 —Structural Principles That Apply to Everything
These aren’t techniques with catchy names. They’re just practices that consistently improve output regardless of what technique you’re using on top.
Specify output format explicitly
Don’t describe the format you want — show it, or name it unambiguously. “Respond in bullet points” is ambiguous (how many? how long? nested or flat?). “Respond with exactly 5 bullets, each under 20 words, no sub-bullets” is not.
# Vague format instruction Summarize this in a useful format. # Specific format instruction Summarize this as: - 2-sentence executive summary - 3 bullet points: key findings (1 sentence each) - 1 bullet point: recommended next action Total length: under 120 words.
Use delimiters to separate input from instruction
When your prompt contains both instructions and data to process, separate them clearly. Without delimiters, the model can conflate the two — especially with longer inputs.
Instructions: Classify the sentiment of the customer review below as Positive, Negative, or Mixed. Return only the classification label. Review: """ The product itself is excellent and arrived on time. But the packaging was damaged and customer support took five days to respond to my complaint. """
Iterate in small steps, not big rewrites
When a prompt isn’t working, change one thing at a time. If you rewrite the whole prompt, you don’t know what fixed it (or broke something else). Change the format specification. Test. Change the context. Test. This is how you build prompts that you understand and can maintain.
Negative constraints are underused
Telling the model what not to do is often more effective than trying to specify every positive constraint. “Don’t use bullet points,” “Don’t hedge with phrases like ‘it’s important to note’,” “Don’t summarize what I already told you — start from the analysis.” These negative constraints carve out the behavior space you want more efficiently than adding more positive instructions.
—Technique Reference
| Technique | Best for | Evidence base | ⚠ Honest limitation |
|---|---|---|---|
| Zero-shot CoT “Let’s think step by step” |
Multi-step reasoning, math, logical deduction | Kojima et al. 2022; Wei et al. 2022 | Adds 20–80% more tokens/time; negligible benefit on o3/o4-mini/Claude 3.5+ which reason by default (Wharton, 2025) |
| Few-shot 2–5 examples in prompt |
Format enforcement; consistent output structure; classification | Brown et al. 2020 (GPT-3); Pisarevskaya & Zubiaga, COLING 2025 | Diminishing returns after 4–5 examples; bad examples actively hurt; token cost scales linearly with example count |
| Role / Persona “You are a…” |
Domain-specific depth; audience-calibrated explanation | Documented in Google Cloud prompt design; Lakera 2026 | Generic role assignments add noise, not signal; perspective + audience framing often more effective than role assignment alone |
| Self-Consistency Multiple runs → majority vote |
High-stakes analytical tasks where accuracy > cost | Wang et al. 2022 (arXiv:2203.11171) | Multiplies API costs directly; overkill for most tasks; manual implementation is tedious |
| Format specification Explicit output constraints |
Any task where structure matters | Consistent finding across all major prompt engineering guides | Over-constraining format can limit useful information — leave some flexibility for complex outputs |
07 —Common Mistakes Worth Naming Specifically
Using CoT on a model that already reasons by default. If you’re using o3, o4-mini, Claude 3.5 Sonnet, or Gemini 2.5 — these models reason by default. Adding “let’s think step by step” to your prompt is the equivalent of telling a professional violinist to make sure they use a bow. They know. You’re just adding tokens.
Building complex prompts before testing simple ones. I’ve watched people spend two hours engineering an elaborate few-shot prompt when zero-shot with clear constraints would have worked fine. Test zero-shot first. Always. Add complexity only when you identify what specifically fails.
Thesis-complicating finding
The 2025 Wharton study found that CoT prompting, for some tasks and models, can decrease accuracy on questions the model would otherwise answer correctly. The mechanism: requesting explicit reasoning can introduce variability that causes the model to second-guess answers it had right. So “add CoT to improve accuracy” is not a universally safe assumption — it depends on the model and task type. SSRN:5285532; Wharton GAIL June 2025
Treating prompts as one-and-done. The model changed. The task changed. Your requirements changed. A prompt that worked in January on GPT-4o may produce different results in April on GPT-4.1. Prompts need version control and periodic testing the same way code does.
No negative constraints. Most prompts tell the model what to do. The most useful prompts also tell it what not to do. If you know the failure mode — the model always hedges with “it’s important to note,” it always ends with a summary you didn’t ask for, it always formats as bullets when you want prose — put that in the prompt as a negative constraint. Explicitly.
08 —A Prompt Workflow You Can Actually Reuse
This isn’t a framework with an acronym. It’s just the order of things to specify, derived from what most commonly causes output to fall short.
# 1. CONTEXT (what the model needs to know that it doesn't by default) [Background: audience, situation, what came before, relevant constraints] # 2. TASK (what you want done — specific, not vague) [Action verb + object + success criteria] # 3. FORMAT (how you want the output structured) [Specific format: length, structure, style, what to include and exclude] # 4. NEGATIVE CONSTRAINTS (what failure modes to avoid) [Don't include X. Don't use format Y. Don't hedge with phrase Z.] # 5. EXAMPLES (only if format enforcement is critical) [1–3 examples of exactly the output you want] # 6. REASONING TRIGGER (only if multi-step logic is required) [Work through this step by step before giving your final answer.]
Not every prompt needs all six. Simple tasks: context + task + format. Complex analytical tasks: all six. Start with fewer elements, add what’s missing based on what the output gets wrong.
Cross-source synthesis
Combining the Wei et al. 2022 findings, the 2025 Wharton CoT study, and the Brown et al. few-shot research produces a conclusion that doesn’t appear cleanly in any single source: the optimal prompting strategy in 2026 is model-dependent in a way that wasn’t true in 2022. In 2022, CoT was almost universally beneficial on reasoning tasks because most models didn’t reason by default. In 2026, models with built-in reasoning (o3, o4-mini, Claude 3.5+) have changed this calculus — CoT adds cost for marginal or negative benefit on those models, while remaining useful on smaller or non-reasoning models. The single prompting playbook has fragmented into model-specific strategies.
—What This Means For Your Situation
For: Individual Knowledge Workers
Stop trying to “engineer” prompts. Start specifying clearly.
The word “prompt engineering” makes people think there are secret techniques to unlock. There aren’t. The biggest gains come from being specific about what you want, in what format, for what audience, with what constraints. That’s it. Start there before you try anything on the techniques list above.
What you do: For the next five prompts you write, add one explicit format constraint and one negative constraint. “In bullet points” is not a format constraint. “In exactly five bullet points, each under 15 words, no sub-bullets” is.
Stop doing this: Stop writing long preambles about context that doesn’t affect the output. “As a marketer at a SaaS company in the B2B space who works with enterprise clients…” — if none of that changes what you’re asking for, cut it. Specificity that matters beats length.
For: Teams Building AI-Powered Products
Prompts are code. Treat them that way.
System prompts that go into production need version control, testing, and regression checks. A prompt that worked last month on GPT-4o may behave differently on GPT-4.1. If you’re not tracking prompt versions alongside model versions, you have no way to attribute when something changes.
What you do: Before the next model update you deploy to, run your top 20 test cases against the new model with your existing prompts. Compare outputs. Document what changed. This takes a few hours and will save you from discovering regressions through user complaints.
Stop doing this: Stop treating CoT as a universal accuracy improvement. If you’re using reasoning models (o3, o4-mini, Claude 3.5+), test whether CoT actually helps on your specific task type before adding it to every system prompt. Per the 2025 Wharton research, it adds 20–80% response time for often negligible or negative gains on these models.
—Honest Summary
The techniques that have real research support: CoT on multi-step reasoning tasks with smaller models, few-shot for format enforcement, self-consistency for high-stakes accuracy. These aren’t magic. They’re specific tools for specific problems.
The stuff that doesn’t have strong evidence: generic role assignment (“act as an expert”), vague reasoning triggers on models that already reason, complex frameworks with acronyms that mostly just dress up “be specific about what you want.”
The 2025 update that changes the calculus: if you’re using a reasoning model, CoT’s value proposition has mostly evaporated. The model is already doing what CoT was designed to elicit. Check what you’re running on before copying prompting advice written in 2022.
That’s the honest version.
