<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1655720828018-edd2daec9349?w=1600&amp;q=80"><h2 id="prompt-engineering-in-2026-beyond-few-shot--advanced-techniques-that-actually-work">Prompt Engineering in 2026: Beyond Few-Shot — Advanced Techniques That Actually Work</h2>Prompt engineering has matured from “write clearer sentences” to a discipline with measurable techniques and real benchmarks. In 2026, with models like Claude 4, GPT-5, and Gemini 2 Ultra deployed at scale, knowing which prompting strategy to use — and why — separates engineers who get 60% accuracy from those who get 90%.This post covers the techniques that consistently move the needle in production.<img src="https://images.unsplash.com/photo-1677442135703-1787eea5ce01?w=1200&amp;q=80" alt="Prompt engineering concept"> Photo by <a href="https://unsplash.com/@mottakin">Mojahid Mottakin</a> on Unsplash<hr><h2 id="why-prompting-still-matters-in-the-age-of-fine-tuning">Why Prompting Still Matters in the Age of Fine-Tuning</h2>“Just fine-tune the model” sounds reasonable until you calculate the cost. For most teams:<ul><li>Fine-tuning costs $500–$5,000+ per run</li><li>Prompting iteration costs minutes and a few API calls</li><li>Most use cases don’t need model-level knowledge — they need better reasoning</li></ul>Even when you do fine-tune, the base prompt still matters. The techniques below apply equally to base models and fine-tuned variants.<hr><h2 id="technique-1-chain-of-thought-cot--the-baseline">Technique 1: Chain-of-Thought (CoT) — The Baseline</h2>Chain-of-thought prompting tells the model to reason step by step before answering. It’s been published since 2022 but remains the single highest-ROI technique.<h3 id="basic-cot">Basic CoT</h3><div><pre><code>❌ Without CoT:
Q: A train leaves Chicago at 8am going 60mph. Another leaves Detroit 
at 9am going 80mph. Chicago to Detroit is 300 miles. When do they meet?

A: 10:30am ← often wrong

✅ With CoT:
Q: [same question]
Let's think step by step.

A: 
- Train 1: leaves Chicago 8am at 60mph
- Train 2: leaves Detroit 9am at 80mph, gap = 300 miles
- At 9am, Train 1 has traveled 60 miles → remaining gap = 240 miles
- Combined speed = 60 + 80 = 140 mph
- Time to close 240 miles = 240/140 ≈ 1.71 hours ≈ 1h 43m
- They meet at approximately 10:43am ✓
</code></pre></div><h3 id="zero-shot-cot">Zero-shot CoT</h3>You don’t always need examples. Just append <code>"Let's think step by step."</code> to any reasoning task.<div><pre><code>def add_cot(prompt: str) -&gt; str:
 return prompt + "\n\nLet's think step by step."
</code></pre></div>Benchmark improvement on GSM8K: ~40% → ~70% accuracy with zero-shot CoT on GPT-3.5 class models.<hr><h2 id="technique-2-self-consistency--majority-vote-over-reasoning-paths">Technique 2: Self-Consistency — Majority Vote Over Reasoning Paths</h2>Self-consistency samples multiple reasoning paths and takes the majority answer. It’s like running CoT multiple times and voting.<div><pre><code>import asyncio
from collections import Counter

async def self_consistent_answer(
 question: str, 
 n_samples: int = 5,
 temperature: float = 0.7
) -&gt; str:
 
 cot_prompt = f"{question}\n\nLet's think step by step."
 
 # Sample n independent reasoning paths
 tasks = [
 llm.invoke(cot_prompt, temperature=temperature) 
 for _ in range(n_samples)
 ]
 responses = await asyncio.gather(*tasks)
 
 # Extract final answers
 answers = [extract_final_answer(r) for r in responses]
 
 # Majority vote
 most_common = Counter(answers).most_common(1)[0][0]
 return most_common
