Skip to content

Prompt engineering

Updated 18 July 2026 Reviewed by Teemu Malinen

What is Prompt engineering?

The craft of writing instructions that reliably get the output you want from an AI model. Small changes in wording can shift the result a lot, so in production teams version and test prompts like code. It's less about clever tricks than about being specific about the task, the format and the constraints.

Why it matters

The same model will give you a vague answer or a useful one depending on how you ask. A prompt is the instruction you hand a model, and prompt engineering is the work of writing that instruction so the output is what you actually need, reliably, not just once by luck. For most people this is the first and often the only layer of AI work they ever touch: it needs no code, only a clear idea of what “good” looks like and the patience to phrase it well.

The term went mainstream fast. Wikipedia notes that prompt engineering gained prominence during the AI boom that followed ChatGPT’s release in November 2022, and that “prompt” was a runner-up for Oxford’s Word of the Year in 2023. The reason is simple economics: rewording a request is far cheaper than fine-tuning or swapping models, and it often closes most of the gap on its own.

What is prompt engineering?

Prompt engineering is the craft of writing instructions that reliably get the output you want from an AI model. DAIR.AI’s widely used guide calls it “a relatively new discipline for developing and optimizing prompts to efficiently use language models.” Wikipedia frames it as “the process of structuring natural language inputs… to produce specified outputs from a generative artificial intelligence (GenAI) model.” The common thread is that the prompt is the unit of work: you are shaping one instruction, its wording, its structure and its examples, so the model does the right thing.

It leans on a real property of large language models called in-context learning: the model can pick up a pattern from examples inside the prompt itself, with no retraining. That is why showing a model two or three worked examples often does more than describing the task in the abstract.

What goes into a good prompt?

A strong prompt usually carries a few parts, in some combination. Anthropic’s prompt engineering guidance is blunt about where to begin: before touching wording, have clear success criteria and a way to test against them, because you cannot improve a prompt you cannot judge. From there, the parts that recur across the vendor guides are:

  • A clear, direct instruction: say exactly what you want and in what form, rather than hinting.
  • Examples: one or more worked cases showing the pattern, which the model generalises from.
  • Relevant context: the specific facts, inputs or constraints the task needs.
  • An output format: the shape you want back, whether prose, a list, JSON or a table.
  • A role or system prompt: framing the model’s job up front, which shapes tone and focus.

What techniques actually work?

A handful of techniques have held up well enough to become standard. Few-shot prompting gives the model a small set of examples to copy; zero-shot asks with none. The best-known reasoning technique is chain-of-thought prompting, introduced by Wei et al. at Google in 2022, which showed that asking a model to work through “a series of intermediate reasoning steps… significantly improves the ability of large language models to perform complex reasoning.” A lighter version, zero-shot chain-of-thought, needs no examples at all: Wikipedia records that simply appending “Let’s think step by step” was found to improve results. Beyond these, guides catalogue self-consistency (sampling several reasoning paths and taking the most common answer), role prompting, prefilling the start of the model’s reply, and prompt chaining, splitting a hard task into a sequence of smaller prompts.

How is it different from context, harness and loop engineering?

Prompt engineering is the narrowest of four related layers, and the cleanest way to hold them apart is by what each one designs. Prompt engineering designs the wording of a single instruction. Context engineering designs what information enters the model’s window on a given turn, everything it sees, not just your instruction. Harness engineering designs the system an agent operates within: its tools, sandbox, guardrails and success criteria. Loop engineering designs the autonomous repetition, how an agent iterates without a human prompting each turn.

Some authorities nest these rather than treat them as peers. LangChain’s Harrison Chase writes that “prompt engineering is a subset of context engineering,” because as an application grows, providing complete, well-structured context matters more than clever wording of one line. Both framings agree on the direction of travel: as you move from a single chat message toward an autonomous agent, the prompt stops being the whole job and becomes one part of a larger system. Prompt engineering remains the foundation, though. Every layer above it still ends up sending the model instructions, and those instructions still have to be written well.

Where prompt engineering runs out

Prompt engineering hits its ceiling when the problem is not the wording. If the model lacks the facts it needs, no phrasing will conjure them. That is a context problem, solved by retrieval. If it needs to act in the world (run code, call an API, check a result), that is a harness problem. Clever prompting also cuts both ways: the same flexibility that lets a good instruction steer a model lets a malicious one hijack it. That is prompt injection, where text hidden in an input overrides the instruction you intended. Prompt engineering is necessary and cheap, but on its own it does not make an agent, and it does not make one safe.

Prompt engineering in practice

In practice prompt engineering is a loop of small edits. You write a first draft instruction, run it against a handful of real cases, see where it fails, and adjust: add an example where the model guessed wrong, tighten a vague phrase, specify the format it kept getting wrong. Anthropic’s guidance frames this as testing against success criteria rather than eyeballing one output. A support team writing a single reusable prompt for drafting replies will iterate it a dozen times against real tickets before it is trustworthy. The craft is less about a magic phrase than about disciplined revision against examples.

Frequently asked questions

Is prompt engineering still a useful skill?

Yes. Even as context, harness and loop engineering take on more of the work in agent systems, every one of those layers still sends the model written instructions, and those instructions have to be clear to work. Prompt engineering is also the cheapest lever there is: rewording a request costs nothing compared with fine-tuning or changing models, and it often closes most of the gap on its own.

What is the difference between prompt engineering and context engineering?

Prompt engineering is about the wording of your instruction. Context engineering is about everything the model sees on a given turn, the system prompt, the conversation history, retrieved documents and tool descriptions, and how that window is filled. Your prompt is one piece of the context. As applications grow more complex, LangChain argues, getting the whole context right matters more than the exact phrasing of one line.

Do I need chain-of-thought prompting?

Only for tasks that need reasoning. Chain-of-thought, asking the model to work through intermediate steps, was shown by Wei et al. in 2022 to improve performance on arithmetic, commonsense and symbolic reasoning. For simple lookups or rewrites it adds little and costs extra tokens. Reach for it when a task has steps the model keeps skipping.

What is prompt injection, and is it a prompt engineering problem?

Prompt injection is when text inside an input, a web page, a document, an email, contains instructions that override the ones you intended, hijacking the model’s behaviour. It is a security risk that comes from the same flexibility that makes prompting powerful, so it sits alongside prompt engineering rather than being solved by it. Guarding against it is a matter of system design, not better wording.

Where should I start?

Start by writing down what a good answer looks like and a few real inputs to test against. Then write a plain, direct instruction, try it on those inputs, and fix what fails: add an example, specify the output format, tighten vague words. That test-and-revise loop, not a secret phrase, is where reliable prompts come from.

Sources

Otto Sunnari, Sales and partnerships at Sofokus

Ready to start leveraging AI?

Call, email, or book a time straight from my calendar.

Otto Sunnari

Sales and partnerships