You Decide the Shape of the Output

So far you've learned what to give the model. This part is about the other side of the same coin: what to ask it to build. The two aren't the same thing. You can tell the model exactly who you are and what you want, and still get back an answer you have to rewrite from scratch — simply because its shape wasn't what you actually needed.

And this small point is the root of most disappointing answers. Usually the problem isn't that the model didn't know something; it's that the request was ambiguous, and the model had to guess what shape you wanted. Ambiguity, not the model's lack of knowledge, is the main cause of a useless output.

Take a single subject — peri-implantitis, say. Now consider three different tasks you might have around that same subject:
“Put the differential signs of peri-implantitis versus peri-implant mucositis into a table: first column the clinical finding, second column the radiographic finding.”
“Write me a six-step checklist I can follow chairside when examining a suspect implant.”
“Write a short message for a patient explaining why they should come in sooner to get the inflammation around their implant checked — in plain language, without scaring them.”

All three are about the same subject, and the model knows just as much in each case. But you get three fundamentally different outputs: a diagnostic table, a clinical tool, and a patient-communication text. The difference wasn't in the model's knowledge; it was that you determined the shape.

If you don't determine the shape, the model picks the most default shape on its own, and its default is usually a generic explanatory text — exactly the thing least useful for any specific task. So determining the shape isn't just something that improves the answer; it's what decides whether the answer is usable at all.

There are two decisions behind “shape.” First, what type of thing to build: an explanatory text, a comparison table, a checklist, a patient message, a multi-paragraph summary of an article. Second, in what format: even once you've specified the type, the format is still open. One continuous paragraph, or several short, separate sentences? A bulleted list, or flowing prose? An explanation you'll read aloud chairside and one you'll write into the chart can carry the same content but need two different formats.

This is the simplest and, at the same time, the highest-yield move in this chapter, because it takes a few seconds and demands no new expertise from you — you just need to know what you want the output for.

When Description Falls Short, Show an Example

Sometimes the shape you have in mind is so specific that describing it in words is harder than just showing it. This is where the strongest prompt-engineering technique comes in, and it's so simple that it's often overlooked: instead of describing the output's shape, give the model a sample of it yourself.

Say you want to write status summaries for several patients in one fixed shape, so the chart stays consistent. You could explain it in words: “diagnosis first, then key findings, then the treatment plan, one line each.” Or you could just show a filled-in example:
I want you to write the patient summary in this shape:
Diagnosis: Irreversible pulpitis, tooth #36
Findings: Spontaneous pain, prolonged response to cold, no swelling
Plan: Root canal treatment, single visit
Now fill in the same shape for this patient: [patient description]

From that single example, the model picks up the whole pattern: the order, the tone, the length of each line, even the kind of detail that should go in. Something that would have taken several sentences to describe — and would still have left room for ambiguity — becomes completely clear with one example.

This technique especially shines wherever the output needs a repeatable format. Build one good example once, and you can reuse that same pattern for many different inputs and get a consistent output every time. One example is usually enough; for a more complex task, two or three examples lock the pattern down more firmly.

One subtle point: the quality of the example carries straight through to the quality of the output. If the example you give is sloppy or vague, the model will copy that same sloppiness. To the model, an example functions as an instruction, not a suggestion — so give it an example that's exactly what you want, not something close to it.

There's also a lighter version of the same idea that sometimes comes in handy: instead of a full example, just write the opening of the answer yourself and let the model continue it. If you end your request with “Start the answer like this: ‘Doctor, for your tooth…’,” the model will pick up right there, in the same tone. Because at its core the model is a continuation engine, taking control of the opening keeps it from drifting away from the format you want.

So far you've done two things: you determined the shape of the output, and, wherever description fell short, you showed an example instead. Both were about what form the output should take. In the next part we turn to something different: not the shape of the output, but the phrasing of the request itself, and two subtle habits that make the model's answer more precise.