You ask an AI to “write something good” and receive five paragraphs that sound like a brochure discovered in an airport. The model has produced words. You had hoped for an idea. Somewhere between those two achievements sits prompt engineering.
Despite the job-title energy, the basic skill is approachable: explain the task, provide the information it needs, and check whether the answer actually works. There is no secret sentence that turns every chatbot into a reliable expert. There are, however, much better briefs than “do the thing.”
What is prompt engineering?
Prompt engineering means designing and testing the instructions given to an AI model. A prompt can include a question, a task, background material, examples and requirements for the result. For the underlying machinery, our guide to how large language models work explains why fluent answers are possible without treating the model as a person who knows your intentions.
Your latest message is only part of what the system may receive. Earlier messages, application instructions, retrieved documents and tool results can also occupy its context window. Anthropic’s context-engineering explanation distinguishes writing instructions from managing that broader collection of information. A beautifully written request cannot compensate for an essential document that was never supplied.
Think of the prompt as a brief to a very fast collaborator who has not attended your meetings. Including the meeting agenda helps. Assuming it has absorbed six months of office politics through the keyboard does not.
A useful prompt starts with a useful brief
Here is a practical checklist, rather than a compulsory five-part incantation:
- Task: what should the model produce or do?
- Context: which facts, source material and audience matter?
- Format: a paragraph, table, draft email or another usable shape?
- Constraints: what must be included, avoided or left undecided?
- Perspective: would a particular editorial role help?
For example: “Draft a 120-word product description for a ceramic cat mug, using only these specifications: 350 ml, white ceramic, printed black cat design. Write for people buying a small birthday gift. Use a warm, playful tone. Include the capacity. Do not invent dishwasher or microwave compatibility; those details have not been supplied.”
That request supplies decisions the model would otherwise have to guess. It also creates things you can inspect: the length, the stated capacity and any invented promises. It does not guarantee compliance. If the answer claims the mug survives volcanic temperatures, the brief has become a test it failed.
A role can guide tone and perspective: “Edit this as a patient technical editor” is reasonable. “You are a certified accountant with twenty years of experience” does not confer qualifications. Nor do you need a role for a straightforward request such as alphabetizing a list.
Show the result you mean
Examples are particularly useful when a label like “friendly” leaves too much room for interpretation. Anthropic recommends representative examples and clear instructions, adding detail in response to observed failures rather than burying the task beneath every imaginable exception.
Suppose you want short captions for photos of cats. You could supply an original example: “Photo: cat sitting inside an empty suitcase. Caption: Management has cancelled your holiday.” Then ask for three similarly brief captions for a cat asleep on a keyboard, while avoiding the holiday joke.
This is often called few-shot prompting when you provide several demonstrations; a direct instruction without demonstrations is commonly called zero-shot prompting. There is no universally correct number of examples. One can clarify a style; several varied ones can clarify a classification rule. Twenty nearly identical examples may just give your prompt a longer commute.
Ask for something you can check
Research on chain-of-thought prompting showed that worked reasoning demonstrations improved results on selected tasks and models. That is useful evidence, not proof that adding “think step by step” always makes an answer correct.
For practical use, ask for a concise explanation, assumptions and calculations that you can verify. If a model proposes a travel budget, request the individual amounts and their total. Check the arithmetic separately. A convincing explanation can still defend the wrong number.
For a complicated assignment, separate the parts when that makes review easier. With an article, you might first check the source outline, then request a draft, then inspect factual claims. Combining tasks is not inherently wrong; losing track of whether any of them succeeded is the problem.
If software needs a precise data structure, a plain instruction to “return JSON” should not be the entire reliability plan. APIs can offer schema-based structured output, as illustrated by Google’s 2025 Gemini API announcement. Check the actual values as well as their structure: a perfectly formatted wrong price remains a wrong price.
Give the model evidence, not encouragement to improvise
When the task depends on a document, provide it and identify the relevant passage. Ask the model to distinguish what the document says from what it infers, and to flag missing information. Then inspect the cited passages yourself. Asking for sources does not make invented sources impossible.
Applications can also retrieve material automatically; that is the idea behind retrieval-augmented generation. Retrieval and prompting address different parts of the job. Instructions tell the model what to do with evidence; retrieval helps bring evidence into reach.
Be selective about what you upload. For a tone edit, anonymized text may be sufficient. A customer’s address or an access key is usually unnecessary context for deciding whether a sentence sounds cheerful.
Improve the prompt by testing the result
Save a few realistic inputs and decide what success looks like before tuning the wording. For the mug example, check whether descriptions preserve specifications, avoid invented features and sound suitable for the intended audience. Try an incomplete specification too. Change one important instruction, compare the results, and keep the version that performs better across the examples.
This is different from fine-tuning. Hugging Face’s training guide describes fine-tuning as further training a pretrained model on task-specific data. Editing a prompt changes the input for a request; it is not that training process.
You do not need to become a professional whisperer of magic keywords. Give the model a clear brief, useful material and a result you can judge. And if the answer is still an airport brochure, tell it exactly which sentences earned that distinction.
