Prompt engineering is the practice of writing instructions to a language model precisely enough that you get the output you wanted rather than a plausible-sounding approximation of it. That is the whole idea. The rest is craft.
It has a reputation for being either a fake discipline or a secret art, and it is neither. It is closer to writing a good brief for a capable freelancer who has no context about your business, will not ask clarifying questions unless invited to, and is extremely literal.
What actually changes the output
In rough order of how much difference they make:
- Context. The model cannot see your document, your codebase or your audience unless you put them in front of it. Most bad output is missing context, not bad prompting.
- A specified format. "Give me a table with columns X, Y, Z" produces something usable. "Tell me about X" produces an essay you then have to mine.
- A role or audience. "Explain this to a sceptical CFO" and "explain this to a new engineer" are different documents. Say which one you want.
- Constraints. Length, tone, what to leave out. Models default to comprehensive; comprehensive is rarely what you need.
- Examples. One or two samples of the output you want beats three paragraphs describing it. This is the single most underused technique.
What matters less than people think: elaborate role-play preambles, politeness, threats, and the long "you are a world-class expert" incantations that circulate. They are mostly harmless and mostly noise.
The four techniques worth knowing by name
Few-shot prompting
Show two or three examples of input and desired output before asking for the real one. Use it whenever the output has a house style — commit messages, support replies, product descriptions.
Chain of thought
Ask the model to work through the reasoning before answering. It genuinely improves multi-step problems: arithmetic, logic, anything where the answer depends on intermediate results. It also lets you see where it went wrong.
Decomposition
Break a large request into steps and run them separately. "Write me a launch plan" is one prompt and a mediocre answer. Audience, then channels, then a calendar is three prompts and a usable plan.
Explicit negative constraints
Tell it what not to do. "No preamble", "do not summarise what I asked", "if you are unsure, say so rather than guessing" each remove a specific recurring annoyance.
Twelve prompts worth keeping
Adapt the bracketed parts. These are patterns, not incantations.
- Critique before drafting. "Before you write anything, list the three biggest weaknesses in this brief and what you would need from me to fix them: [brief]"
- Rewrite at a level. "Rewrite this so a smart 15-year-old follows it without losing any technical accuracy: [text]"
- The steelman. "Make the strongest possible case against this decision, assuming I am wrong: [decision]"
- Extract to a schema. "Pull every [entity] from this text into JSON with keys [a, b, c]. If a field is absent, use null rather than inventing it: [text]"
- The interview. "Ask me one question at a time until you have enough to write [artefact]. Do not write it until you do."
- Format-first. "Answer as a table: column 1 [x], column 2 [y], column 3 [z]. No prose before or after."
- Assumption audit. "List every assumption you made answering that, and mark which ones would change the answer if wrong."
- Style transfer by example. "Here are two things I wrote: [a], [b]. Write [new thing] so it sounds like the same person."
- The reduction. "Cut this by 40% without losing meaning. Show only the result: [text]"
- Failure modes. "What are the five most likely ways [plan] fails, ordered by probability, with an early warning sign for each?"
- Second opinion. "Here is an answer you gave. Review it as a sceptical expert and list anything wrong or overstated: [answer]"
- Explain the diff. "Explain what changed between these two versions and why it might have been done: [a], [b]"
When prompting is the wrong fix
If you are rewriting the same prompt every day, you want a saved prompt or a small tool, not better wording. If the model keeps lacking the same context, you want to supply that context as a file or a system instruction, not repeat it. And if it is confidently wrong about facts, no prompt fixes that — you need a source in the context window or a different approach entirely.
The skill that transfers is not knowing magic phrases. It is noticing quickly that an answer is subtly wrong and being specific about why. That is editing, and it is the part that stays useful as models change.
Most of these patterns work on any capable assistant. If you are choosing one, ChatGPT and Claude are the two you will most often see compared, and both handle everything above.
