Developer/AI/PromptEngineering/Fundamentals/prompt-engineering-core-techniques

Prompt Engineering: Core Techniques and Production Discipline

Concept

Prompt engineering is the practice of shaping the text sent to an LLM so its output is reliable and production-quality, rather than merely plausible. It matters because it's the cheapest lever available for output quality — cheaper than fine-tuning a model, and cheaper than switching to a more capable (and more expensive) one — but "cheap" only holds if prompts are treated with the same rigor as code, not tuned by trial and error until an example output looks right.

Three techniques cover most of the ground. Zero-shot is a plain instruction with no examples — the baseline, and often sufficient for simple, well-specified tasks. Few-shot adds a handful of example input/output pairs before the actual request, which anchors the model's output format and style far more reliably than a written instruction alone; critically, real production inputs make better few-shot examples than synthetic ones written to look tidy, because two real examples surface edge cases and formatting quirks that ten hand-crafted ones won't. Chain-of-thought asks the model to reason step by step before producing a final answer — even the minimal instruction "let's think step by step" measurably improves accuracy on tasks that require multi-step reasoning, arithmetic, or logic, at the cost of a longer, slower response. These compose: a prompt can use few-shot examples that themselves demonstrate chain-of-thought reasoning.

A fourth concern, orthogonal to reasoning technique, is output structure: constraining the response to a specific format (JSON matching a schema, a fixed Markdown structure) rather than free text, so the caller can parse it deterministically instead of regex-scraping a paragraph. This is usually enforced via a provider's structured-output/JSON mode or function-calling interface rather than by instruction alone, since instruction-only formatting requests degrade under adversarial or unusual input in a way schema-enforced output doesn't.

Tradeoffs

Technique	Benefit	Cost
Zero-shot	Shortest prompt, lowest token cost and latency	Least reliable on tasks with an implicit format or reasoning requirement the model has to guess at
Few-shot	Strong accuracy/format gains from a handful of real examples; often the single highest-leverage change to a struggling prompt	Longer prompt (more input tokens, more cost); examples need real production inputs to be worth including, which takes work to collect
Chain-of-thought	Measurably better accuracy on multi-step reasoning, arithmetic, and logic tasks	Longer, slower responses; not worth the added latency on tasks that don't actually require multi-step reasoning
Structured output (schema/JSON mode)	Deterministic, parseable responses; removes an entire class of "the model almost formatted it right" bugs	Only as good as the schema itself — a schema that's too loose still leaves ambiguity, and provider support for strict schema enforcement varies

None of these are mutually exclusive — a production prompt commonly combines few-shot examples, an instruction to reason step by step, and a schema-constrained final output in the same request.

When to use / when not to

Start with zero-shot for simple, well-specified tasks (classification into a small fixed set of labels, straightforward extraction) — added technique is cost paid for a reliability problem that may not exist yet.
Reach for few-shot the moment zero-shot output is inconsistent in format or tone — pull the examples from real logged inputs, not ones written to look clean, since the model needs to see the actual messiness it will face in production.
Add chain-of-thought specifically for tasks that require genuine multi-step reasoning (math, multi-hop logic, planning) — it adds latency for no benefit on tasks that are really single-step classification or extraction wearing a reasoning-shaped prompt.
Always constrain to structured output when the response feeds directly into code — free-text parsing of an LLM response is a recurring, avoidable source of production bugs once schema-enforced modes are available from the provider.
Don't add multiple techniques speculatively "to be safe" — each one has a real cost (tokens, latency, prompt complexity), and a prompt with unnecessary chain-of-thought or unnecessary few-shot examples is harder to iterate on later, not more robust.

Common pitfall

Treating prompt changes as trial-and-error tinkering instead of versioned, tested code. A prompt that gets adjusted informally — "that felt better" — with no fixed evaluation set to check it against is running experiments in production, not running a tested system: a change that fixes one bad output can just as easily silently break three others outside whatever the developer happened to glance at. The fix is the same discipline applied to any other code change: keep a small fixed set of real inputs with expected outputs (ten to twenty is enough to start), run every prompt revision against that set before shipping it, and version the prompt itself so "what changed between v1 and v2, and why" has an actual answer.

Engineering Lens

Prompt engineering earns its "engineering" label only when it's held to the same standards as the rest of the codebase: versioned, tested against a fixed eval set, and reviewed like any other change that affects production behavior — not tuned informally against whatever example happened to be on screen. The discipline gap shows up exactly where it always does with under-tested code: not on the happy path anyone actually checked, but on the edge case nobody thought to add to the eval set until it broke in front of a real user. A team that can point to its prompt's eval set and version history is doing prompt engineering; a team iterating on vibes in a chat playground is doing prompt guessing.