Prompt Engineering

Specifying a task to something that has no context on you

A prompt is a specification. The model has read a great deal and knows nothing about your product, your customers, or what your team means by "urgent". Anthropic's framing is the useful one:

Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.

Most prompt work is not clever phrasing. It is noticing that you asked for something you never defined.

What has to exist before you start

Anthropic's guide states its own prerequisites, and they are worth taking seriously because skipping them is what makes prompt work feel endless:

1. A clear definition of the success criteria for your use case
2. Some ways to empirically test against those criteria
3. A first draft prompt you want to improve

Without the second, you are not improving a prompt. You are changing it and reading the next answer, which tells you about one sample. LLM evaluations covers the machinery; the point here is that it comes first, not after.

Not everything is a prompt problem

The same guide is direct about the limits:

Not every success criteria or failing eval is best solved by prompt engineering. For example, you can sometimes improve latency and cost more easily by selecting a different model.

Three failures that look like prompt problems and are not:

• The model does not know your data. No instruction adds facts it never saw. That is retrieval: what is RAG.
• The output must always satisfy a rule. A prompt asks; it does not enforce. Constraining inputs and outputs covers where a rule has to live to be one.
• It is too slow or too expensive. Usually a model or an architecture choice, not wording.

Recognising these early saves the rounds of rewording that never converge.

The techniques, roughly in the order they pay

Be specific about the output. Vague in, vague out. Anthropic's test for this is the best one going: show your prompt to a colleague with minimal context and ask them to follow it. If they would be confused, the model will be too.

Give the reason behind the rule. An instruction with its motivation attached generalises better than the instruction alone. Their example: "NEVER use ellipses" works less well than "Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them." The second survives cases you did not anticipate, because the model can reason about the goal.

Show examples. Two or three examples of the shape you want do more for format and tone than a paragraph describing them. Few-shot prompting covers how many and what makes them work.

Separate the parts with tags. When a prompt mixes instructions, context, examples and the user's input, XML tags let the model tell them apart. Consistent descriptive names, nested where the content nests.

Give it a role. One sentence in the system prompt focuses tone and behaviour. System prompting covers what that parameter is and what it cannot enforce.

Say what to do instead of what to avoid. "Write in flowing prose paragraphs" beats "do not use markdown". Constraints covers format control in full.

Prompts are versioned artefacts

The habit that separates a prompt that keeps working from one that decays is treating it as code rather than as a setting.

Keep it in the repository, not in a dashboard. Change one thing at a time and run the evals. Record which model it was tuned against, because guidance is model-specific: Anthropic notes that where a technique names a model, it should be treated as measured on that model and re-checked before being applied to another.

That last point is the one that bites during an upgrade. Chain of thought is the clearest case. An instruction that helped on one generation can cost tokens and accuracy on the next.

Further reading

• Anthropic, Prompt engineering overview: the prerequisites and when prompt engineering is the wrong tool.
• Anthropic, Prompting best practices: the living reference for current models.
• System prompting: the instruction that sits outside the conversation.
• LLM evaluations: the measurement that makes prompt changes more than guesses.