A prompt is a specification
By the end: You can write a prompt that gets the right answer reliably, instead of one that works sometimes.
- Being specific about the task
- Saying what the output should look like
- Telling the model what to do when it does not know
- Giving it a role, and when that helps
New to prompting? A prompt is the text you send a model to tell it what you want: the task, examples of a good answer, the format to reply in, and what to do when it is unsure. It is closer to writing a brief for a capable new colleague than to typing a search query. The model will do what you asked, including the parts you never thought to specify. Why it matters
This is where you stop typing requests and start writing briefs. The section covers being precise about the task, pinning down what the reply should look like, and saying explicitly what to do when the answer is not available, which is the instruction people most often leave out. It is unglamorous work and it recovers more bad answers than moving to a larger model does.
Most failures are underspecified tasks#
When a model gets something wrong, the usual cause is that the request allowed the wrong answer. Write the prompt as though briefing a capable new colleague who cannot ask you follow-up questions.
Weak: "Summarise this."
Better: "Summarise this support ticket in two sentences for an
engineer who will pick it up. Say what broke and what the
customer has already tried. Do not include pleasantries."Four things make the difference: what the task is, who the output is for, how long it should be, and what to leave out.
Say what the output should look like#
If something downstream will read the output, describe its shape exactly. Left to itself the model will vary the format between calls, and that variation is what breaks your parser at three in the morning.
Return one line per finding, in this format:
SEVERITY | FILE:LINE | one sentence
Use only HIGH, MEDIUM or LOW for severity.
Return the single word NONE if there are no findings.That last line matters more than it looks. Without it, a model with nothing to report will write a paragraph explaining that it found nothing, and your parser will choke on prose it never expected.
Give it an escape route#
A model asked for a field that is not in the source will usually invent something plausible rather than refuse. It is not lying; it is doing what you asked, which was to produce that field. Give it a permitted way out and it will take it.
If a value is not present in the text, return null for it.
Do not infer, estimate or guess. An absent field is an
acceptable answer; an invented one is not.This is the single highest-value line in most prompts
Hallucinated fields in extraction tasks drop sharply when the model is explicitly allowed to say it does not know. Most prompts never grant that permission.
Roles#
Opening the system prompt with a role, such as telling the model it is a senior accountant, helps when it genuinely narrows vocabulary and conventions. It does not make the model more capable, and stacking superlatives adds nothing.
Useful: "You are reviewing German invoices for VAT compliance."
Useless: "You are a world-class, elite, 10x expert assistant."Where people go wrong
Iterating on a prompt by eye. You will convince yourself it improved because you remember the bad outputs and not the good ones. Fix a set of test inputs and compare against them.
If this comes up in an interview
A prompt works most of the time but occasionally returns the wrong format. What do you do?
First check whether the task and output format are fully specified, including what to do in the empty or unknown case. Then lower the temperature, since format drift is sampling variation. Then use schema-constrained output, which makes the shape a guarantee rather than a request.
Then they push further
You added a schema and it still fails on 1% of requests. Now what?
Look at the failing inputs. Check for truncation from max_tokens, for unusual inputs such as very long or empty ones, and for inputs that contain their own formatting. Then decide between fixing the prompt, validating and retrying once, or failing cleanly.
Is retrying on failure a good idea?
Once, with the validation error passed back, is usually cheap and fine. Unlimited retries hide a real problem and multiply cost. Count retries so you notice when they climb.
What gets marked up. Marked up for reaching for structured output and validation rather than more wording, and for reading the failing inputs before changing anything.
How do you stop a model inventing data during extraction?
Explicitly permit null for missing fields and state that guessing is not acceptable. Models fill gaps because the prompt demanded a value; giving them a legitimate alternative removes the pressure.
Does telling a model it is an expert improve results?
Only when the role genuinely narrows the domain, vocabulary or conventions. Piling on superlatives does nothing measurable. The gain comes from specificity, not flattery.
Build this: Take a weak prompt, write down ten inputs with expected outputs, then improve the prompt and measure how many pass before and after. Notice how often your first instinct made it worse.
Watch it explained
This is one section of Prompting, 10 hours across 3 sections. Read it in full to get the whole topic in order.
Stop 5 of 50 on the AI Engineer route
0 of 50 topics done · 0h behind you, 603h to go
What you have marked done is stored in this browser only. It does not reach a server, and clearing site data will clear it.