Is prompt engineering a real skill or just marketing?

It is a real and fairly small skill. The techniques take an afternoon to learn and a while to apply consistently. What makes it valuable is not difficulty but discipline — most people never write down the context, constraints and success criteria that only exist in their heads, and that is where most of the quality gap comes from.

Will prompt engineering become obsolete as AI improves?

The performative parts already have. Nobody needs to tell a modern model it is a world-class expert. The informational parts will not become obsolete, because no model can guess constraints and context that were never supplied. The skill is shifting from coaxing models toward specifying tasks.

How long should a prompt be?

As long as it takes to say what the model cannot infer, and no longer. A one-line prompt is fine for a task with no hidden requirements. A prompt with 500 words of genuine context is fine when the task depends on that context. Padding a prompt with filler makes it worse, because it dilutes attention across text that constrains nothing.

Do I need different prompts for different AI models?

The content stays the same; the syntax changes. Claude follows XML-delimited structure most reliably, ChatGPT works well with markdown headings, Gemini prefers the task stated first, and image models need comma-separated descriptors rather than sentences. See the [model comparison guide](/guides/claude-vs-chatgpt-vs-gemini/) for the specifics.

What is the single fastest way to improve a prompt?

Add one example of a correct answer. It communicates format, length, register and depth simultaneously, all of which are ambiguous when described in prose. If you cannot produce an example, the next best step is stating explicitly how you will judge the result.

Does being polite to an AI improve the output?

Not measurably, and it costs tokens. Politeness is harmless and many people prefer it, but it is not a prompting technique. Specific constraints and concrete examples change output; "please" does not.

What is prompt engineering?

Published 2026-07-26

Prompt engineering is the practice of writing and refining instructions so a language model produces the output you want reliably, rather than occasionally. It is less about clever phrasing than about supplying what the model cannot infer: the task stated precisely, the background it lacks, the shape of the answer, and how the result will be judged.

What does prompt engineering actually mean?

Prompt engineering is the practice of writing and refining the instructions given to a language model so that it produces the output you want reliably. The word "engineering" is doing real work in that sentence. A prompt that produced a brilliant result once and a mediocre one the next time has not been engineered — it got lucky.

That distinction is the whole discipline. Anyone can write a prompt that occasionally works. The skill is in writing one that works on the tenth input as well as the first, on the awkward edge case as well as the tidy example, and next month on a newer model version.

It helps to be precise about what a prompt actually is. A prompt is not a question — it is several distinct jobs bundled into one piece of text: naming a role, supplying context, stating a task, bounding the output, and defining the format. Prompts that separate those jobs explicitly behave far more predictably than prompts that blend them into a paragraph.

Why does prompt engineering still matter as models improve?

A reasonable objection: if models keep getting better at understanding intent, does careful prompting not become obsolete? The answer is no, for a reason that has nothing to do with model capability.

A model cannot read your mind, and most of what makes an output good lives in your head rather than in the request. When you ask for "a blog post about composting", the model does not know your reader has no garden, that you have 900 words of space, that you have already covered wormeries, or that the piece must not recommend anything over £50. No amount of model improvement recovers information that was never supplied.

What has changed is which techniques matter. Elaborate incantations and "you are a world-class expert" framing have faded, because models no longer need coaxing into competence. What has not faded is specificity, context, examples, constraints, and stated success criteria. Those supply information rather than perform confidence, and information is not something a better model can guess.

A useful test: if a competent human freelancer could not complete your brief without asking a question, neither can a model. The difference is that the freelancer asks, and the model invents.

What are the six parts of a strong prompt?

Almost every prompt that works well contains the same six ingredients. Almost every prompt that disappoints is missing three or more of them.

Part	What it answers	What happens without it
Task	What exactly should be produced?	The model picks a scope, usually broader and blander than you wanted.
Context	What does the model not know?	It fills gaps with generic assumptions, or invents specifics.
Format	What shape should the answer take?	You get prose when you wanted a table, or 200 words when you needed 900.
Constraints	What must it do and avoid?	Obvious-to-you requirements are silently violated.
Examples	What does a correct answer look like?	Structure, register and depth are all guesswork.
Success criteria	How will the result be judged?	The model has nothing to check its own work against.