</code></pre></div>When to use it: Complex math, multi-step logical reasoning, anything where the model is uncertain. Not useful for factual lookups or creative tasks.Cost tradeoff: 5x API calls for ~10-15% accuracy improvement. Worth it when accuracy is critical.<hr><h2 id="technique-3-tree-of-thought-tot--deliberate-exploration">Technique 3: Tree of Thought (ToT) — Deliberate Exploration</h2>Tree of Thought extends CoT by explicitly exploring multiple reasoning branches and evaluating them:<div><pre><code>Problem
 ├── Approach A
 │ ├── Step A1 → evaluate: promising ✓
 │ └── Step A2 → evaluate: dead end ✗
 ├── Approach B
 │ ├── Step B1 → evaluate: promising ✓
 │ │ └── Step B1.1 → SOLUTION FOUND
 └── Approach C
 └── evaluate: not viable ✗
</code></pre></div><h3 id="simplified-tot-implementation">Simplified ToT Implementation</h3><div><pre><code>async def tree_of_thought(problem: str, breadth: int = 3, depth: int = 3):
 
 # Generate initial approaches
 approaches_prompt = f"""
Problem: {problem}

Generate {breadth} different high-level approaches to solve this.
Format: numbered list, one sentence each.
"""
 approaches_text = await llm.invoke(approaches_prompt)
 approaches = parse_numbered_list(approaches_text)
 
 best_path = None
 best_score = 0
 
 for approach in approaches:
 # Evaluate each approach
 eval_prompt = f"""
Problem: {problem}
Approach: {approach}

Rate this approach's likelihood of success (1-10) and explain why.
Format: SCORE: X\nREASON: ...
"""
 evaluation = await llm.invoke(eval_prompt)
 score = extract_score(evaluation)
 
 if score &gt; best_score:
 best_score = score
 best_path = approach
 
 # Execute best path with CoT
 return await chain_of_thought_solve(problem, approach=best_path)
</code></pre></div>Best for: Creative problem-solving, multi-step planning, tasks with multiple valid strategies (not single-answer math problems where self-consistency is better).<hr><h2 id="technique-4-retrieval-augmented-generation-rag-prompt-design">Technique 4: Retrieval-Augmented Generation (RAG) Prompt Design</h2>RAG is table stakes in 2026, but most teams use it naively. The prompt structure matters enormously.<h3 id="naive-rag-common-mistake">Naive RAG (Common Mistake)</h3><div><pre><code>❌ Context:
[paste 10 retrieved chunks]

Question: What is the refund policy?
Answer:
</code></pre></div><h3 id="structured-rag-with-source-attribution">Structured RAG with Source Attribution</h3><div><pre><code>✅ You are a helpful customer support assistant.

RETRIEVED CONTEXT:
---
[Source 1 - FAQ, relevance: 0.94]
Refunds are processed within 5-7 business days...

[Source 2 - Policy Doc, relevance: 0.87] 
For purchases over $500, a manager approval is required...
---

INSTRUCTIONS:
- Answer using ONLY the provided context
- If the context doesn't contain the answer, say "I don't have that information"
- Cite which source supports your answer
- Be concise

