Prompt engineering

Definition

Prompt engineering is the practice of designing inputs — the prompts — sent to language models to reliably produce desired outputs. It's the craft that sits between raw model capability and practical application. Every ChatGPT power user, every developer building on the Anthropic or OpenAI APIs, every team deploying LLM-powered products does prompt engineering, whether they call it that or not.

The discipline emerged with GPT-3 in 2020. Users quickly discovered that the same model could produce dramatically different quality outputs depending on how the prompt was structured. Adding a few examples (few-shot prompting) improved results. Asking the model to reason step by step (chain-of-thought) transformed math and logic tasks. Assigning a role, structuring outputs, and providing context all mattered.

By 2026, prompt engineering has matured from clever tricks to systematic engineering. Teams maintain prompt libraries with version control. Frameworks like DSPy treat prompting as programming and optimize prompts automatically. Evaluation platforms (LangSmith, Promptfoo) let you test prompt changes like you'd test code changes. Provider cookbooks from Anthropic, OpenAI, and Google document proven patterns.

The core techniques are surprisingly universal. Zero-shot: describe the task in words. Few-shot: show examples. Chain-of-thought: ask for reasoning. System prompts: set persona and constraints. Structured output: constrain the format. ReAct: interleave reasoning with tools. Combined thoughtfully, these produce reliable behavior even on complex tasks.

Real-world example

The same task, three prompting techniques

Say you want an LLM to classify customer support emails as billing, technical, feature-request, or complaint. A naive prompt might just ask 'What category is this email?' The model may respond inconsistently, hedge with prose, or use categories you didn't define. Better prompts use progressively more structure: (1) a system prompt defining the categories and constraints, (2) few-shot examples showing the desired format, (3) structured output like JSON to force a parseable response. Each layer dramatically improves reliability in production.

# Progressively better prompts for email classification
from anthropic import Anthropic
client = Anthropic()

email = "Hi, I was charged twice for my October subscription..."

# ❌ Naive prompt — inconsistent output format
def classify_v1(email):
    return client.messages.create(
        model="claude-opus-4-8", max_tokens=100,
        messages=[{"role":"user","content":f"What category: {email}"}]
    ).content[0].text

# ✅ Better — system prompt + constraints + one-word output
def classify_v2(email):
    return client.messages.create(
        model="claude-opus-4-8", max_tokens=20,
        system="""You classify customer emails into exactly one of:
billing, technical, feature-request, complaint.
Respond with ONLY the category word — no explanation.""",
        messages=[{"role":"user","content":email}]
    ).content[0].text

# ✅✅ Best — few-shot examples + structured JSON output
def classify_v3(email):
    return client.messages.create(
        model="claude-opus-4-8", max_tokens=200,
        system="""Classify support emails. Return JSON:
{"category": "...", "confidence": 0.0-1.0, "reasoning": "..."}
Categories: billing, technical, feature-request, complaint.""",
        messages=[
            {"role":"user","content":"I can't log in for 3 days now."},
            {"role":"assistant","content":'{"category":"technical","confidence":0.95,"reasoning":"Login issue."}'},
            {"role":"user","content":"Add dark mode please."},
            {"role":"assistant","content":'{"category":"feature-request","confidence":0.98,"reasoning":"Feature ask."}'},
            {"role":"user","content":email},
        ]
    ).content[0].text

When you'll encounter this

• You're building any LLM feature — the prompt is the interface between your product and the model.
• You're debugging model behavior — most 'model bugs' are actually prompt bugs.
• You're optimizing cost — shorter prompts and better structure often reduce token count 30-50%.
• You're improving reliability — structured prompts with examples and constraints cut hallucination and format drift.
• You're evaluating whether to fine-tune — a well-designed prompt is often the correct baseline before spending on fine-tuning.

How it works

Common misconceptions

Related terms

Where you'll see this in practice

Learn more

• Take the Master Prompt Engineering path
• Read: How Chain-of-Thought Actually Works
• Compare Prompt Engineering vs Fine-tuning
• Browse Prompt Engineering category