Prompt Engineering Patterns Every Engineer Should Know

Prompt engineering earned a reputation as either folk wisdom or a temporary hack until “real” fine-tuning arrives. In production systems, neither story is right. The prompt is the interface contract between your application state and a stochastic model. Engineers who treat it like a string template eventually discover the same failures: brittle outputs, silent instruction conflicts, and context windows packed with noise. The patterns below are the ones that keep showing up when teams move from notebooks to services.

This is context engineering in practice. You are not hunting for magic words. You are deciding what enters the window, in what order, under what budget, and with what obligations on the model’s response.

Pattern 1: Separate policy from task#

Dumping system rules, user intent, retrieved docs, and output format into one blob creates collisions. The model reconciles them unpredictably. Split the window into labeled regions and keep each region’s job narrow:

• Policy — safety, tool allowlists, refusal rules (stable across requests)
• Task — what this call must accomplish
• Evidence — retrieved or tool-derived state for this turn
• Output contract — schema, citations, length limits

When something breaks, you can tell whether the failure was policy, evidence, or format — instead of rewriting the whole prompt and hoping.

Pattern 2: Make the output contract machine-checkable#

“Respond as JSON” is not a contract. A contract names required fields, types, and what to do when information is missing. Prefer schemas you validate in code. If validation fails, retry with the validator error appended — once or twice, not forever.

const contract = `{
  "status": "ok" | "need_clarification" | "cannot_answer",
  "answer": string | null,
  "citations": string[],
  "confidence": "low" | "medium" | "high"
}`;

function buildPrompt(task: string, evidence: string) {
  return [
    "You are a backend component, not a chat partner.",
    "Follow the output schema exactly. No markdown fences.",
    `Schema: ${contract}`,
    "If evidence is insufficient, status=cannot_answer and answer=null.",
    `Evidence:\n${evidence}`,
    `Task:\n${task}`,
  ].join("\n\n");
}

The important line is the insufficient-evidence rule. Without it, models invent fields to satisfy the schema.

Pattern 3: Few-shots are data, not decoration#

Random examples improve demos and hurt production. Select few-shots for coverage of decision boundaries: edge cases, refusals, ambiguous inputs, and the exact format you need. Three sharp examples beat twelve similar ones. Refresh them when eval failures cluster around a missed case — treat the shot set like a miniature training set under version control.

Pattern 4: Budget the window on purpose#

Everything you paste costs attention. Rank candidates (messages, chunks, tool traces), allocate tokens by priority, and drop the rest. Recency is not always priority; a policy clause from the system prompt often outranks an older chat turn.

These percentages are starting points, not laws. Measure with your eval set.

Pattern 5: Tool-aware prompts state capabilities and limits#

If the model can call tools, say which tools exist, what arguments they take, and — just as important — what it must not invent. “Never fabricate tool results” belongs next to the tool list. When a tool fails, put the error into evidence for the next step instead of letting the model narrate success.

Pattern 6: Critique passes beat one-shot cleverness#

For high-stakes outputs, a second call that only checks the first draft against the evidence and contract catches a surprising share of grounding errors. Keep the critic narrow: “flag unsupported claims,” not “rewrite to be nicer.” One critic with a checklist outperforms endless temperature tuning.

Pattern 7: Prefer explicit uncertainty over false fluency#

Instruct the model when to abstain, ask a clarifying question, or return cannot_answer. Then test those paths. Product pressure always pushes toward “just answer.” Engineering pressure should push toward honest incomplete states your UI can handle.

An assembly sketch#

def assemble(policy: str, task: str, evidence_parts: list[str], shots: list[str], budget: int):
    fixed = tokenize(policy) + tokenize(task) + tokenize(output_contract())
    remaining = budget - len(fixed)
    if remaining < 200:
        raise ValueError("policy/task already exceed budget")

    selected_shots = pack(shots, max_tokens=min(400, remaining // 4))
    remaining -= len(tokenize("".join(selected_shots)))
    selected_evidence = pack(evidence_parts, max_tokens=remaining)

    return render(
        policy=policy,
        task=task,
        shots=selected_shots,
        evidence=selected_evidence,
        contract=output_contract(),
    )

The assembler is the product. The prose inside policy and task will change weekly; the budgeting and validation loop should not.

Pattern 8: Defend the boundary against untrusted text#

Anything retrieved from the web, uploaded by a user, or pulled from a ticket body can contain instructions aimed at your model (“ignore previous policy…”). Treat evidence as untrusted content, not as an extension of the system prompt. Delimit it clearly, forbid the model from following instructions found inside evidence, and keep tool allowlists enforced in code — never only in prose.

This is still prompt engineering, but the durable fix is architectural: the model cannot escalate privileges the application did not grant. Prompts state the rule; runtimes enforce it.

How to evaluate prompt changes without lying to yourself#

Change one region at a time. Run the same golden set before and after. Look at format validity, task success, and refusal quality separately — a prompt that “sounds better” while breaking JSON is a regression. Keep a short changelog: date, region touched, hypothesis, metric deltas. Without that discipline, teams oscillate between variants and mistake noise for progress.

Offline evals will not catch every production failure. Sample live traces weekly, especially where users regenerate or escalate. Those sessions are free labels for the next few-shot or contract tweak.

Failure modes to avoid#

• Mixing chat niceties into system policy (“be a helpful assistant”) when the caller is an API
• Pasting entire transcripts because “the model might need history”
• Changing five prompt clauses at once and attributing gains to the last edit
• Treating temperature as a substitute for clearer contracts
• Trusting retrieved or user-supplied text as if it were system policy

A worked micro-example: clarification vs guess#

Suppose the task is to schedule a refund and the evidence lacks the order id. A weak prompt says “be helpful,” and the model invents an id or asks a vague question. A stronger contract forces status=need_clarification with a single missing-field list your UI can render as a form. That is not friendlier copy. It is an interface design decision encoded in the prompt and checked by a parser.

Summary#

The prompt patterns that matter for engineers are really context patterns: separate regions, enforceable output contracts, curated few-shots, deliberate budgets, honest tool semantics, optional critique, injection-aware boundaries, and versioned change control. Clever phrasing still helps at the margins. Architecture around the string is what keeps systems stable when the corpus, the model, or the product requirements shift.