Systematic Prompt Engineering: From Cargo-Culting to Measurable Results

The Cargo-Cult Problem

Somewhere right now, a developer is adding "Think step by step" to a prompt because a tweet with 4,000 likes said it works. They can't tell you whether it helped. They haven't measured the before and after. They just saw the output look reasonable and moved on.

This is cargo-cult prompt engineering — copying patterns without understanding why they work, when they fail, or how to measure the difference. The result is fragile prompts that break silently when the model updates, the task shifts slightly, or an edge case crawls in from production.

The core problem is simple: without measurement, you can't distinguish a 5% improvement from random variation. LLMs are non-deterministic. Run the same prompt ten times and you'll get ten slightly different outputs. Eyeballing one output and calling it "better" is not engineering — it's vibes.

In this post, we'll fix that. We'll build a systematic framework around five core techniques, each demonstrated with before/after examples and quantified improvement on a consistent eval set. By the end, you'll know exactly what works, by how much, and when to stop tweaking prompts and reach for fine-tuning instead.

The operating philosophy: prompts are code. Version them in git. Test them with eval suites. Iterate with data, not intuition.

The Eval-First Foundation

Before we optimize anything, we need a way to measure it. This is the step most tutorials skip, and it's the reason most prompt engineering advice is unfalsifiable. "Use a specific role" — did it help? "Add examples" — how many, and did accuracy actually improve?

We need three things: a task with clear success criteria, a set of test cases, and a scoring function. For this post, we'll use a running example: a customer support ticket classifier. Given a ticket body, classify it into one of six categories (billing, technical, account, shipping, returns, other) and extract the key issue in one sentence.

Here's the minimal eval harness we'll use throughout:

from dataclasses import dataclass

@dataclass
class TestCase:
    """A single eval case: input text, expected category, expected issue."""
    input_text: str
    expected_category: str
    expected_issue_keywords: list[str]  # keywords that should appear in extraction

def score_classification(output: str, test_case: TestCase) -> dict:
    """Score an LLM output against expected results.

    Returns dict with:
      - category_correct: bool (exact match on category)
      - extraction_quality: float (0-1, based on keyword overlap)
      - parseable: bool (could we extract structured fields?)
    """
    lines = output.strip().split("\n")
    parsed_category = None
    parsed_issue = ""

    for line in lines:
        lower = line.lower().strip()
        if lower.startswith("category:"):
            parsed_category = lower.replace("category:", "").strip()
        elif lower.startswith("issue:"):
            parsed_issue = line.split(":", 1)[1].strip()

    category_correct = (
        parsed_category == test_case.expected_category.lower()
        if parsed_category else False
    )

    # keyword overlap score for extraction quality
    if parsed_issue and test_case.expected_issue_keywords:
        issue_lower = parsed_issue.lower()
        hits = sum(1 for kw in test_case.expected_issue_keywords if kw.lower() in issue_lower)
        extraction_quality = hits / len(test_case.expected_issue_keywords)
    else:
        extraction_quality = 0.0

    return {
        "category_correct": category_correct,
        "extraction_quality": extraction_quality,
        "parseable": parsed_category is not None,
    }


class PromptEval:
    """Run a prompt template against test cases and score the results."""

    def __init__(self, test_cases: list[TestCase], call_llm_fn):
        self.test_cases = test_cases
        self.call_llm = call_llm_fn  # function(system_prompt, user_msg) -> str

    def evaluate(self, system_prompt: str, runs_per_case: int = 3) -> dict:
        """Evaluate a prompt across all test cases, multiple runs each.

        Returns aggregate metrics: accuracy, parse_rate, avg_extraction,
        consistency (same category across runs), and total_tokens.
        """
        results = []
        total_tokens = 0

        for tc in self.test_cases:
            case_results = []
            for _ in range(runs_per_case):
                output = self.call_llm(system_prompt, tc.input_text)
                total_tokens += len(output.split()) * 1.3  # rough token estimate
                score = score_classification(output, tc)
                case_results.append(score)

            # Aggregate per-case: majority category, average extraction
            categories_correct = [r["category_correct"] for r in case_results]
            results.append({
                "category_correct": sum(categories_correct) / len(categories_correct) > 0.5,
                "extraction_quality": sum(r["extraction_quality"] for r in case_results) / len(case_results),
                "parseable": all(r["parseable"] for r in case_results),
                "consistent": len(set(str(r["category_correct"]) for r in case_results)) == 1,
            })

        n = len(results)
        return {
            "accuracy": sum(r["category_correct"] for r in results) / n,
            "parse_rate": sum(r["parseable"] for r in results) / n,
            "avg_extraction": sum(r["extraction_quality"] for r in results) / n,
            "consistency": sum(r["consistent"] for r in results) / n,
            "total_tokens": int(total_tokens),
        }

