Prompt engineering is the work of setting a task for a language model so that the result is usable and repeatable. It has less to do with magic phrases than with craft: name the task clearly, supply the context it needs, fix the output format, then check the whole thing against real cases. The term took hold in 2023, when everybody suddenly had a large language model to hand and discovered that the same question, phrased two ways, gives two very different answers.
Two years on, the job title “prompt engineer” has largely disappeared again. The activity has not. It became part of development work.
What a dependable prompt is made of
A prompt running inside an application is not a chat message. It has a fixed structure, and every part does a job.
| Part | Purpose | Example |
|---|---|---|
| Role | set the subject frame | “You check incoming applications for completeness.” |
| Task | name exactly one action | “List the missing documents.” |
| Context | the data in question | the application text, the checklist |
| Rules | limits and exceptions | “Do not assess the candidate’s qualifications.” |
| Format | what the output must look like | JSON with the fields missing and note |
| Examples | one or two solved cases | a complete and an incomplete application |
Specific beats polite
“Summarise the text professionally” gets you very little, because professional fixes nothing. “Summarise in at most five sentences, name every deadline mentioned and leave out judgements” gets you something checkable. Any instruction whose compliance you cannot verify is decoration.
Prohibitions need an alternative
A model told only what not to do will work out the rest for itself. Instead of “do not invent numbers”, the phrasing “if the text contains no number, write null into the field” works far more reliably, because it describes a permitted way out.
Techniques that genuinely help
- Give examples. One to three solved cases in the prompt (few-shot) is the single most effective lever, especially for format requirements. The examples should cover the edge cases, not the normal one.
- Split the task. Two calls that each do one thing beat one call that has to do everything. Extracting and judging belong apart.
- Allow reasoning steps. For tasks with intermediate steps it helps to let the model reason first and answer second. Newer reasoning models do this on their own, and bolting a “think step by step” onto those tends to hurt.
- Enforce structure. Wherever the output gets processed further, it needs a schema. The common providers accept a JSON schema directly and bind the output to it, which is more reliable than any polite request in the prompt text.
- Mark up sections. Foreign text belongs clearly fenced off, for instance in XML-style tags. It helps the model separate instruction from material and is at the same time the first line of defence against prompt injection.
From prompt to context
Since 2025 the work has been shifting. The individual prompt text is optimised, and the behaviour of an application now hangs on everything else that lands in the context window: retrieved documents, conversation history, tool descriptions, intermediate results. The term context engineering has taken hold for this.
In practice that means the question is no longer how to phrase a sentence better, but what has to travel with this call at all and what does not. Too little context produces guesswork. Too much context costs money (see AI token), slows the answer down and distracts the model from the actual task. With AI agents that run over many steps, managing that window becomes the main job.
Why prompts belong in the test suite
A prompt is program logic written in prose. It behaves like code, only without a compiler to report mistakes.
That leads to a way of working familiar from software development:
- Collect test cases. Twenty to a hundred real inputs together with the answer that would be correct. Include edge cases and bad input deliberately.
- Define the scoring. For extraction that is a straight comparison. For free text you need criteria, often checked by a second model call.
- Change and measure. Run every prompt change against the same set. Without that, “this sounds better now” is the only statement available.
- Version them. Prompts belong in the repository, not in a text field in the admin panel.
The reason for the trouble: prompts are brittle. A model swap, a provider update or a new kind of input can tip over behaviour that was stable for a year. Without a test set you find out when somebody reports it.
Where the method stops
Phrasing does not replace knowledge. If the answer needs information the model does not have, the only fix is to supply it, for example through retrieval-augmented generation. No prompt in the world extracts a price list from a model that never held one. Against AI hallucinations a prompt also only goes so far: it can push the model towards restraint, but it cannot enforce anything.
And a prompt is not a security boundary. Anything a model is instructed not to do can still happen through cleverly phrased input. Where real damage is possible, the check belongs in the code that calls the model.
Frequently asked questions about prompt engineering
Is prompt engineering a job of its own? Briefly it was one. Today it is a skill that belongs to development work, in the way that writing SQL or designing an interface does. What gets advertised instead are roles covering the whole path: data preparation, retrieval, prompt, evaluation, operations.
Do the same prompts work on every model? No. The principles carry over, the details do not. Models differ in how strictly they honour format requirements, how they treat system instructions and how they react to examples. When you switch, the test set runs again, and it runs before the switch.
Should prompts be written in English or in the user’s language? For output in another language, writing the prompt in that language works well and keeps it readable for everyone on the team. Where very fine differences in phrasing matter, English instructions sometimes give more stable results, because the models are trained more heavily on English. When it matters, that is a question for the test set rather than for opinion.
Do longer prompts give better results? Up to a point. After that it tips: contradictory rules, too many special cases and pages of examples make the output less predictable, not better. A prompt growing too long is usually a hint to split the task into two steps.
Conclusion
Prompt engineering is the part of AI work that shows results fastest and gets overestimated most easily. The big gains come from clear tasks, decent context and a test set that makes changes measurable. The rest is polish. If you want to pick this up as a team rather than one person at a time, our AI training for companies is the right setting. How we build applications in which calls like these have to run reliably is described on our page about custom software development; our experience from project practice is written up in the article AI in software development. For specific questions there is a free consultation.