Prompt Engineering Best Practices for Developers

The most important prompt engineering best practices are simple: state the task and constraints explicitly, give the model the context it needs, show an example of the output you want, and test prompts against real inputs like any other code. Clever wording tricks matter far less than clarity and evaluation. Treat a prompt as a specification for a capable but literal new teammate who knows nothing about your product.

What is prompt engineering?

Prompt engineering is the practice of designing the input to a language model so it reliably produces useful output. For developers, that input usually has several parts: a system message that sets role and rules, optional examples, retrieved context, and the user's request. Because a large language model predicts likely continuations of whatever you give it, the structure and specificity of that input directly shape the result.

Prompt engineering best practices

1. Be explicit about the task, audience, and format

Vague prompts get generic answers. Compare:

The strong versions define who the output is for, what to include, and the exact shape of the answer.

2. Separate instructions from data with delimiters

When you paste user content or documents into a prompt, mark clearly where they start and end. XML-style tags or fenced sections work well. This helps the model distinguish your instructions from the material it should act on, and it reduces the chance that text inside a document is treated as a command.

You are extracting action items from meeting notes.
Only use information inside the <notes> tags.
Return a JSON array of objects with keys "owner" and "task".
If there are no action items, return [].

<notes>
{{meeting_notes}}
</notes>

3. Show, do not just tell: few-shot examples

One or two input and output examples often communicate format and tone better than a paragraph of rules. Pick examples that cover the tricky cases, such as an empty result or an ambiguous input. Keep them short and consistent, because the model will copy their style closely, including their mistakes.

4. Ask for structured output

If code will consume the answer, request JSON that matches a schema, and use your provider's structured output or JSON mode when available. Then validate it. Structured output removes chatty preambles, makes parsing deterministic, and usually reduces tokens.

import { z } from "zod";

const ActionItems = z.array(
  z.object({ owner: z.string(), task: z.string().min(1) })
);

export function parseActionItems(raw: string) {
  const result = ActionItems.safeParse(JSON.parse(raw));
  if (!result.success) {
    throw new Error("Model output did not match schema: " + result.error.message);
  }
  return result.data;
}

5. Give the model room to reason when the task is hard

For multi-step problems, ask the model to work through the steps before giving a final answer, or use a model with built-in reasoning. When you only need the final answer in your app, ask for the reasoning and answer in separate fields so you can discard the reasoning or log it for debugging.

6. Provide the context instead of hoping the model knows

Models do not know your internal APIs, your pricing rules, or yesterday's incident. Put the relevant facts in the prompt, ideally retrieved dynamically. That is the core idea behind retrieval-augmented generation; see what is RAG and our deeper article, RAG explained. Also tell the model what to do when the context does not contain the answer, for example: "If the answer is not in the documents, say you do not know."

7. State constraints positively and specifically

"Do not be verbose" is weaker than "Answer in at most 3 sentences." "Do not make things up" is weaker than "Only cite facts from the provided documents and include the document ID for each claim." Positive, checkable constraints are easier for the model to follow and easier for you to test.

8. Assign a role only when it adds information

A system message like "You are a senior security reviewer. Flag injection risks and unsafe deserialization first." helps because it implies priorities and vocabulary. "You are a helpful assistant" adds little. Use roles to encode expertise, audience, and tone.

9. Break complex work into a chain of prompts

One giant prompt that retrieves, analyzes, formats, and self-checks is hard to debug. Split it into steps, each with a clear input and output: classify the request, gather context, draft, then validate. Each step can use a different model size, which also helps cost. When steps need to call tools and decide what to do next, you are building an agent; see what is an AI agent.

10. Version and evaluate prompts like code

Prompts regress. A small wording change or a model upgrade can quietly break an edge case. Keep prompts in source control, and maintain an evaluation set of real inputs with expected properties. Score new prompt versions against it before shipping:

• Exact-match checks for labels and structured fields
• Schema validation for JSON outputs
• Rubric scoring, by humans or a grader model, for open-ended text
• Regression cases for every bug you have fixed

Common prompt engineering mistakes

• Burying the key instruction in the middle of a long prompt. Put critical rules near the start and restate the output format at the end.
• Contradictory rules, such as "be thorough" and "be brief," without saying which wins.
• Examples that do not match the stated format.
• Trusting user-supplied text. Treat it as data, keep sensitive instructions out of reach, and never give the model permissions you would not give the user. Prompt injection is a real risk whenever untrusted content reaches the prompt.
• Tuning prompts by vibes on three examples instead of measuring on a representative set.

Prompting vs RAG vs fine-tuning

Start with prompting, add retrieval for knowledge gaps, and consider fine-tuning only when the first two plateau. Our guide on RAG vs fine-tuning walks through that decision.

A reusable prompt template

A structure that works for most application prompts:

1. Role and goal: who the model is and what success looks like.
2. Rules: specific, checkable constraints.
3. Context: retrieved documents or data, inside delimiters.
4. Examples: one or two input and output pairs.
5. Task: the user input, inside delimiters.
6. Output format: the schema or exact shape, restated last.

Shorter prompts are also cheaper; see how to reduce LLM API costs for how prompt structure affects prompt caching.

Key takeaways

• Clarity beats cleverness: define task, audience, constraints, and output format.
• Use delimiters to separate instructions from data and to reduce injection risk.
• Few-shot examples and structured output make results consistent and parseable.
• Supply context explicitly and say what to do when it is missing.
• Split complex tasks into steps and evaluate every prompt change against a test set.

Frequently asked questions

What makes a good prompt?

A good prompt states the task, the audience, the constraints, and the exact output format, and it includes the context the model needs. Adding one or two representative examples usually improves consistency more than adding more rules.

Do prompt engineering tricks still matter with newer models?

Newer models follow instructions better, so phrasing tricks matter less. Clear structure, relevant context, explicit output formats, and systematic evaluation still make a large difference in reliability.

How long should a system prompt be?

As long as it needs to be and no longer. Remove rules the model already follows and anything your evaluation shows has no effect, because every extra token adds cost and can dilute important instructions.

How do I test prompts?

Build a set of real inputs with expected outputs or properties, then score each prompt version against it using exact checks, schema validation, and rubric-based grading. Rerun the set whenever you change the prompt or the model.