How to talk to a model: prompting without incantations

The internet is full of lists titled "10 magic prompts". They mostly contain phrases like "you are a world-renowned expert" and advice to offer the model a tip. None of it works any better than a plain, clear sentence.

What works is duller: saying exactly what you want.

Why "act as an expert" does nothing

There is nobody to fool. A model does not start knowing more because you told it that it knows more. A role can nudge the style of the answer — a more formal register, different vocabulary — but it adds no knowledge.

The difference you can actually see is between "write me some copy about our product" and "write two paragraphs for a tool retailer, the audience is working tradespeople, emphasise durability and servicing, no superlatives, under 400 characters".

The second sentence is not magic. It is just specific.

Four things that always work

1. Context. The model knows nothing about your company. If you do not say you sell B2B and the reader is a procurement officer, you get copy aimed at a consumer. Not because it erred — because it guessed.

2. Examples. The strongest tool you have. Showing two or three finished outputs you like beats a paragraph describing what you want. Models are far better at imitating a pattern than at following an abstract instruction.

3. Format. Say what you want back. JSON with these fields. Three bullets. One sentence. Without it you get an essay when you wanted a word.

4. Boundaries. What not to do. "If the text has no due date, return null — do not guess." This is your only defence against the model inventing a value it does not have.

What genuinely helps on harder tasks

"Work through it step by step" is not an incantation, but it has a real effect where something must be derived. A model that writes the intermediate steps lands the right answer more often than one firing straight at the result. The reason is mundane: each written step becomes part of the context for the next.

It has a price — you pay for those steps. On simple classification it is waste. On working out whether an invoice matches an order, it earns its keep.

Where people go wrong

• The prompt is a list of exceptions. When it runs three hundred lines and half of them are "IMPORTANT: don't forget…", that is not prompt engineering, it is a symptom. Split the task.
• Politeness instead of information. "Please be so kind as to try…" is not context. It adds nothing.
• Negation. "Don't be long-winded" works worse than "under 300 characters". Say what you want, not what you do not.
• One prompt, five jobs. Read, verify, classify, summarise and reply. Break it up.
• Testing on one example. A prompt that worked once is not a finished prompt. Try it on ten cases, including the ugly ones.

A prompt in code is a different discipline

People conflate these. A prompt in a chat is written for yourself, and when it returns nonsense you ask again. A prompt in an application runs a thousand times a day with nobody watching.

Which brings in things a chat never has to handle:

You are interpolating foreign text — from a user, an email, a document. That text can contain instructions. Separate data from instructions with a clear boundary and tell the model that the content between the markers is data, not a command. It is not bulletproof, but it is the necessary minimum.

Validate the output. If three JSON fields are expected, check three JSON fields arrived. Without that you are writing a hallucination to your database.

And version it. A prompt is part of the code — it belongs in git, not in a variable somebody changed once and no longer remembers why.

The summary

A good prompt reads like a good brief for a colleague who knows nothing about your company, is extremely fast, and takes everything literally. No incantations. Just precision.

If you are writing a prompt and it feels annoyingly specific, you are roughly in the right place.