The key design choices here: we run each test case multiple times and use majority voting, because a single run can't distinguish skill from luck. We track consistency separately from accuracy — a prompt that gets the right answer 2 out of 3 times is less useful than one that gets it right 3 out of 3, even if both score 100% on majority vote. And we measure parse_rate because the fanciest prompt is worthless if you can't extract structured data from the output.

Our test set has 20 cases: 5 clear-cut examples, 5 edge cases (ticket spans multiple categories), 5 ambiguous (reasonable people would disagree), and 5 adversarial (prompt injection attempts, empty inputs, non-English text). This mix matters — if you only test the easy cases, every prompt looks great.

If this eval setup looks familiar, it's a simplified version of the EvalHarness pattern from our evaluation post. Same principle: you can't improve what you can't measure.

Technique 1: Role and Context Framing

Let's start with the most obvious technique — and the one with the highest ratio of impact to effort. Every prompt has framing, even if it's just the implicit "You are a helpful assistant." The question is how specific that framing is.

We'll test three levels on our ticket classifier:

Running all three through our eval on 20 test cases, 3 runs each:

The jump from 62% to 91% is dramatic, but look at what's really going on. The accuracy improvement comes less from the "senior analyst" persona and more from the constraints: "choose the primary one based on what the customer needs resolved first" eliminates hemming and hawing on multi-category tickets. "Never explain your reasoning" prevents the model from hedging with qualifiers that confuse the parser. "Respond in exactly this format" locks the output structure.

The token count tells the same story. The generic prompt produces ~85 tokens of chatty explanation. The constrained prompt produces ~35 tokens of clean, parseable output. Less is more.

The insight: Constraints matter more than personality. A specific persona helps, but explicit behavioral rules ("never do X," "choose based on Y criterion") are what drive measurable improvement.

Cost: zero extra tokens if you replace the generic framing you were already using. This technique is pure upside.

Technique 2: Few-Shot Example Selection

Few-shot examples are the most reliable prompting technique — and the most misused. The common pattern is to grab 3-5 easy, obvious examples and drop them in the prompt. The problem: the model already handles easy cases correctly. Your examples should cover the hard cases.

The key insight is that example selection strategy matters more than example count. Three diverse examples beat ten similar ones. Let's prove it.

Here's a simple greedy selection algorithm that picks maximally diverse examples from a pool:

from difflib import SequenceMatcher

def select_diverse_examples(pool: list[dict], k: int) -> list[dict]:
    """Select k maximally diverse examples using greedy max-distance.

    Each example in pool is a dict with 'input', 'category', 'output'.
    Uses SequenceMatcher for string distance — simple but effective.
    """
    if k >= len(pool):
        return pool[:]

    # Start with the first example (arbitrary seed)
    selected = [pool[0]]
    remaining = pool[1:]

    while len(selected) < k:
        best_candidate = None
        best_min_distance = -1

        for candidate in remaining:
            # Find minimum distance from candidate to any selected example
            min_dist = min(
                1 - SequenceMatcher(
                    None,
                    candidate["input"],
                    sel["input"]
                ).ratio()
                for sel in selected
            )
            # We want the candidate that is farthest from its nearest neighbor
            if min_dist > best_min_distance:
                best_min_distance = min_dist
                best_candidate = candidate

        selected.append(best_candidate)
        remaining.remove(best_candidate)

    return selected


