Glossary
Prompt engineering
Prompt engineering is the practice of writing and refining the requests you send a model so results are good and repeatable, which resembles briefing a capable stranger far more than it resembles engineering.
In plain terms
There is no secret vocabulary and there are no magic words. What works is what works when you brief a competent new colleague: say what you want, say who it is for, show an example of good, and say what to do if the material does not cover the question. The reason a plain habit acquired a grand name is that doing it systematically, and keeping what worked, turns out to matter far more than anyone expected.
Why it matters
It is the one improvement available to you today that costs nothing and belongs to you rather than to a vendor. On most everyday tasks the gap between a vague request and a well-specified one is wider than the gap between two models a generation apart, and only one of those gaps is free to close. It is also, quietly, the difference between a pilot that works and one that quietly ends: the pilots that fail rarely fail because the model was not clever enough.
How it works
Being specific about the output does most of the work. Who is going to read this, how long should it be, what format, what must it contain, what should it leave out. Four short lines of that kind change results more than any amount of rephrasing the request itself, and they are the lines people skip because they feel too obvious to write down.
Examples beat descriptions of examples. Two or three worked instances of the shape you want convey more than a paragraph explaining that shape, because the model can pattern-match against something concrete rather than interpret your adjectives. If you have ever struggled to describe a house style, this is the shortcut.
Most poor answers are missing context rather than missing capability. The model does not know your customer, your policy, your last conversation or the constraint that makes the obvious answer wrong, and it will not ask. Before assuming a task is beyond a tool, check whether the thing you have in your head reached the request.
Say what to do when it cannot answer. Given a question the supplied material does not cover, a model with no stated fallback produces something regardless. One sentence, telling it to say so instead, removes a whole class of confidently wrong output, and it is the single most useful line to add to any request that draws on documents.
It becomes engineering at the point you keep records. Change one thing at a time, run the result against a fixed set of real cases rather than the one that annoyed you, and save the version that won with a note on why. Without that, the same discoveries get made and lost repeatedly, which is what separates a practice from an afternoon of fiddling.
What makes it a practice rather than an afternoon
Seen in the wild
Rewrite one disappointing request four times, altering a single thing on each attempt, and keep the version that worked rather than the feeling that it improved.
ChatGPTAsk for the same output twice, once described in words and once with two worked examples attached, and see which comes closer to what you wanted.
ClaudePut a request inside an automation step where it runs unattended across hundreds of items, which is where inconsistency you would shrug at by hand turns into a problem.
n8n
Common misconceptions
People assume
There are magic words that get better answers.
In fact
There are habits, and they are unglamorous: be specific about the output, supply the material, show an example, state the fallback. Phrases that circulate as tricks are mostly rediscoveries of those four. Anything presented as a secret formula is worth testing against a plainly worded version of the same request.
People assume
It is a specialism you hire for.
In fact
It was briefly a job title and it works better as a skill folded into existing roles. The hard part is knowing what a good output looks like in your field, which the person doing the work knows and a prompting specialist does not. Teach the domain expert the habits rather than hiring somebody to guess at their standards.
People assume
Better models will make it unnecessary.
In fact
Models have improved considerably and the gap between a vague request and a specific one has not closed, because the missing information is still missing. A more capable model guesses better at what you meant. It still cannot know the constraint you did not mention.
Telling them apart
Prompt engineering vs Prompt
Prompt engineering
The practice: how you arrive at a request that works, and how you keep it once you have it.
The artefact: the request itself, on one occasion.
Anyone can write a prompt. The practice is what makes the second hundred as good as the one you got lucky with, and it is mostly bookkeeping rather than wording.
Prompt engineering vs Fine-tuning
Prompt engineering
Instructions supplied with each request. Free, changed in a minute, and paid for in the space it occupies on every call.
Behaviour trained into the model. Needs a dataset, costs to produce, and then needs no instructions at run time.
Do this first, always. It is quicker, cheaper and reversible, and it tells you what the remaining gap actually is before you spend anything closing it.
Questions
- Is there a formula I can follow?
- A serviceable one: state the task, say who the output is for and how long it should be, supply the material it needs, show one example of good, and say what to do if the material does not cover the question. That covers most everyday work. The rest is noticing which of the five you keep omitting.
- How do I stop retyping the same instructions?
- Move them into your assistant's standing instructions, where they are sent automatically with every conversation. The rule of thumb is that anything typed into three separate conversations was never a prompt and belongs in the standing brief instead. Keep it short, since it is sent and paid for every time.
- How do I know a change actually helped?
- Keep a small set of real cases, ten or so including the awkward ones, and run any change against all of them rather than against the example that irritated you. Improvements that only show on one case are usually noise. This is the part that turns fiddling into something you can hand to a colleague.
- Does the wording that works transfer between tools?
- Partly. The habits transfer completely, since being specific and supplying context help everywhere. Particular phrasings transfer less reliably, because products differ in their standing instructions and their models differ in disposition. Re-test a request that matters when you move it, rather than assuming it carried across.
Key takeaways
- The gains come from four unglamorous habits, not from special vocabulary.
- Being specific about the output changes results more than rephrasing the request.
- Most poor answers are missing context rather than missing capability.
- One sentence about what to do when the material does not cover it removes a class of wrong answers.
- The engineering is the record you keep, which is why the skill transfers when the wording does not.
Last checked July 2026