These are not equally weighted. Specificity of the task and definition of the output format between them account for the largest share of quality, because they constrain the most downstream decisions. Examples are the highest-leverage thing most prompts are missing, since a single worked example communicates format, length, register and depth at once — all things that take several ambiguous paragraphs to describe.

You can see this weighted explicitly in the rubric this site publishes, which scores prompts against exactly these six dimensions.

What is the difference between a good prompt and a bad one?

Take a real request and watch what changes. Here is a prompt of the kind people actually write:

Write a good blog post about composting. Make it engaging and comprehensive.

Three of those words — "good", "engaging", "comprehensive" — read as requirements but constrain nothing. None of them can be checked. The model cannot tell whether it has satisfied them, so it optimises for something safe and generic, and you get an article that could have been written about any topic by anyone.

The same request, with the missing information supplied:

Write a 900-word guide to composting for people in rented UK flats
with no garden or balcony.

Context: readers share a bin store and have limited under-sink space.
The two questions they ask most are about smell and fruit flies.

Requirements:
- No equipment costing more than £50
- Only name products available in the UK
- Do not recommend worm bins or anything needing outdoor space
- Open with a specific concrete detail, not a general statement

Done when: a renter could start this weekend, and every product
named can actually be bought in the UK.

Nothing here is clever. It is the same request with the information that was previously only in the writer's head. That is what prompt engineering mostly is.

Which prompting techniques are worth learning?

Beyond supplying information, a small number of named techniques genuinely change results. Each is worth knowing when it applies — and worth skipping when it does not.

Few-shot prompting — showing two to five worked examples so the model infers the pattern. The single largest improvement available to most weak prompts.
Chain-of-thought prompting — asking for reasoning before the answer. Helps on arithmetic, logic and analysis; hurts on short creative work.
Role prompting — naming the expertise the model should apply. Useful when the role implies a concrete standard, useless when it is flattery.
System prompts — putting persistent rules where they persist, rather than repeating them every turn.
Structured output — constraining the response to JSON or a fixed schema when something downstream has to parse it.

What is conspicuously absent from that list is anything about tone of voice toward the model. Politeness, threats, offers of payment, and claims that the task is "very important" do not reliably change output quality. They consume tokens and attention that specificity would use better.

How do you know whether a prompt is actually working?

This is where most prompt work quietly falls apart. A change is made, one example looks better, and the change is declared an improvement. That is not a measurement — it is an impression, on a sample of one, from someone hoping it improved.

The minimum viable discipline is small: collect ten inputs that represent the real range of what you will send, including the awkward ones, write down what a correct output looks like, and re-run all ten after every prompt change. This catches the most common failure in prompt work, which is overfitting a prompt to the two or three examples you happened to test with.

It also catches something you cannot anticipate: prompts regress when the model version changes, with no edit on your side. Keeping the test set is the only way to notice.

Common questions

Is prompt engineering a real skill or just marketing?: It is a real and fairly small skill. The techniques take an afternoon to learn and a while to apply consistently. What makes it valuable is not difficulty but discipline — most people never write down the context, constraints and success criteria that only exist in their heads, and that is where most of the quality gap comes from.
Will prompt engineering become obsolete as AI improves?: The performative parts already have. Nobody needs to tell a modern model it is a world-class expert. The informational parts will not become obsolete, because no model can guess constraints and context that were never supplied. The skill is shifting from coaxing models toward specifying tasks.
How long should a prompt be?: As long as it takes to say what the model cannot infer, and no longer. A one-line prompt is fine for a task with no hidden requirements. A prompt with 500 words of genuine context is fine when the task depends on that context. Padding a prompt with filler makes it worse, because it dilutes attention across text that constrains nothing.
Do I need different prompts for different AI models?: The content stays the same; the syntax changes. Claude follows XML-delimited structure most reliably, ChatGPT works well with markdown headings, Gemini prefers the task stated first, and image models need comma-separated descriptors rather than sentences. See the [model comparison guide](/guides/claude-vs-chatgpt-vs-gemini/) for the specifics.
What is the single fastest way to improve a prompt?: Add one example of a correct answer. It communicates format, length, register and depth simultaneously, all of which are ambiguous when described in prose. If you cannot produce an example, the next best step is stating explicitly how you will judge the result.
Does being polite to an AI improve the output?: Not measurably, and it costs tokens. Politeness is harmless and many people prefer it, but it is not a prompting technique. Specific constraints and concrete examples change output; "please" does not.