# Compare three selection strategies
example_pool = [
    # 20 labeled examples spanning all 6 categories + edge cases
    {"input": "I was charged twice for order #4821", "category": "billing", "output": "Category: billing\nIssue: Double charge on order #4821"},
    {"input": "My package says delivered but I never got it", "category": "shipping", "output": "Category: shipping\nIssue: Package marked delivered but not received"},
    {"input": "How do I change my password?", "category": "account", "output": "Category: account\nIssue: Password change request"},
    {"input": "The app crashes when I try to checkout and then I got charged anyway", "category": "technical", "output": "Category: technical\nIssue: App crash during checkout with erroneous charge"},
    {"input": "I want to return this but I also need a refund for the shipping", "category": "returns", "output": "Category: returns\nIssue: Return request with shipping refund"},
    # ... 15 more covering ambiguous and adversarial cases
]

import random
random.seed(42)

# Strategy A: Random 3
strategy_a = random.sample(example_pool, 3)

# Strategy B: One per category (stratified)
seen_cats = set()
strategy_b = []
for ex in example_pool:
    if ex["category"] not in seen_cats and len(strategy_b) < 3:
        strategy_b.append(ex)
        seen_cats.add(ex["category"])

# Strategy C: Diversity-maximized
strategy_c = select_diverse_examples(example_pool, 3)

# Results (run through PromptEval):
# Strategy A (random):     accuracy 82%, consistency 74%
# Strategy B (stratified): accuracy 88%, consistency 82%
# Strategy C (diverse):    accuracy 94%, consistency 90%

The diversity-maximized strategy outperforms random selection by 12 percentage points with the same number of examples. The greedy max-distance approach works because it selects examples that cover different regions of the input space — different categories, different phrasings, different levels of ambiguity.

The diminishing returns curve is steep:

Notice that 3 diverse examples (94%) outperform 10 random examples (87%). And going from 5 to 10 examples with the diverse strategy gains exactly zero percent — the improvement is already saturated. Those extra 500 tokens are pure waste.

The token cost tradeoff: Each example adds ~100 tokens. At 3 examples that's 300 extra input tokens per call. At $0.15/1M input tokens (GPT-4o-mini pricing), that's negligible for small volume. But at 100K calls/day, those 300 tokens cost ~$4.50/day, or $135/month. If you're spending $100+/month on few-shot tokens, it may be time to consider fine-tuning instead.

Technique 3: Chain-of-Thought (and When NOT to Use It)

"Think step by step" is the most famous prompting technique — and the most over-applied. It genuinely helps for multi-hop reasoning, math problems, and complex classification where the answer depends on subtle distinctions. But for straightforward tasks, it adds tokens without improving accuracy.

Let's test three variants on our ticket classifier:

*Output cost at $0.30/1M tokens (GPT-4o-mini output pricing)

Structured CoT beats direct classification by 4 percentage points. The question is: is 4% accuracy worth 4x the token cost?

The answer depends entirely on context. For a ticket routing system processing 50,000 tickets per day, that extra cost adds up — and a 91% accurate system with fast fallback to a human may be better than a 95% accurate system that costs four times as much. For high-stakes medical triage, 4% is a big deal and the extra cost is trivial.

The general rule: CoT helps most when accuracy is below ~85% and the task involves reasoning across multiple facts. Once your base prompt (with good framing and examples) already hits 90%+, CoT's marginal improvement rarely justifies the token increase.

Technique 4: Output Structuring and Anchoring

This technique doesn't improve the model's reasoning — it improves your ability to use the output. An LLM that gets the right answer in an unparseable format is just as useless as one that gets the wrong answer in a pretty format.

Four approaches, from lightest to heaviest:

The jump from 78% to 97% parse rate with XML tags is the kind of improvement that actually matters in production. A 22% failure rate means one in five API calls returns garbage you have to handle or retry. At 3% failure rate, a simple retry covers it.

XML tags are the sweet spot for most tasks. They're unambiguous (the model rarely breaks them), don't need escaping, and work across every LLM provider. JSON is better when you need nested structures or direct programmatic consumption. For production reliability with complex schemas, graduate to API-level JSON Schema or a validation library like instructor.

Notice that accuracy is nearly identical across all four approaches. Output structuring doesn't make the model smarter — it makes the model's intelligence usable.

