Prompting Fundamentals

"Write me a blog post about AI" and "You are a technical writer for a developer audience; write a 600-word post explaining next-token prediction with one concrete example, no marketing language, ending in a one-sentence takeaway" are the same request. One of them is a guess wearing the shape of a question. The other is a decision. That difference — asking versus specifying — is the entire skill this lesson teaches.

Asking gets you a guess. Specifying gets you a decision.

When you ask vaguely, the model has to guess at dozens of decisions on your behalf: length, tone, audience, structure, depth, what to include and what to leave out. It will guess something, because it always produces an answer — it never comes back and says "too many unknowns, please clarify" unless you've explicitly told it to. Specifying means making those decisions yourself, up front, so the model executes your call instead of substituting its own.

Notice that the vague prompt in that diagram isn't wrong, exactly — every one of those possible outputs is a reasonable response to "write something about AI." That's the problem. Reasonable-but-unpredictable is what you get any time you leave a decision unmade. The specified prompt didn't ask for anything more — it just made the decisions instead of leaving them for the model to guess.

The five layers of a specified prompt

Every fully-specified prompt is built from the same five layers, stacked in whatever combination the task actually needs.

Role frames who the model should act as — it implicitly sets vocabulary, assumed expertise, and evaluation criteria. "You are a senior security-focused code reviewer" pulls different behavior than no role at all, because it tells the model which lens to look through.

Instructions are the actual task, stated as a concrete action — not a topic. "Review this diff for injection risks" gets you something usable. "Diffs" or "security stuff" doesn't.

Examples show 1-2 sample input/output pairs when the shape of the answer matters. Models are excellent at pattern-matching a shown example — often more reliable than following a described rule about the same pattern.

Constraints are explicit boundaries: length limits, things to avoid, scope limits like "don't touch files outside src/api." Constraints are what stop a model from being unhelpfully thorough in a direction you didn't ask for.

Output format states the exact shape expected — a bullet list, a specific JSON schema, a fixed heading structure — stated outright, never left implied.

Not every prompt needs all five layers stacked to the ceiling. A quick, throwaway question doesn't need constraints and a rigid output format. But these five names are the vocabulary for diagnosing what's missing the moment a prompt keeps coming back the wrong shape.

Three before/after makeovers

Before: "Write me a blog post about AI." After: "You are a technical blog writer for a developer audience. Write a 600-word post explaining how next-token prediction works, using one concrete example. Avoid marketing language. End with a one-sentence takeaway."

Before: "Fix this bug" (with code pasted in). After: "You are a senior engineer. The function below throws [exact error] when [exact input]. Fix only the specific cause of that error — don't refactor unrelated code. Show the diff, then explain the root cause in two sentences."

Before: "Summarize this" (with a document pasted in). After: "Summarize the attached document in exactly 5 bullet points, one per major section, each under 20 words, written for someone who has 30 seconds and needs to decide whether to read the full thing."

Look at what actually changed between each before and after: the underlying ask didn't change at all. What changed is which of the five layers got made explicit instead of left for the model to guess.

Iteration is part of the method, not a failure

Treat your first prompt as a first draft. If the output isn't right, edit that same prompt to add the layer that's missing — usually a constraint or an example — rather than throwing it out and starting an unrelated one. Feed corrections back explicitly ("that's too long — cut to 3 bullets") instead of re-describing the whole task from zero. The model already has the context; what it needs is the delta, not a fresh explanation of something it already has in front of it.

Build It

The BuildChallenge below has you encode this as a function — a promptSpec() helper that takes a vague request and assembles a fully-specified prompt from its layers, with real validation instead of vague vibes about "being more specific."

This exercise is written in TypeScript — if you don't code, read the solution as pseudocode for the same five-layer logic, or skip ahead; the lesson stands on its own without it.

Bottom line

Asking and specifying produce the same effort on your end and wildly different odds of getting what you actually wanted. Five layers — role, instructions, examples, constraints, output format — are the full vocabulary for what a vague prompt is missing. You don't need all five every time, but when an answer keeps coming back the wrong length, the wrong tone, or the wrong shape, one of those five is almost always the one you skipped. Next: once your prompts are specified, the next skill is knowing when to trust what comes back — and when to check it.