QUESTION: What is the refund policy for a $600 purchase?
</code></pre></div><h3 id="relevance-filtering-before-prompting">Relevance Filtering Before Prompting</h3>Don’t stuff all retrieved chunks into the prompt. Filter first:<div><pre><code>def build_rag_prompt(query: str, retrieved_chunks: list, 
 min_score: float = 0.75) -&gt; str:
 
 relevant = [c for c in retrieved_chunks if c.score &gt;= min_score]
 
 if not relevant:
 return f"No relevant context found.\n\nQuestion: {query}"
 
 context_block = "\n\n".join([
 f"[Source {i+1} - score: {c.score:.2f}]\n{c.text}"
 for i, c in enumerate(relevant[:5]) # max 5 chunks
 ])
 
 return f"""CONTEXT:
{context_block}

Using only the above context, answer:
{query}

If the context doesn't contain the answer, say so explicitly."""
</code></pre></div><hr><h2 id="technique-5-constitutional-prompting">Technique 5: Constitutional Prompting</h2>Constitutional prompting embeds behavioral constraints directly in the system prompt. Instead of filtering outputs post-hoc, you guide the model’s generation:<div><pre><code>SYSTEM_PROMPT = """You are a financial analysis assistant.

CONSTITUTION:
1. Never make specific investment recommendations ("buy X" or "sell Y")
2. Always distinguish between historical data and forward projections
3. When citing statistics, mention the source and date if known
4. If asked about illegal activities, decline and explain why
5. Acknowledge uncertainty — avoid false confidence

STYLE:
- Be precise and data-driven
- Prefer tables and bullet points for comparative data
- Keep responses under 500 words unless detail is explicitly requested
"""
</code></pre></div>The “constitution” pattern makes behavior auditable. You can diff system prompts between versions and understand what changed.<hr><h2 id="technique-6-persona--context-injection">Technique 6: Persona + Context Injection</h2>Giving the model a specific role with relevant context consistently improves output quality:<div><pre><code>❌ Generic:
Summarize this code review.

✅ Persona-injected:
You are a senior software engineer with 10 years of experience in 
distributed systems. You are reviewing code for a team of mid-level 
engineers. Your feedback should be:
- Direct but constructive
- Focused on correctness first, style second
- Including specific line references when possible
- Prioritized (P1/P2/P3)

Review the following code:
[code]
</code></pre></div><hr><h2 id="technique-7-structured-output-forcing">Technique 7: Structured Output Forcing</h2>In 2026, most major models support JSON mode natively, but prompt design still matters for complex schemas:<div><pre><code>STRUCTURED_PROMPT = """Analyze the following customer feedback and extract:

REQUIRED OUTPUT FORMAT (strict JSON):
{
 "sentiment": "positive" | "negative" | "neutral",
 "topics": ["topic1", "topic2"], // max 5
 "urgency": 1-5, // 5 = immediate action needed
 "action_required": boolean,
 "suggested_action": "string or null if no action"
}

Rules:
- Return ONLY valid JSON, no prose
- urgency=5 only if customer threatens churn or legal action
- topics must be from: [billing, product, support, shipping, other]

FEEDBACK: {feedback_text}
"""
</code></pre></div>For complex outputs, show an example:<div><pre><code>EXAMPLE = """
Input: "I've been waiting 3 weeks for my order and nobody responds to emails"
Output: {
 "sentiment": "negative",
 "topics": ["shipping", "support"],
 "urgency": 4,
 "action_required": true,
 "suggested_action": "Escalate to fulfillment team, send apology email with tracking"
}
"""
</code></pre></div><hr><h2 id="prompt-evaluation-measuring-what-works">Prompt Evaluation: Measuring What Works</h2>Don’t iterate on vibes. Build an evaluation harness:<div><pre><code>class PromptEvaluator:
 def __init__(self, test_cases: list[dict]):
 self.test_cases = test_cases # [{input, expected_output}]
 
 async def evaluate(self, prompt_template: str) -&gt; dict:
 results = []
 for case in self.test_cases:
 prompt = prompt_template.format(**case["input"])
 response = await llm.invoke(prompt)
 score = self.score_response(response, case["expected_output"])
 results.append(score)
 
 return {
 "mean_score": sum(results) / len(results),
 "pass_rate": sum(1 for r in results if r &gt;= 0.8) / len(results),
 "samples": len(results)
 }
 
 def score_response(self, response: str, expected: str) -&gt; float:
 # Use LLM-as-judge or exact match depending on task type
 return llm_judge_score(response, expected)