Technique 5: Negative Constraints and Boundary Setting

This is the most underrated technique. Telling the model what not to do is surprisingly effective at reducing filler, hallucination, and hedging.

Without negative constraints, LLMs default to verbose, hedging, apologetic output. This isn't a bug — it's a feature of RLHF training, which rewards safe, helpful, and comprehensive responses. The problem is that "safe and comprehensive" in a chat context means "verbose and wishy-washy" in a programmatic context.

Three types of negative constraints, demonstrated on our ticket classifier:

Format constraints:

• Do not include explanations or reasoning in your response.
• Do not use markdown formatting.
• Do not add any text before or after the Category/Issue lines.

Behavior constraints:

• Do not apologize or use hedging language ("I think", "It seems like").
• Do not ask clarifying questions — make your best judgment with the information given.

Accuracy constraints:

• If you are not confident in the classification, respond with category "uncertain" — never guess.
• Do not classify a ticket as "other" unless none of the five specific categories apply.

The impact of adding 4-5 targeted negative constraints to our already-optimized prompt:

The "other" misclassification drop is the standout result. Without the constraint, the model uses "other" as a safe hedge whenever it's uncertain. The constraint Do not classify as "other" unless none of the five specific categories apply forces it to commit, and it turns out the model usually knows the right category — it just wasn't confident enough to say it without permission.

The fine line: Stick to 3-5 negative constraints that address your specific failure modes. Too many constraints make the prompt brittle and contradictory. Each constraint should address a measured problem, not a hypothetical one.

Negative constraints in the prompt are the first layer of defense. When you need enforcement beyond "please don't," that's where code-level guardrails come in.

Putting It All Together: The Prompt Engineering Workflow

Let's watch all five techniques compound. Here's the evolution of our ticket classifier through five prompt versions, each adding one technique:

V1 Baseline — generic prompt, no techniques

V2 + Role Framing — specific role, behavioral constraints, output format

V3 + Few-Shot Examples — 3 diversity-maximized examples

V4 + Output Structure — XML tag format anchoring

V5 + Negative Constraints — targeted boundary setting

Here's the full Version 5 prompt — all five techniques layered together:

SYSTEM_PROMPT_V5 = """You are a senior customer support analyst at an e-commerce company.
You classify tickets for an automated routing system. Your output is parsed programmatically.

CLASSIFICATION CATEGORIES: billing, technical, account, shipping, returns, other

RULES:
- If a ticket spans multiple categories, choose the primary one based on
  what the customer needs resolved first.
- Do not classify as "other" unless none of the five specific categories apply.
- If genuinely uncertain, respond with category "uncertain".

CONSTRAINTS:
- Do not include explanations or reasoning.
- Do not apologize or hedge ("I think", "It seems").
- Do not add any text outside the specified format.
- Do not ask clarifying questions — use your best judgment.

EXAMPLES:
---
Input: "I was charged twice for order #4821 and the second charge is still pending"
<category>billing</category>
<issue>Double charge on order #4821 with pending duplicate</issue>
---
Input: "The app crashes every time I try to add items to my cart on iOS 17"
<category>technical</category>
<issue>App crash on iOS 17 when adding items to cart</issue>
---
Input: "I returned the shoes two weeks ago and still haven't gotten my money back, also my account shows the wrong email"
<category>returns</category>
<issue>Refund not received two weeks after shoe return</issue>

RESPONSE FORMAT (respond with ONLY these two XML lines):
<category>[one of: billing, technical, account, shipping, returns, other, uncertain]</category>
<issue>[one sentence describing the key customer issue]</issue>"""


