Prompt Engineering: Asking Better Questions
Learn what makes a prompt clear, and why every guess you remove from the model improves the answer.
Imagine handing a task to a brilliant new colleague on their first morning. They’re quick, well read and eager, but they know nothing about your company, your customers or what you’re trying to achieve. If you say “write something about dogs”, you’ll get something about dogs. Probably not what you wanted.
That’s the right mental model for a prompt. Prompt engineering sounds like a dark art, but most of it is simply writing a good brief. Every detail you leave out is a gap the model fills with the most generic guess, because, as Track 2 showed, the most plausible continuation of a vague request is a vague answer.
The ingredients of a good brief:
- Purpose: what it’s for and what success looks like.
- Audience: who will read it and what they already know.
- Format and length: “about 80 words, two paragraphs” beats “short”.
- The facts it can’t know: names, numbers, dates, your situation.
- Constraints: what to avoid, and what to do in tricky cases.
A few extra habits help. Put long reference material first and the question last. Use clear labels or headings to separate instructions from data. For problems that need reasoning, ask the model to think it through before answering (Track 2’s chain of thought). And iterate: read the output, notice what it got wrong, and add the missing piece of the brief.
A longer prompt isn’t always better, but a prompt that leaves nothing important to guess almost always is.
Key takeaways
- A prompt is a brief for a capable newcomer who knows nothing about your situation.
- Vague prompts get generic answers, because the model fills gaps with the most plausible guess.
- Include purpose, audience, format and length, the facts it can’t know, and constraints.
- Separate instructions from data, ask for reasoning on hard problems, and iterate on the failures.
Check your understanding
Go deeper (more technical)
Model providers publish prompting guides with recurring advice: be clear and direct, give context and motivation, use examples (next lesson), structure long inputs with tags or headings, and give the model room to reason before answering.
For apps, prompts are part of the code: they are versioned, reviewed and tested against an evaluation set, like the one from the benchmarks lesson, so a “small wording tweak” that breaks something is caught before users see it. Some teams also ask a model to critique or improve a draft prompt.