Let's Make Prompts Work: It Predicts, You Narrow

AI answers are inconsistent in a specific way. Sometimes you get exactly what you needed. Sometimes something so vague it's useless. Sometimes something confident and completely wrong.

The model didn't change between those three. Your prompt did.

That's the entire premise of prompt engineering, a term that has become as popular as the tools themselves and sounds like something you need a certificate for. It isn't. It's this:

Designing clear instructions to get better responses.

Or, with nothing left to remove:

Ask better questions to get better answers.

The rest of this is why that works.

You already do the thing the model does#

Finish this:

Once upon a ________

You didn't have to think. Nobody taught you a rule for it — you read enough English that "time" became the overwhelmingly likely next word.

Now a harder one:

I am going to the ________

Store? Gym? Airport? Doctor? Bank? You can't pick, and not because you lack information about language. Too many continuations are roughly equally likely.

Now add six words:

My flight leaves in three hours.
I am going to the ________

Airport. Immediately.

Context didn't make you smarter. It removed the wrong options.

That is, roughly, the mechanism#

A model like GPT or Claude was trained on an enormous amount of text — news, books, papers, documentation, code, forum arguments. Not stored and looked up, but compressed into patterns about which words tend to follow which.

Then it does what you just did: predicts the next word, then the next, then the next.[^1]

So when a tool tells you it is "thinking", that's a description written for humans. What's happening underneath is a computation over likely continuations, not deliberation. This isn't a criticism — predicting continuations turns out to be startlingly powerful. But it explains the behaviour you actually see:

The more context you give, the fewer wrong continuations are likely.

That's the lever. Everything below is a way of pulling it.

[^1]: Strictly, the next token — roughly a word or a piece of one. The distinction matters for tokenisation and pricing; it doesn't matter for this.

Two prompts about the same thing#

Explain Compose

Compose what? To whom? At what depth? Three guesses the model has to make, and a good tool will now stop and ask you rather than guess — which is itself a signal that your prompt was underspecified.

Against:

You are an Android engineer explaining to a backend developer who has
never written UI code.

Explain what Jetpack Compose is and how it differs from XML layouts.
Use one concrete example.

Under 200 words. Prose, no bullet lists.

Same model. Same subject. The second one cannot be answered badly without being obviously wrong — and that's the real test of a prompt. If a bad answer would still look plausible, you haven't constrained it enough.

The anatomy of a prompt#

Four parts. You don't need all four every time — but knowing which one you left out is the skill.

All four, in one prompt:

You are a senior Android engineer reviewing a pull request.     ← persona

Review the composable below and list what you would change      ← instruction
before merge.

@Composable fun ChipIconItem(icon: ImageVector, ...) { ... }    ← context

Answer as a numbered list. Maximum five items. One line each.   ← format

The useful part is that each omission fails in its own recognisable way:

• No persona → a generic answer pitched at nobody in particular.
• No instruction → it summarises your context instead of acting on it. This is the most common failure by a wide margin, and it's why pasting a document and hitting enter so rarely gives you anything.
• No context → confident, plausible, and about someone else's codebase.
• No format → six paragraphs when you wanted five bullet points.

Once you can name the failure, you can fix it in one edit instead of rewriting from scratch.

Three intimidating names for simple things#

People love naming things to make them sound harder than they are. All three of these are one sentence each.

Zero-shot is a prompt with zero examples. You have been doing this the whole time.

Few-shot is a prompt with a few examples. Reach for it when the shape of the answer matters more than its content:

Classify the commit message.

"fix: crash on empty catalogue"   -> fix
"add dark theme to profile"       -> feature
"bump kotlin to 2.2"              -> chore

"remove unused import"            -> ?

You never defined the categories. The examples did it, and more precisely than a paragraph of explanation would have.

Chain-of-thought is asking it to work through the steps before answering. Use it for problems with more than one move:

Before answering, work through this step by step:
  1. what the current code actually does
  2. where that differs from the intent
  3. the smallest change that closes the gap

Then give me the change.

One honest caveat, because most tutorials on this were written in 2023: newer reasoning models already do this internally, so the gain from bolting "let's think step by step" onto the end is much smaller than it was. Steps you define are still worth writing — not because they make the model smarter, but because they make its answer checkable.

Five things that work on every prompt#

1. Be clear on the objective. Action verbs. Name the audience. Name the output format.
2. Offer background and context. Facts, data, the actual document. Paste it in — an approximate summary of the thing is worse than the thing.
3. Be specific. Precise language, tasks broken apart, quantities named. "Five" beats "a few", every time.
4. Iterate. Change one thing and compare. The first prompt is a draft, not an attempt.
5. Ask it to check itself. "What assumptions did you make? What's missing from this?" is frequently the most useful reply of the session, and almost nobody asks for it.

The one idea worth keeping#

If you remember nothing else:

It predicts continuations. Context narrows them.

Every technique above — persona, examples, step lists, format constraints — is the same move in different clothes. You are cutting away the continuations you don't want.

This is part one of Let's Make Prompts Work, a free course in two parts:

1. Fundamentals — this one.
2. Judging it, then using it — evaluating and refining what comes back, and putting prompts to work on real tasks.

Part two, plus the complete deck as a PDF, is at makethiswork.dev/prompt-engineering.

Both are free and that's the whole course. It's the first one in a longer prompt engineering path, and the courses after it will be paid — saying so here rather than in an email later.