What is prompt engineering, and which techniques still matter with current models?

Prompt engineering is the work of getting a model to do a job reliably through what you write to it: the instructions, the context, the examples and the shape of the answer you ask for. The name suggests clever phrasing. In practice it is closer to writing a good brief for a new colleague and then checking their work.

Start with a way to measure

Anthropic's own guide puts 2 things before any prompting: a clear definition of what a good answer is, and a way to test against it. Without them every change is a guess, and a prompt that reads better can quietly do worse on cases you did not look at. Keep a handful of test cases from the start and grow them into an eval setEval SetThe list of test cases an LLM app is graded on after every change. Each case is an input and what a good answer must do, so a score going up or down shows whether the change helped.. Not every failure is a prompting problem either: a slow or costly answer is often better fixed by choosing another model.

The techniques that hold up

• Be clear and direct. Write as if briefing a capable new employee who knows nothing about your business. Anthropic's test: show the prompt to a colleague; if they would be confused, so will the model.
• Say why. "Write order numbers as KX-48213, because the order lookup only finds that form" works better than the rule alone, because the model can apply the reason to cases you did not list.
• Show examples. 3 to 5 varied examples of input and ideal output, marked off in tags, are one of the most reliable ways to set format and tone (few-shot promptingFew-shot LearningPutting a few worked examples of the task in the prompt, so the model copies their format, labels and tone without any training.).
• Separate the parts. Wrap instructions, documents, examples and the user's input in their own tags, so the model never mistakes a customer's email for your instructions.
• Say what to do, not what not to do. "Write in plain paragraphs" beats "do not use Markdown".
• Put long documents first. With long inputs, documents at the top and the question at the end did better in Anthropic's tests, by up to 30%.
• Ask for a schema when code reads the answer. Structured outputStructured OutputA setting that makes a model's answer follow a JSON schema you give it, so your code can read fields such as a category or an order number without parsing free text. guarantees the shape, so the prompt can spend its words on content.

What changed

Some older techniques now matter less. "Think step by step" was a powerful trick before models had thinkingChain of ThoughtHaving a model write out the steps of its reasoning before it gives an answer. Once a prompting trick, now built into "thinking" models. built in; current Claude models decide for themselves when to reason, steered by an effort setting. Prefilling the start of a reply is rejected by current Claude models. Tutorials that spend pages on magic phrases describe models you are no longer calling.

The bigger shift is from the wording of one prompt to everything the model sees: documents, tool results, conversation history. That wider job is context engineeringContext EngineeringChoosing what goes into a model's context at each step of a task, what to fetch only when needed, and what to clear, note down or summarise as the context grows., and a prompt in production is code: kept in a file as a templatePrompt TemplateA prompt kept as a file with placeholders filled in at run time, so it can be versioned, reviewed and tested like the rest of your code., versioned, and tested on every change.