Prompt engineering is the practice of designing and testing the instructions, examples and output requirements given to a language model. Its purpose is to make the model perform a defined task consistently enough for the intended use.
A useful prompt makes the task explicit. It states what evidence the model can use, how to handle missing information and what the response should contain. Prompt engineering also includes evaluating changes; a convincing response to one example is weak evidence that a prompt works across a workload.
The four parts of an effective prompt
Most application prompts contain an instruction, supporting context, the current input and an output specification. The parts can be separate messages or clearly labelled sections, depending on the interface.
Task: Classify the customer review as positive, negative or mixed.
Rule: Use mixed when the review contains both praise and criticism.
Review: The battery lasts two days, but the camera is disappointing.
Output: Return exactly one of the three labels.
The rule resolves a real ambiguity in the task. Without it, either the overall sentiment or the strongest complaint might determine the label. No amount of polished wording can resolve a decision the product team has not made.
Negative instructions can also be useful, particularly for explicit prohibitions. Pair a prohibition with the desired alternative where possible. “If the source omits the date, return null” gives clearer behaviour than “Do not guess.”
Zero shot, one shot and few shot prompting
Zero shot prompting supplies instructions without worked examples. One shot prompting adds one example. Few shot prompting adds several examples so the model can infer the desired pattern.
Examples are especially useful for ambiguous categories, unusual formats and exceptions. A sentiment classifier may need one positive review, one negative review and a mixed review. The examples should agree with the written rules.
Review: Arrived early and works perfectly.
Label: positive
Review: This is the third unit that has failed.
Label: negative
Review: Beautiful screen. Support took nine days to reply.
Label: mixed
The Language Models are Few Shot Learners paper established influential results for learning tasks from demonstrations in context. In context learning does not update the model's weights during the request.
There is no universal best number of examples. Start with cases that explain the decision boundary, then measure the effect of adding or removing them. Examples consume context and can introduce accidental patterns, such as a preference for the label that appears most often.
Chain of thought, role prompting and prompt chaining
Chain of thought prompting asks for intermediate reasoning or demonstrates worked solutions. Early research found improvements on several reasoning benchmarks. Whether it helps a particular task depends on the model and prompt. Models with built in reasoning support may need different instructions from earlier general purpose models.
Generated explanations can be incomplete or misleading. Treat them as outputs to assess, not as a verified account of the model's internal computation. Request concise evidence or checkable calculations when those are useful to the reader.
Role prompting establishes a perspective, such as a technical editor explaining a bug to a beginner. A role can influence tone and emphasis, but it does not confer qualifications or access to missing facts.
Prompt chaining separates work into calls with explicit intermediate results. For example, an application can extract fields, validate them in code and then draft a reply. ReAct combines reasoning and action in an iterative interaction with tools or an environment.
Prompt templates and context engineering
A prompt template stores reusable instructions and inserts request specific values. Version the template together with its examples and output schema so a release can be reproduced.
Context engineering covers the wider task of selecting and maintaining everything available during a model call, including instructions, retrieved documents, history, memory and tool results. Prompt engineering is one part of that work. A well written instruction cannot compensate for a missing policy or the wrong customer's record.
Security limits of prompt engineering
Prompt related risks include confidential information exposure, poisoned source material, prompt injection and jailbreak attempts. The terms overlap in practice. A malicious retrieved document can both corrupt an answer and attempt to redirect the model.
Message roles establish an intended instruction hierarchy, but compliance is not an access control guarantee. Keep credentials out of model context, authorise data retrieval in application code and validate tool requests before execution. See prompt injection for the trust boundary problem.
How to improve a prompt systematically
Write down the required behaviour before editing. Collect ordinary requests, ambiguous cases, missing information cases and known failures. Run the current prompt as a baseline, change one element and compare the results.
An ablation removes an instruction or example to test its contribution. If five cases show no change, the instruction may simply be untested. Add cases that exercise its purpose before deleting it.
Keep useful changes only when the evidence supports them. Record the prompt version, model configuration, evaluation results and any trade off in cost or response time.