What Is Prompt Engineering? Core Techniques Explained

Prompt engineering is the practice of designing, testing and revising the instructions given to a language model so that it produces a useful result consistently, not just once. It combines clear writing with a small set of repeatable techniques: explicit instructions, examples, structure, room to reason, task decomposition and evaluation. The "engineering" part is the testing loop, since a prompt is only as good as its results on the inputs you have not tried yet.

What the term covers

A language model generates text by continuing from what it has been given. The prompt is everything it has been given: your request, any background, any documents, any earlier turns. Prompt engineering is deciding what goes into that input and how it is arranged.

That is a wider job than wording. It includes choosing which information to supply, what to leave out, whether to split the work across several calls, and how you will know the output is acceptable. Anthropic's documentation makes the last point the starting condition: before refining a prompt, have a definition of success and a way to test against it.

It is also narrower than it sometimes sounds. It does not change what the model knows or retrain it, and it will not make a model reliable at something it cannot do. Some problems, such as speed or cost, are better solved by choosing a different model than by rewriting a prompt.

The core techniques

The three major vendors, Anthropic, OpenAI and Google, publish guidance that overlaps heavily. The names differ; the ideas below appear in all three.

Clear, direct instructions

State the task, the audience, the purpose and the format explicitly. Models follow what is written, so anything you leave implicit is decided for you. The practical method for writing this kind of prompt is covered in how to write a good AI prompt.

Examples

Showing the model one or more sample inputs with the outputs you want is often more effective than describing the pattern. This is called few-shot or multishot prompting. Google's guidance recommends including examples as a default; Anthropic's recommends several varied examples so the model generalizes and does not copy one. See few-shot prompting for how to choose them.

Structure and delimiters

Separating the parts of a prompt, instructions here, source document there, examples in their own block, reduces misreading. Common devices are section labels, triple quotes and XML-style tags.

<instructions>
Classify the review below as positive, negative or mixed.
Reply with one word.
</instructions>

<review>
Arrived quickly, but the zip broke within a week.
</review>

The tags carry no special meaning to the model; they are simply unambiguous boundaries you can refer to by name.

Roles and system prompts

Telling the model who it is working as, and for whom, sets vocabulary, depth and tone for everything that follows. In an application this usually lives in a system prompt, separate from user input. The mechanics are in how to use system prompts.

Room to reason

For problems involving several steps of analysis, asking the model to work through its reasoning before giving an answer tends to improve accuracy; OpenAI's guide describes this as giving the model time to think, and Anthropic's as chain-of-thought prompting. A simple form:

First list the facts in the contract that bear on termination.
Then explain which clause applies and why.
Only then give your one-sentence answer.

Some current models have built-in reasoning modes that do this without being told. Check the vendor documentation for the model you are using, because step-by-step instructions can be redundant there.

Decomposition

A large task split into smaller prompts, each with one job, is easier to get right and easier to debug. Outline, then draft, then edit. Extract, then analyze. The pattern is known as prompt chaining.

Grounding in supplied material

When accuracy matters, give the model the reference text and instruct it to answer from that text, and to say when the text does not contain the answer. This does not eliminate errors, but it changes the task from recall to reading, which is the more dependable of the two.

Systematic testing

Change one thing, run the prompt against a fixed set of inputs, compare. Without this step, an edit that fixes one case can quietly break another. The method is described in how to test AI prompts.

The working loop

In practice prompt engineering is a cycle, not a single act of writing:

1. Define success. What must a good output contain? What would make it unusable?
2. Collect inputs. A handful of realistic cases, including an awkward one.
3. Draft. Start with clear instructions; add structure as needed.
4. Run and read. Read the outputs in full. Skimming hides the failures.
5. Diagnose. Name the specific shortfall: missed constraint, wrong register, invented fact.
6. Revise one thing. Then run the same inputs again.

Reach for the simpler techniques first. A clearer instruction often removes the need for examples; examples often remove the need for a chain.

Chat use versus building a product

For someone using ChatGPT, Claude or Gemini directly, prompt engineering mostly means writing complete requests and iterating in conversation. Mistakes are cheap because you see every answer.

For someone building a feature on top of a model, the prompt runs unattended on inputs the author never sees. That raises the bar: the prompt needs to handle empty input, hostile input and edge cases, produce a format code can parse, and keep working when the model version changes. OpenAI's documentation recommends pinning a specific model snapshot in production for this reason, so behavior does not shift underneath a tested prompt.

What it cannot fix

• Missing knowledge. If the facts are not in the model or the prompt, the wording will not supply them.
• Unverifiable output. A confident, well-formatted answer can still be wrong. Review remains your job.
• A vague goal. If you cannot say what a good answer looks like, no technique will find it.
• Model differences. A prompt tuned on one model may behave differently on another. Each vendor's guide notes model-specific behavior; re-test when you switch.

Where to begin

Pick one task you do often and write the prompt for it properly once. Compare a structured prompt from the library, for instance the debugging prompt or the research summary prompt, against what you would normally type, and note which parts you tend to omit. If you want to see how two versions of a prompt differ before running them, the prompt comparison tool puts them side by side.