What Is Prompt Engineering?
What prompt engineering is, why the wording of a request changes what an AI model gives back, and where good prompting stops helping.
What prompt engineering is
The terms prompt and prompt engineering are defined in Working with LLMs: a prompt is the text you give a language model, and prompt engineering is designing and testing prompts so that the model reliably gives the output you need. This topic goes further into the second part: how to write those prompts, why the techniques work, and how to tell whether a prompt is actually good.
Most people meet prompts through an AI assistant: a chat application built around a large language model that answers requests written in ordinary language, and can often also read files, search the web or use other tools. Well-known examples as of October 2026 are Claude (Anthropic), ChatGPT (OpenAI), Microsoft Copilot (formerly Microsoft 365 Copilot) and Gemini (Google). Behind each one sits the same basic machine: a large language model that turns the text it receives into new text.
Prompt engineering happens in two places. In a chat, you write the prompt yourself, read the answer and ask again. Inside software, a developer writes the prompt once and the program sends it thousands of times, filled with different tickets, logs or emails. The principles are the same; the second case simply needs more care, because no one reads each answer before it is used. Both are covered here.
How this topic works
Every page explains a technique, shows prompts that use it and explains why it works in terms of how models behave. Three kinds of blocks recur:
- Prompts are shown in blocks with a label such as "Prompt · vague" or "Prompt · specific". Before-and-after pairs are the main way this topic teaches.
- Model answers are labeled "Response · illustrative". They are examples of the kind of answer you may get, written to make a point. Real answers differ from run to run and from model to model, so no page presents one as what a particular model "says".
- Try it yourself boxes hold two or more prompts to paste into an AI assistant (Claude, ChatGPT, Copilot, Gemini or another), followed by what to look for when you compare the answers. They are experiments, not quizzes: there is no single right answer to check against.
Two rules apply to every Try it yourself box:
- One new chat per prompt. An assistant sends the whole conversation to the model with every message (see Stateless: the history is sent again), so an earlier prompt in the same chat would influence the next answer and spoil the comparison.
- Fictional data only. The prompts use Kestrel Energy, a made-up Dutch energy supplier, with invented tickets, people and addresses. Paste them as they are. Do not swap in real tickets, logs, customer data or anything confidential: that belongs only in a tool your organization has approved for it (see What never to paste).
The technical pages also contain small Python programs that build, check or test prompts. They run on your own computer with the standard library only, never call an AI service, and use recorded answers written into the code. The background on what language models are, how they are trained and where they fail is in the Artificial Intelligence topic; this topic links to it instead of repeating it.
Why the wording changes the answer
A language model does not look up an answer to your question. It predicts a continuation of the text it was given, one token at a time (the mechanics are on How a Model Reads Your Prompt). Microsoft's prompt engineering guide makes the same point: the model "isn't following a separate 'Q&A' code path", it is responding with what it determines is most likely to follow. Your prompt is the start of a document, and the answer is the most plausible rest of it.
That has a direct consequence. Everything your prompt states, the model can use. Everything it leaves open — the audience, the length, the facts, what to do when something is unknown — the model fills in with whatever is typical. Typical is often fine. But when the missing piece is a fact, typical means invented.
Write something about the outage.We are aware of an issue affecting some of our services. Our engineers have identified the cause as a network problem and expect everything to be working again by 15:00. We apologize for any inconvenience.
Nothing in the prompt said which outage, which service, what the cause was or when it would be fixed, so an answer like this one invents all four. It reads well, which is exactly the danger. The specific version supplies the facts and the frame:
Write a three-sentence update for Kestrel Energy customers about INC-40217: the customer portal was unavailable from 08:10 to 09:05 today; meter readings submitted during that time were not saved; customers should resubmit them. Plain language, no technical terms, no apology longer than one sentence.Instruction following
A freshly trained model only continues text; it would answer a question with more questions. Assistants behave differently because of extra training on example conversations and human feedback (see From text predictor to assistant). The result is instruction following: a model's learned ability to treat the text it receives as a request and carry out the instructions in it, including details such as length, format and tone. It is a trained tendency, not a rule engine. Models follow clear, explicit instructions well and unclear or conflicting ones unpredictably, and they never check with you before guessing unless you ask them to.
Prompt sensitivity
Prompt sensitivity is the way a model's output can change noticeably after small changes to a prompt that a person would consider equivalent: another word, a different order, an extra sentence. It is real, and it is hard to predict. A 2025 study in the Wharton "Prompting Science Report" series reported that variations in prompting can make a large difference on individual questions, while it is hard to know in advance whether a particular approach will help or harm. On top of that, the same prompt can give different answers on different runs (see sampling), and Microsoft's Copilot guidance tells users to expect exactly that.
The practical lesson is to judge a prompt on several runs and several inputs, never on one lucky answer. That is the subject of Iterating and Testing Prompts.
Try it yourself
Open a new chat in an AI assistant (Claude, ChatGPT, Copilot, Gemini) and paste the first prompt. Then start another new chat and paste the second.
Write something about the outage.Write a three-sentence update for Kestrel Energy customers about INC-40217: the customer portal was unavailable from 08:10 to 09:05 today; meter readings submitted during that time were not saved; customers should resubmit them. Plain language, no technical terms, no apology longer than one sentence.What to look for: whether the first answer invents a cause, a time or a promise (or asks you which outage you mean); how long each answer is and who it seems to be written for; whether the second answer contains only the facts you gave and keeps to three sentences. Run the second prompt once more in a third new chat and compare the wording of the two runs.
A briefing, not a spell
Much early advice about prompting read like a collection of magic words. The guidance the model providers publish today (as of October 2026) is plainer. Anthropic asks you to think of the model as "a brilliant but new employee who lacks context on your norms and workflows". Microsoft's Copilot guidance says that "all that's required is a clear goal", plus context, expectations and sources, and that you will most likely follow up with another prompt. Google and OpenAI give similar advice: be clear and specific, provide the context, show examples, test.
In other words, a good prompt is a good briefing. If you have written a clear ticket, handover or request for help (see Writing Tickets and Technical Documentation and A good help request), you already know most of what matters: state the goal, give the facts, say what the result should look like and what to do when something is unclear.
Newer models also need less scaffolding than older ones. OpenAI's developer blog notes that "with more capable models, what used to require a lot of handholding and scaffolding no longer does", and Anthropic advises toning down emphatic instructions written for earlier models because current ones may now overreact to them. A trick that helped in 2023 can be useless or harmful today, which is one more reason to test instead of collecting tricks.
The main prompting techniques
A prompting technique is a reusable way of writing or organizing prompts that makes a certain kind of result more likely, such as adding examples, asking for a fixed format or splitting a task into steps. None of them is a guarantee; each shifts the odds, and each has a cost in length, time or tokens. The techniques in this topic:
| Technique | What it does | Page |
|---|---|---|
| Building a prompt from parts | Covers task, context, input, format and constraints | Anatomy of a Good Prompt |
| Clear, specific instructions | Leaves the model less to guess | Clear and Specific Instructions |
| Reference material | Gives the model the facts instead of its memory | Giving Context and Reference Material |
| Roles and system prompts | Sets tone, focus and standing rules | Roles and System Prompts |
| Examples | Shows the pattern instead of describing it | Zero-Shot, One-Shot and Few-Shot Prompting |
| Structured output | Gets answers a program can read and check | Structured Output |
| Reasoning before answering | Gives the model room to work through a problem | Reasoning: Step by Step and Thinking Models |
| Prompt chaining | Splits a large job into steps you can check | Breaking Down Tasks: Prompt Chaining |
| Grounding and "I don't know" | Makes invented facts less likely and easier to spot | Reducing Hallucinations |
| Testing and templates | Turns a prompt that worked once into one that keeps working | Iterating and Testing Prompts, Prompt Templates and Reuse |
The last pages apply these techniques: Prompts for IT Work, Prompting for Code, Prompts in Applications: the API, Context Engineering and Agents and Prompt Security and Responsible Use.
Where prompting stops helping
Good prompts make good answers more likely. They do not make a model reliable, and some problems cannot be solved with wording at all. Anthropic's documentation says it directly: not every problem "is best solved by prompt engineering"; latency and cost, for example, are sometimes easier to improve by choosing a different model. The main limits:
- Knowledge the model does not have. No phrasing teaches a model your network plan, today's incidents or a procedure written last week. You have to put that material in the prompt or let the application retrieve it (see Giving Context and Reference Material and retrieval-augmented generation).
- Truth. Prompting reduces invented facts but does not eliminate them; a fluent answer can still be wrong (see Hallucination: fluent is not true and Reducing Hallucinations). Check what matters.
- A guaranteed format. "Answer in JSON" usually works and sometimes does not. When a program depends on the shape, use the structured-output features of the API and validate the result anyway (see Structured Output).
- Identical answers. The same prompt can give different answers. Even temperature 0 never guaranteed identical output, as Anthropic's migration guide notes, and several current models no longer accept a temperature setting at all (as of October 2026; see Temperature).
- Security. An instruction such as "never reveal customer data" is text the model weighs, not a lock. Text in a document or email the model reads can override it. Access control belongs in code and permissions (see System prompts and user prompts and Prompt injection).
- Learning. A model does not learn from your prompts. The next request without your examples or corrections starts from scratch (see Few-shot prompting).
A skill for everyone, not a job title
Around 2023, "prompt engineer" was talked about as a new profession. In April 2025 the Wall Street Journal reported that the job title was already fading: as models improved and more people learned to use them, the skill moved into ordinary jobs. That is the view this topic takes. A service desk analyst drafting a customer reply, a network engineer asking for help with a log and a developer building a ticket classifier all do prompt engineering, at different levels of rigor.
It is also part of what is now called AI literacy: knowing what these tools can and cannot do, using them within the rules, and checking their work. Writing good prompts is the visible half of that skill. Judging the answers is the other half, and it stays your responsibility (see Human accountability).