</code></pre></div>Run this before and after every prompt change. A/B test prompts like you A/B test features.<hr><h2 id="choosing-the-right-technique">Choosing the Right Technique</h2><table><thead><tr><th>Task Type</th><th>Best Technique</th></tr></thead><tbody><tr><td>Math / logic reasoning</td><td>Self-Consistency &gt; CoT</td></tr><tr><td>Multi-step planning</td><td>Tree of Thought</td></tr><tr><td>Knowledge Q&amp;A</td><td>RAG + Structured Prompt</td></tr><tr><td>Code generation</td><td>CoT + Structured Output</td></tr><tr><td>Content moderation</td><td>Constitutional Prompting</td></tr><tr><td>Data extraction</td><td>Structured Output + Examples</td></tr><tr><td>Creative tasks</td><td>Persona + Context Injection</td></tr></tbody></table><hr><h2 id="conclusion">Conclusion</h2>The field has moved past “magic words.” In 2026, good prompt engineering means:<ol><li>Measuring outcomes with evaluation harnesses</li><li>Matching technique to task type — no one-size-fits-all</li><li>Treating prompts as code — version control, test coverage, changelogs</li><li>Layering techniques — CoT + structured output + persona often beats any single method</li></ol>The engineers who understand why techniques work will continue to outperform those cargo-culting patterns from blog posts. Start with measurement; let the numbers guide your iterations.<hr>Tags: AI, LLM, Prompt Engineering, Claude, GPT, Chain-of-Thought, RAG <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

Prompt Engineering in 2026: Beyond Few-Shot — Advanced Techniques That Actually Work
Prompt engineering has matured from “write clearer sentences” to a discipline with measurable techniques and real benchmarks. In 2026, with models like Claude 4, GPT-5, and Gemini 2 Ultra deployed at scale, knowing which prompting strategy to use — and why — separates engineers who get 60% accuracy from those who get 90%.
This post covers the techniques that consistently move the needle in production.
Photo by Mojahid Mottakin on Unsplash
Why Prompting Still Matters in the Age of Fine-Tuning
“Just fine-tune the model” sounds reasonable until you calculate the cost. For most teams:
Fine-tuning costs $500–$5,000+ per run
Prompting iteration costs minutes and a few API calls
Most use cases don’t need model-level knowledge — they need better reasoning
Even when you do fine-tune, the base prompt still matters. The techniques below apply equally to base models and fine-tuned variants.
Technique 1: Chain-of-Thought (CoT) — The Baseline
Chain-of-thought prompting tells the model to reason step by step before answering. It’s been published since 2022 but remains the single highest-ROI technique.
Basic CoT
❌ Without CoT:
Q: A train leaves Chicago at 8am going 60mph. Another leaves Detroit 
at 9am going 80mph. Chicago to Detroit is 300 miles. When do they meet?
A: 10:30am  ← often wrong
✅ With CoT:
Q: [same question]
Let's think step by step.
A: 
- Train 1: leaves Chicago 8am at 60mph
- Train 2: leaves Detroit 9am at 80mph, gap = 300 miles
- At 9am, Train 1 has traveled 60 miles → remaining gap = 240 miles
- Combined speed = 60 + 80 = 140 mph
- Time to close 240 miles = 240/140 ≈ 1.71 hours ≈ 1h 43m
- They meet at approximately 10:43am ✓
Zero-shot CoT
You don’t always need examples. Just append "Let's think step by step." to any reasoning task.
def add_cot(prompt: str) -> str:
    return prompt + "\n\nLet's think step by step."
Benchmark improvement on GSM8K: ~40% → ~70% accuracy with zero-shot CoT on GPT-3.5 class models.
Technique 2: Self-Consistency — Majority Vote Over Reasoning Paths
Self-consistency samples multiple reasoning paths and takes the majority answer. It’s like running CoT multiple times and voting.
import asyncio
from collections import Counter
async def self_consistent_answer(
    question: str, 
    n_samples: int = 5,
    temperature: float = 0.7
) -> str:
    
    cot_prompt = f"{question}\n\nLet's think step by step."
    
    # Sample n independent reasoning paths
    tasks = [
        llm.invoke(cot_prompt, temperature=temperature) 
        for _ in range(n_samples)
    ]
    responses = await asyncio.gather(*tasks)
    
    # Extract final answers
    answers = [extract_final_answer(r) for r in responses]
    
    # Majority vote
    most_common = Counter(answers).most_common(1)[0][0]
    return most_common
