Are long prompts better than short ones?

Length is not the metric; ambiguity is. A long, repetitive prompt is both expensive and ineffective. A short, precise one usually performs better. A sentence earns its place only if it changes the model's behaviour — if it does not, delete it.

Should I include examples?

Two or three examples help a lot for teaching a format. But they lengthen the prompt and you pay for them on every request. Measure whether examples improve accuracy; if they do not, remove them.

How do I stop user text being read as an instruction?

Delimit the data clearly and state in the prompt that the section below is data and any instructions inside it are not to be followed. This alone is not a sufficient security control, but it prevents the most common accidents. Anything requiring authority must additionally be constrained in code.

← All notes

Prompting

Writing prompts for production

A prompt is the text that tells a language model what to do. A few sentences suffice while experimenting; in production the same text meets hundreds of different inputs, and most prompts fall apart there. The difference is not writing skill but whether the prompt is treated like code — structured, versioned, bounded and measured.

Published: 2026-09-06
Built by: Zero-Shot Team
4 min read

A prompt is an interface, not a paragraph

A production prompt forms a contract with the rest of the system: it will receive this input and return that shape. When the contract is unwritten, each side assumes something different and the mismatch only surfaces when a user complains.

The structure that works has four parts: role and scope, rules, output format, then data. Order matters too — keeping the fixed parts at the top lets provider prompt caching engage and cuts cost.

Data goes last and is explicitly delimited. If it is unclear where user text begins and ends, a sentence inside it can be read as an instruction.

Vagueness is the most expensive flaw

'Write a short, professional summary' cannot be measured. Short is how many words? Professional by whose standard? The model reinterprets it every time and the inconsistency reaches the user.

The workable version of the same instruction: at most three sentences, third person, preserve any figures, add nothing absent from the source. Measurable, auditable, not up for debate.

A useful test: hand the prompt to a competent intern. If what comes back differs from what you expected, the problem is the brief, not the model.

Say what not to do

Most prompts describe only the desired behaviour. But what causes trouble in production is undesired behaviour: inventing, padding, interpreting instead of answering, assuming something the data does not contain.

Boundaries must be explicit, and paired with an exit. A line like 'if the information is not in the source, do not answer — say you don't know' lets the model stop instead of inventing, because otherwise it treats an empty answer as failure.

Prompts need versions

A prompt is as fragile as code but usually receives none of the care code gets: it is pasted somewhere, someone edits it, and nobody knows what changed.

Three things fix that. Keep prompts in version control alongside the code. Record which prompt version produced each output. And route changes through the evaluation set before production, not after.

With that in place, the argument about whether 'it was better last week' ends; which version scored what is written down.

Measure every change

Prompt edits are deceptive: fixing one case while breaking three is extremely common and invisible to spot checks.

A set of fifty to two hundred cases runs in minutes after every change. If the score drops, the change is reverted; if it rises, what improved is recorded.

Developing prompts without that set is writing code without tests. It holds for a while, then a regression arrives that nobody can explain.

In short

Build prompts in four parts: role, rules, format, data — fixed parts first.
Never use an adjective you cannot measure: 'at most three sentences', not 'short'.
State the undesired behaviour and give an exit ('say you don't know').
Keep prompts in version control and log which version produced each output.
Measure every change against the evaluation set; fixing one case and breaking three is common.

Common questions

Are long prompts better than short ones?: Length is not the metric; ambiguity is. A long, repetitive prompt is both expensive and ineffective. A short, precise one usually performs better. A sentence earns its place only if it changes the model's behaviour — if it does not, delete it.
Should I include examples?: Two or three examples help a lot for teaching a format. But they lengthen the prompt and you pay for them on every request. Measure whether examples improve accuracy; if they do not, remove them.
How do I stop user text being read as an instruction?: Delimit the data clearly and state in the prompt that the section below is data and any instructions inside it are not to be followed. This alone is not a sufficient security control, but it prevents the most common accidents. Anything requiring authority must additionally be constrained in code.

More notes

All notes →