Prompt Engineering for Developers
A vague prompt produces vague code; a structured prompt with role, constraints, examples, and a fixed output shape produces something you can test. Prompt engineering is how developers turn chat into a repeatable interface — in the IDE, in CI review bots, and in app-facing LLM calls. Prompt vs Context vs Harness Engineering helps confirm that the message is the layer you need to change.
This article covers zero-shot, few-shot, and chain-of-thought, then production patterns: system vs user messages, structured outputs, and the failure modes (injection, format drift, silent model upgrades) that break naive pipelines. For the controls around prompts in production, continue with 9 AI Concepts for Production Systems.
Zero-Shot Prompting
Zero-shot gives a task with no examples. Modern models often infer format from a clear instruction: summarize in three bullets, convert JSON to TypeScript interfaces, classify a label set you name. It fails when the task is ambiguous, domain-specific, or needs a non-standard shape — then escalate to few-shot or chain-of-thought.
Request trace: Client → your API builds system + user messages → model API → parse JSON → validate schema → return to client (or 422 on bad shape). Start zero-shot; escalate only when quality drops on a fixed eval set.
Quick reference
- Best for: summarization, translation, simple codegen, clear-label classification.
- State task, format, and constraints in one place.
- Assign a role when domain judgment matters.
- Escalate when the model misformats or misses edge cases.
- Quality still depends on model capability — verify on your eval set, not vendor demos.
Remember this
Start zero-shot with an explicit output contract; escalate when a fixed eval set fails.
Few-Shot Prompting
Few-shot adds 2–5 input/output examples before the real task. The model copies the pattern — powerful for classification, extraction, and format conversion. Quality tracks example quality, not count: three diverse examples beat ten mediocre ones. Include an empty or ambiguous case if production will see one.
When not to use: the examples themselves leak PII, or you need general reasoning more than format mimicry (prefer CoT). Put durable examples in the system message so they survive multi-turn chats.
Quick reference
- Best for: classification, extraction, format conversion, domain terms.
- Use 2–5 examples; more mostly burns tokens.
- Include edge cases: empty, ambiguous, error.
- Dynamic few-shot: retrieve similar solved examples per query.
- Never paste secrets into examples that land in logs or vendor training opt-in paths.
Remember this
Few-shot teaches output patterns better than instructions alone — invest in diverse, safe examples.
Chain-of-Thought (CoT)
Chain-of-thought asks the model to reason in steps before the final answer. It helps on multi-step debugging, architecture trade-offs, and logic-heavy analysis. Structured steps ("1 identify bug, 2 propose fix, 3 list edge cases") beat free-form essays for reliability.
When not to use: simple lookups, latency-sensitive UI paths, or when you cannot afford the extra tokens. Run CoT internally; show users only the final answer unless the product is explicitly an explanation tool.
Quick reference
- Best for: debugging, multi-step analysis, architecture decisions.
- Trigger: "Show reasoning, then the final answer as JSON."
- Combine with few-shot: one worked example with steps.
- Hide internal reasoning from end users when it adds noise or leaks internals.
- Measure accuracy vs cost on your eval set before enabling CoT everywhere.
Remember this
Use CoT when wrong answers are costly — not for trivial format tasks.
Production Prompt Patterns
Production prompts separate system (role, constraints, format, safety) from user (the task). Version prompts in code, pin temperature for deterministic work, and evaluate against a small golden set before model upgrades. Prefer structured outputs / tool calling so parsers do not invent recovery logic.
Failure path — prompt injection: treat user text as data, never as instructions that rewrite the system role. If the model returns invalid JSON or a policy violation, fail closed (422/500 with a safe message) — do not retry blindly into an infinite loop.
Quick reference
- System = role + constraints + format; user = task payload.
- Structured outputs / function calling reduce parse failures.
- Temperature 0 for extraction and codegen; higher only when creativity is the product.
- Keep a 20–50 case eval set; run it on every model or prompt change.
- Monitor production format-error rate — silent model updates can break prompts.
Remember this
Treat prompts as versioned code with schemas, evals, and fail-closed parsing.
Key takeaway
Escalate deliberately: zero-shot with a contract, few-shot for format, CoT for hard reasoning, and production wrappers for versioning and safety. The durable skill is a testable prompt pipeline — not a clever one-off chat.
Practice (20 min): Take one real task (PR review or field extraction). Write a system prompt with JSON schema, add two few-shot edge cases, and a parser that returns 502 on bad shape. Run three inputs: happy path, empty input, and an injection attempt (Ignore previous instructions…) — record whether the system role held.
Related Articles
Explore this topic