When to use it: Complex math, multi-step logical reasoning, anything where the model is uncertain. Not useful for factual lookups or creative tasks.
Cost tradeoff: 5x API calls for ~10-15% accuracy improvement. Worth it when accuracy is critical.
Technique 3: Tree of Thought (ToT) — Deliberate Exploration
Tree of Thought extends CoT by explicitly exploring multiple reasoning branches and evaluating them:
Problem
  ├── Approach A
  │     ├── Step A1 → evaluate: promising ✓
  │     └── Step A2 → evaluate: dead end ✗
  ├── Approach B
  │     ├── Step B1 → evaluate: promising ✓
  │     │     └── Step B1.1 → SOLUTION FOUND
  └── Approach C
        └── evaluate: not viable ✗
Simplified ToT Implementation
async def tree_of_thought(problem: str, breadth: int = 3, depth: int = 3):
    
    # Generate initial approaches
    approaches_prompt = f"""
Problem: {problem}
Generate {breadth} different high-level approaches to solve this.
Format: numbered list, one sentence each.
"""
    approaches_text = await llm.invoke(approaches_prompt)
    approaches = parse_numbered_list(approaches_text)
    
    best_path = None
    best_score = 0
    
    for approach in approaches:
        # Evaluate each approach
        eval_prompt = f"""
Problem: {problem}
Approach: {approach}
Rate this approach's likelihood of success (1-10) and explain why.
Format: SCORE: X\nREASON: ...
"""
        evaluation = await llm.invoke(eval_prompt)
        score = extract_score(evaluation)
        
        if score > best_score:
            best_score = score
            best_path = approach
    
    # Execute best path with CoT
    return await chain_of_thought_solve(problem, approach=best_path)
