Prompt Engineering

Prompt engineering is the practice of designing, testing and refining the instructions and inputs given to a large language model (LLM) so it reliably produces the output you need. It covers wording, structure, examples, role and format instructions, and how a task is split into steps, and it is judged against defined success criteria rather than by how clever a prompt sounds.

How Prompt Engineering Works

Anthropic's documentation frames prompt engineering as an empirical loop with three prerequisites: a clear definition of success for the use case, a way to test against it, and a first draft prompt to improve. From there you change one thing, rerun the same test cases and keep what measurably helps.

The common techniques are well established across model providers:

• Clarity and directness: state the task, the audience, the constraints and the expected format instead of hinting.
• Examples: show one or more sample inputs and outputs so the model can copy the pattern (often called few-shot prompting).
• Structure: separate instructions from reference material, for example with labeled sections or XML-style tags, so the model knows what is guidance and what is data.
• Role prompting: set the model's role or perspective, usually in a system prompt.
• Room to reason: let the model think through a problem before answering when accuracy matters more than speed.
• Prompt chaining: break a complex job into a sequence of smaller calls, each with its own prompt.

Why Prompt Engineering Matters

For product teams, a better prompt is often the cheapest way to improve an AI feature or an AI-assisted task. It needs no new model, no fine-tuning and no new infrastructure.

Its limit is just as important. Wording cannot supply facts the model was never given. A polished prompt built on an incomplete spec still returns a confident, well-formatted answer that is quietly wrong, because the model fills the gap with generic assumptions. Not every failure is a prompt problem either: Anthropic notes that some goals, such as lower latency or cost, are often easier to reach by choosing a different model.

Prompt Engineering Example

A product manager asks a model to "write acceptance criteria for password reset." The result covers only the happy path.

The revised prompt sets the role (a QA-minded product analyst), names the entity (a user account with a verified email), lists the states to cover (unknown email, expired link, reused link, too many requests), asks for Given/When/Then format and includes one sample criterion. The team runs both versions against the same five feature specs and checks one thing: does every listed state appear in the output? The revised prompt is kept only if it passes that check more often. The output is still reviewed as draft acceptance criteria, not accepted as final.

For a product-management take on this, see why PMs should engineer the input, not just the prompt.

Prompt Engineering vs. Context Engineering

Anthropic describes context engineering as the natural progression of prompt engineering. Prompt engineering is about writing and organizing the instructions. Context engineering is about curating everything the model sees at inference time: instructions plus tool definitions, retrieved documents, message history and memory. Writing a prompt is largely a discrete task. Context engineering is repeated on every turn, which is why it matters most for an AI agent running over many steps.