Prompting techniques that move the needle

Prompt advice is an ocean of folklore. This lesson keeps only the techniques that reliably change results on current Claude models, and — just as useful — names the ones that stopped mattering. The theme throughout: you are not tricking the model, you are specifying the task well enough that the model's capability actually lands on it.

Show, don't describe: few-shot examples

When output shape or judgment is hard to describe, two or three worked examples outperform paragraphs of description. Examples pin down everything at once — format, tone, edge-case handling, level of detail:

Classify each support ticket as BUG, BILLING, or HOWTO. Output only the label.

<examples>
Ticket: "The export button 500s when the report has zero rows" -> BUG
Ticket: "I was charged twice for March" -> BILLING
Ticket: "Can I add a webhook so my CRM updates automatically?" -> HOWTO
</examples>

Ticket: "Invoice PDF renders blank in Safari"

Choose examples that disagree with each other — the boundary cases teach more than the obvious ones. A ticket that mentions a payment but is really a bug report teaches the classifier where the line is; three easy examples teach nothing your instruction didn't already say.

Reasoning is a dial now, not a trick

The era of coaxing reasoning with "think step by step" is over. Current Claude models have adaptive thinking — the model decides when and how deeply to reason before answering, emitting thinking blocks you can optionally surface — and you control depth with the effort parameter rather than with incantations:

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "adaptive"},          # on by default on the newest models
    output_config={"effort": "high"},        # low | medium | high | xhigh | max
    messages=[{"role": "user", "content": "Design a rate limiter for our multi-tenant API..."}],
)

Learn the effort ladder as a tuning instrument, because it is now the primary intelligence–latency–cost control:

• low / medium — routine, latency-sensitive routes; on current models these punch far above their weight, and medium on a new model often matches high on the previous one.
• high — the default, and the sweet spot for most intelligence-sensitive work.
• xhigh — the recommended setting for hard coding and agentic tasks; what Claude Code itself runs at.
• max — correctness-over-cost territory; test it, because past a point more deliberation stops buying accuracy and starts buying overthinking.

The method is the same one you used for model choice: sweep two or three levels over your evaluation set, per route, and keep the cheapest one that holds quality. Two budgeting notes: thinking spends from max_tokens, so deep-reasoning calls need generous caps — and don't ask for step-by-step reasoning in the prompt on top of thinking; you'd pay for deliberation twice.

What no longer works: temperature and other sampling knobs are gone from the newest models — steering happens through prompts. If you relied on temperature for variety (say, design options), ask for variety explicitly: "propose four distinct directions, then wait."

Give the reason, not just the request

Claude performs measurably better when it knows why it is doing something, because intent lets it resolve the hundred small ambiguities every task contains — in your favour instead of at random:

I'm preparing a migration plan for a Postgres 12 -> 16 upgrade on a payments system.
The audience is our SRE team; they need to veto anything that risks writes being lost.
With that in mind: list the breaking changes between 12 and 16 that matter for us.

The frame — payments, SREs, write-loss risk — turns a generic listicle into a targeted answer. This is the cheapest quality upgrade in this entire course: one sentence of context per request.

License uncertainty, or you will get confident nonsense

A model asked a question it cannot answer will still answer, in the shape of an answer. The fix is standing permission to abstain, written into the system prompt: "If you are not confident, say so and state what you would need to check. A wrong answer is worse than no answer." This costs nothing when the model knows, and converts the failure mode from silent fabrication — which you ship — into an explicit gap, which you fix. Pair it with grounding ("answer only from the provided context") and you have the two-line core of every trustworthy Q&A system.

Constrain scope explicitly

Capable models err toward doing more than asked — refactoring around the bug they were asked to fix, adding the error handling nobody requested. If you want minimal, targeted output, say so: "Deliver what was asked at the scope intended. Make routine judgment calls yourself; if you think the ask itself is wrong, say so in one sentence and continue with the task as given." And the mirror habit for you: put the complete task specification up front in one turn rather than dribbling requirements across five — well-specified single turns get better results at lower cost than iterative clarification.

What to take into the next lesson

Examples over adjectives, effort over incantations, reasons over bare requests, licensed uncertainty over confident guessing, explicit scope over hoped-for restraint. Every one of these is a specification improvement, not a trick — which is why they survive model upgrades. Next we make output machine-consumable: schemas the API actually guarantees.