Best for: Creative problem-solving, multi-step planning, tasks with multiple valid strategies (not single-answer math problems where self-consistency is better).
Technique 4: Retrieval-Augmented Generation (RAG) Prompt Design
RAG is table stakes in 2026, but most teams use it naively. The prompt structure matters enormously.
Naive RAG (Common Mistake)
❌ Context:
[paste 10 retrieved chunks]
Question: What is the refund policy?
Answer:
Structured RAG with Source Attribution
✅ You are a helpful customer support assistant.
RETRIEVED CONTEXT:
---
[Source 1 - FAQ, relevance: 0.94]
Refunds are processed within 5-7 business days...
[Source 2 - Policy Doc, relevance: 0.87]  
For purchases over $500, a manager approval is required...
---
INSTRUCTIONS:
- Answer using ONLY the provided context
- If the context doesn't contain the answer, say "I don't have that information"
- Cite which source supports your answer
- Be concise
QUESTION: What is the refund policy for a $600 purchase?
Relevance Filtering Before Prompting
Don’t stuff all retrieved chunks into the prompt. Filter first:
def build_rag_prompt(query: str, retrieved_chunks: list, 
                     min_score: float = 0.75) -> str:
    
    relevant = [c for c in retrieved_chunks if c.score >= min_score]
    
    if not relevant:
        return f"No relevant context found.\n\nQuestion: {query}"
    
    context_block = "\n\n".join([
        f"[Source {i+1} - score: {c.score:.2f}]\n{c.text}"
        for i, c in enumerate(relevant[:5])  # max 5 chunks
    ])
    
    return f"""CONTEXT:
{context_block}
Using only the above context, answer:
{query}
If the context doesn't contain the answer, say so explicitly."""
Technique 5: Constitutional Prompting
Constitutional prompting embeds behavioral constraints directly in the system prompt. Instead of filtering outputs post-hoc, you guide the model’s generation:
SYSTEM_PROMPT = """You are a financial analysis assistant.
CONSTITUTION:
1. Never make specific investment recommendations ("buy X" or "sell Y")
2. Always distinguish between historical data and forward projections
3. When citing statistics, mention the source and date if known
4. If asked about illegal activities, decline and explain why
5. Acknowledge uncertainty — avoid false confidence
STYLE:
- Be precise and data-driven
- Prefer tables and bullet points for comparative data
- Keep responses under 500 words unless detail is explicitly requested
"""
The “constitution” pattern makes behavior auditable. You can diff system prompts between versions and understand what changed.
Technique 6: Persona + Context Injection
Giving the model a specific role with relevant context consistently improves output quality:
❌ Generic:
Summarize this code review.
✅ Persona-injected:
You are a senior software engineer with 10 years of experience in 
distributed systems. You are reviewing code for a team of mid-level 
engineers. Your feedback should be:
- Direct but constructive
- Focused on correctness first, style second
- Including specific line references when possible
- Prioritized (P1/P2/P3)
Review the following code:
[code]
Technique 7: Structured Output Forcing
In 2026, most major models support JSON mode natively, but prompt design still matters for complex schemas:
STRUCTURED_PROMPT = """Analyze the following customer feedback and extract:
REQUIRED OUTPUT FORMAT (strict JSON):
{
  "sentiment": "positive" | "negative" | "neutral",
  "topics": ["topic1", "topic2"],  // max 5
  "urgency": 1-5,  // 5 = immediate action needed
  "action_required": boolean,
  "suggested_action": "string or null if no action"
}
Rules:
- Return ONLY valid JSON, no prose
- urgency=5 only if customer threatens churn or legal action
- topics must be from: [billing, product, support, shipping, other]
FEEDBACK: {feedback_text}
"""
For complex outputs, show an example:
EXAMPLE = """
Input: "I've been waiting 3 weeks for my order and nobody responds to emails"
Output: {
  "sentiment": "negative",
  "topics": ["shipping", "support"],
  "urgency": 4,
  "action_required": true,
  "suggested_action": "Escalate to fulfillment team, send apology email with tracking"
}
"""
Prompt Evaluation: Measuring What Works
Don’t iterate on vibes. Build an evaluation harness:
class PromptEvaluator:
    def __init__(self, test_cases: list[dict]):
        self.test_cases = test_cases  # [{input, expected_output}]
    
    async def evaluate(self, prompt_template: str) -> dict:
        results = []
        for case in self.test_cases:
            prompt = prompt_template.format(**case["input"])
            response = await llm.invoke(prompt)
            score = self.score_response(response, case["expected_output"])
            results.append(score)
        
        return {
            "mean_score": sum(results) / len(results),
            "pass_rate": sum(1 for r in results if r >= 0.8) / len(results),
            "samples": len(results)
        }
    
    def score_response(self, response: str, expected: str) -> float:
        # Use LLM-as-judge or exact match depending on task type
        return llm_judge_score(response, expected)
Run this before and after every prompt change. A/B test prompts like you A/B test features.
Choosing the Right Technique
Task Type
      Best Technique
    
Math / logic reasoning
      Self-Consistency > CoT
    
Multi-step planning
      Tree of Thought
    
Knowledge Q&A
      RAG + Structured Prompt
    
Code generation
      CoT + Structured Output
    
Content moderation
      Constitutional Prompting
    
Data extraction
      Structured Output + Examples
    
Creative tasks
      Persona + Context Injection
    
Conclusion
The field has moved past “magic words.” In 2026, good prompt engineering means:
Measuring outcomes with evaluation harnesses
Matching technique to task type — no one-size-fits-all
Treating prompts as code — version control, test coverage, changelogs
Layering techniques — CoT + structured output + persona often beats any single method
The engineers who understand why techniques work will continue to outperform those cargo-culting patterns from blog posts. Start with measurement; let the numbers guide your iterations.
Tags: AI, LLM, Prompt Engineering, Claude, GPT, Chain-of-Thought, RAG

Prompt Engineering in 2026: Beyond Few-Shot — Advanced Techniques That Actually Work

댓글