Prompt Engineering 101: Zero-Shot, Few-Shot, and Chain-of-Thought

Prompt Engineering 101: Zero-Shot, Few-Shot, and Chain-of-Thought

Forget the lore about magic phrases and secret incantations. A prompt is a program written in English and executed by a stochastic machine, which means the craft is specification writing: say precisely what you want, in what format, with what constraints. Three primitives cover nearly all of it. Everything else is garnish.

The three techniques form a natural escalation. You always start at the bottom rung, and you only climb when a specific, observed failure forces you to.

Zero-Shot: The Baseline You Never Skip#

Zero-shot means asking for what you want with clear instructions and no examples. It deserves first place because modern models are startlingly good at following well-written specs, and most people's "prompting problems" dissolve under two fixes: explicit output contracts and delimiters around untrusted input.

A production-grade zero-shot prompt has five parts, and each one exists to remove a category of surprise:

In code, with the Anthropic SDK:

import anthropic

client = anthropic.Anthropic()

SYSTEM = """You triage support tickets.
Return only JSON: {"category": "billing" | "bug" | "how_to", "urgency": 1-5}"""

msg = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=200,
    system=SYSTEM,
    messages=[{"role": "user", "content": f"<ticket>\n{ticket_text}\n</ticket>"}],
)
print(msg.content[0].text)

Two details carry most of the weight. The output contract names exact categories instead of hoping the model guesses your taxonomy. The <ticket> tags fence off user text so a customer pasting "ignore previous instructions" stays data rather than becoming instructions. OpenAI offers the same discipline through response_format JSON modes; the principle is identical across providers.

Few-Shot: Show the Format You Want#

Instructions describe behavior; examples demonstrate it. When models wobble on tone mimicry, ambiguous category boundaries, or quirky formats, showing three to five worked examples usually beats another paragraph of prose. That is few-shot prompting: solved cases embedded in the prompt itself.

The message array alternates demonstration turns with your real input:

messages = [
    {"role": "user", "content": "<ticket>Refund charged twice</ticket>"},
    {"role": "assistant", "content": '{"category": "billing", "urgency": 4}'},
    {"role": "user", "content": "<ticket>How do I export my data?</ticket>"},
    {"role": "assistant", "content": '{"category": "how_to", "urgency": 2}'},
    {"role": "user", "content": f"<ticket>\n{new_ticket}\n</ticket>"},
]

Example selection matters more than example count. Cover genuinely different cases, include at least one borderline or negative case (a bug that looks like a billing complaint), and keep every example consistent with your stated rules. When instructions and examples conflict, models tend to follow the examples, so contradictions quietly rewrite your spec.

Budget note: every example bills on every call. Keep them short, and if your prompt prefix is stable across requests, provider prompt caching will blunt most of that cost.

The best examples come from production, not imagination. Log misclassified inputs, promote the interesting ones into demonstrations, retest, freeze:

Chain-of-Thought: Making the Steps Visible#

Some tasks fail not from unclear formatting but from being answered in one hop: multi-step arithmetic, applying a policy with exceptions, comparing several documents. Chain-of-thought prompting asks the model to produce intermediate reasoning before its final answer, which measurably improves accuracy on such tasks and gives you an audit trail for free.

The classic trigger was appending something like "think step by step." Modern practice is more deliberate: request numbered steps, then a clearly delimited final answer containing only the machine-readable payload.

PROMPT = """Refund policy:
- Full refund within 30 days of purchase.
- No refund after 30 days unless the item is defective.

Think step by step through the rules that apply, then write:
###FINAL
{{"eligible": true/false, "reason": "..."}}
###END

Purchase date: {purchase_date}
Today: {today}
Item defective: {defective}"""

Parse everything between the markers and discard the rest. Two tradeoffs to respect. Reasoning costs extra output tokens and latency, so reserve it for tasks where the reasoning actually helps rather than reflexively adding it everywhere. And reasoning-model families handle internal deliberation themselves; forcing a verbose scratchpad onto them mostly wastes tokens. Explicit chain-of-thought remains most valuable when you want visible steps for debugging or compliance, or when a standard model needs structure to lean on.

Choosing between the three techniques is a decision tree, not a debate:

Failure Modes Worth Knowing#

Five patterns account for most wasted prompting effort. Vague verbs like "analyze this" without saying what analysis should produce. Contradictory constraints, the classic being concise-but-exhaustive; pick a lane and quantify it. Instruction-example drift, where your carefully written rules get undermined by an off-spec example. Example overload, where fifteen demonstrations dilute attention and later examples crowd out the instructions entirely; three to five strong ones win. And no output contract, which turns every downstream parser into a prayer.

Treat Prompts as Source Code#

Prompts determine behavior, so they deserve source-code treatment: live in version control, not buried as string literals scattered through business logic. Give variants names. Before deploying any change, run it against a golden set of inputs with expected outputs, because prompt edits regress in ways eyeballing never catches. Tools built for this exist, from OpenAI's open-source Evals framework to promptfoo, but even a pytest file with twenty assertions beats nothing. Log which prompt version produced each response so you can diff outcomes against changes.

That mindset shift, from incantations to specifications under test, is the whole discipline. Write prompts like an engineer who has been burned by untested code, because probabilistic software burns faster than most.