12 min

Why prompts matter

The same language model, asked the same underlying question by two different people, will often produce output of very different quality. One person gets a vague, hedging paragraph that could have come from anywhere. The other gets a specific, usable draft. Nothing about the model changed between those two attempts. What changed was the prompt.

This lesson explains why that gap exists, what a prompt is actually doing when you send it, and how to think about prompting as a skill rather than a set of magic phrases.

What a prompt actually does

A language model has no memory of you, no goals of its own, and no access to the situation you are sitting in. It has one input — the text you provide — and one job: produce a continuation that is plausible given that text.

That framing is worth sitting with, because it explains almost everything that follows. The model is not retrieving an answer from a database and it is not deciding what you meant. It is generating the most plausible next stretch of text given everything in front of it. Your prompt is the entire evidence base it has for deciding what "plausible" looks like in your case.

So when you write "write something about our new product," the model has to guess the audience, the length, the tone, the format, the level of technical detail, and what the product even is. It will guess, because guessing is what it does. It will guess in the direction of the most common, most generic version of that request it has seen. Generic input produces generic output, and this is not a defect — it is the system behaving exactly as designed.

Note

A useful mental test before sending a prompt: could a competent new colleague, given only this text and no other context about your organization, produce what you want? If not, the model cannot either. It knows strictly less about your situation than that colleague does.

The four things most weak prompts are missing

Across a wide range of tasks, the same gaps show up again and again.

Context. Who is this for, what is the situation, what background does the reader already have? A summary written for a technical team and a summary written for a board are different documents, and only you know which one you need.

A specific task. "Help me with this email" is a topic. "Rewrite this email so it is under 120 words, keeps the deadline explicit, and reads as firm but not aggressive" is a task. The second one can be completed and evaluated; the first one cannot.

Constraints. Length, format, tone, what to include, what to leave out, what to do when information is missing. Constraints are not a limitation on the model — they are the difference between output you can use directly and output you have to rework.

A definition of good. Say what a strong answer looks like. If you need three options rather than one, say three. If you want the reasoning shown, ask for it. If you need it in a table, describe the columns.

Most of the improvement people attribute to advanced technique comes from simply supplying these four things. It is unglamorous, and it is where the majority of the value is.

Prompting is iteration, not incantation

There is a persistent belief that prompting is about discovering the right magic words — a phrase that unlocks better performance. That belief tends to produce a collection of superstitions rather than a skill.

What actually works looks more like editing. You write a first attempt, look carefully at what came back, identify the specific way it missed, and change the one thing most likely to fix that. Output too long? Add a length constraint. Wrong register? Describe the audience. Made something up? Tell it explicitly to mark uncertain claims rather than fill gaps.

This loop is the core practice of the whole discipline. It is also why prompting improves with deliberate attention in a way that idle use does not: the people who get good at it are the ones who notice precisely how an answer failed, rather than just regenerating and hoping.

One caution worth carrying through the rest of this course. Because model output varies between runs, a single good result is weak evidence that a prompt is good. If a prompt matters — if it will be reused, or used by other people, or wired into something that runs repeatedly — try it several times, and on inputs that differ from the one you happened to start with. We will treat this properly in the module on testing.

What this course covers

The next lessons build up the practical toolkit: the structural parts of a well-formed prompt, how to supply context and worked examples, how to control the shape of the output, how to test a prompt so you know it holds up, and how these patterns apply to the tasks that come up in real professional work.

None of it requires code, and none of it depends on a particular product. The techniques transfer across tools because they follow from what these systems are — text continuation engines that know only what you tell them.

Knowledge check

Why does a vague prompt tend to produce generic output?