Prompt engineering best practices

6 min read · Updated 2026-08-10

Most “the model isn’t good enough” problems are really prompt problems. A capable model given a vague instruction has to guess your intent, your format, and your constraints — and it guesses differently every run. Good prompt engineering removes the guessing. These are the practices that move the needle before you reach for anything clever.

1. Be specific about the task

Say exactly what you want, for whom, and in what form. Replace “summarize this” with “summarize this support ticket in one sentence for an on-call engineer, focusing on the user’s blocker.” Vague verbs (analyze, improve, handle) are where quality leaks out.

• State the goal and the audience.
• Name the inputs the model should use and the ones it should ignore.
• Give the success criteria (“a valid IATA code,” “3–5 bullet points,” “no more than 40 words”).

2. Give the prompt a structure

A wall of text is hard for a model to follow. Use clear sections — a role, the instructions, the input, and the output format — separated with headings or delimiters. Delimiters (""", <tags>, ### Input) also prevent the model from confusing your instructions with the user’s data.

### Role
You are a support triage assistant.

### Instructions
Classify the ticket's priority as low, medium, or high, and summarize the blocker in one sentence.

### Ticket
"""
{{ticket}}
"""

3. Show, don’t just tell (few-shot)

When a rule is easier to demonstrate than to describe, give one to three examples of input → ideal output. Examples pin down tone, edge cases, and format far more reliably than adjectives. Keep them short, correct, and representative — a wrong example teaches the wrong thing. See Few-shot prompting.

4. Constrain the output

Decide the output format up front and make it explicit. If your code parses the result, ask for structured JSON and give a schema; brittle string-parsing is where integrations break. If it’s prose, cap the length and define the shape. See Structured outputs & JSON.

5. Tell the model what to do when unsure

Left unguided, models fill gaps with confident guesses. Give an explicit escape hatch: “If the ticket doesn’t state a priority, return unknown — do not invent one.” Defining the failure mode is as important as defining the success case, and it’s the cheapest way to cut hallucinations.

6. Put durable rules in the system prompt

The role, tone, hard constraints, and output contract belong in the system prompt — set once, applied to every call — while the per-request data goes in the user message. This keeps behavior consistent and your prompts clean. See Designing system prompts.

7. Iterate against evals, not vibes

“Looks good” doesn’t scale. Collect a handful of real inputs (including the awkward ones), define pass/fail checks, and re-run them every time you change the prompt or the model. Otherwise a small edit silently breaks a case you fixed last week. See Evaluating prompts.

A quick checklist

• The goal, audience, and output format are explicit.
• Instructions and input data are clearly separated.
• There’s an example if the format is non-obvious.
• The output is constrained (JSON schema or length/shape).
• There’s a defined behavior for missing or ambiguous input.
• It’s tested on every model you plan to run it on.

Common mistakes

• Overloading one prompt. If a prompt does five things, split it into steps or a flow — each step is easier to get right and to evaluate.
• Politeness as instruction. “Please try to be accurate” does nothing; a concrete constraint or an example does.
• Assuming portability. A prompt tuned on one model can behave differently on another. Test before you switch.