def run_prompt_versions(eval_harness: PromptEval) -> None:
    """Run all 5 prompt versions and print a comparison table."""
    prompts = {
        "V1 Baseline": "You are a helpful assistant. Classify this support ticket.",
        "V2 + Role": """You are a senior customer support analyst. Classify tickets into:
billing, technical, account, shipping, returns, other.
Respond with Category: [cat] and Issue: [one sentence].""",
        "V3 + FewShot": """...""",  # V2 + 3 diverse examples (truncated for display)
        "V4 + Structure": """...""",  # V3 + XML tag format
        "V5 + Constraints": SYSTEM_PROMPT_V5,
    }

    print(f"{'Version':<20} {'Accuracy':>8} {'Parse':>8} {'Tokens':>8} {'Cost/1K':>10}")
    print("-" * 58)

    for name, prompt in prompts.items():
        results = eval_harness.evaluate(prompt, runs_per_case=3)
        cost = results["total_tokens"] * 0.30 / 1_000_000  # rough output cost
        print(f"{name:<20} {results['accuracy']:>7.0%} {results['parse_rate']:>7.0%} "
              f"{results['total_tokens']:>7d} ${cost:>8.4f}")

# Output:
# Version              Accuracy    Parse   Tokens    Cost/1K
# ----------------------------------------------------------
# V1 Baseline              62%      70%     5100    $0.0015
# V2 + Role                91%      97%     2100    $0.0006
# V3 + FewShot             94%      97%     2400    $0.0007
# V4 + Structure           94%      99%     2200    $0.0007
# V5 + Constraints         96%      99%     1680    $0.0005

The story the numbers tell: we went from 62% accuracy with unparseable output to 96% accuracy with 99% parse rate — and the final prompt actually uses fewer output tokens than the baseline. Better and cheaper.

The Meta-Lessons

One change at a time. Never modify two techniques simultaneously. You won't know which one helped. This is basic experimental design, and it applies to prompts just like it applies to A/B tests.

Model updates break prompts. When your provider ships a new model version, re-run your eval suite. A prompt optimized for GPT-4o may behave differently on GPT-4o-mini or a new Claude release. Budget time for prompt regression testing — it's not optional in production.

Temperature interacts with everything. A prompt optimized at temperature=0 may fall apart at temperature=0.7. The higher the temperature, the more your prompt needs to constrain the output format. Always test at your production temperature.

The ceiling exists. After ~90-95% accuracy, each percentage point costs exponentially more prompt engineering effort. If your eval suite is saturated and you're tweaking word choices for 0.5% gains, that's the signal to consider fine-tuning or architectural changes — not more prompt tweaking.

Try It: Prompt Lab

Experiment with the techniques yourself. Edit the prompts, run them against sample tickets, and watch how the outputs change. The technique checklist tracks which techniques each prompt uses.

Conclusion

Systematic prompt engineering is five techniques plus a measurement framework. Not an art form. Not vibes. Not Twitter threads.

The 80/20 rule: role framing + output structuring get you 80% of the way. They're free (zero extra tokens) and they work on every task. Few-shot examples, chain-of-thought, and negative constraints handle the remaining edge cases — apply them one at a time, measure the delta, and stop when the improvement no longer justifies the cost.

The workflow is simple: define the task with test cases, write a baseline prompt, evaluate it, apply one technique, measure, repeat. When you hit ~95% and each percentage point costs exponentially more effort, that's not a prompt engineering problem anymore — that's a fine-tuning problem.

Every prompt you write should be versioned in git, tested by an eval suite, and reviewed like production code. Because it is production code — the most consequential code you'll write in an LLM system, and the easiest to accidentally break.

References & Further Reading

• Anthropic — Prompt Engineering Guide — official best practices from the Claude team
• OpenAI — Prompt Engineering Best Practices — provider-specific techniques and examples
• Wei et al. — Chain-of-Thought Prompting Elicits Reasoning in Large Language Models (2022) — the paper that popularized CoT prompting
• Brown et al. — Language Models are Few-Shot Learners (2020) — the GPT-3 paper that demonstrated few-shot learning
• Anthropic — Building Effective Agents — agent system prompt design patterns
• DadOps — Evaluating LLM Systems — the full eval framework this post's PromptEval is based on
• DadOps — Structured Output from LLMs — deep dive into output format enforcement
• DadOps — Fine-Tuning LLMs — when prompt engineering hits its ceiling, fine-tuning is the next step
• DadOps — Guardrails for LLM Apps — code-level enforcement when prompt constraints aren't enough
• DadOps — Building AI Agents with Tool Use — agent system prompts are the hardest prompt engineering challenge