Your Method, Not Just the Text of the Request

The previous three parts were about what to write. This part is about how to carry the work forward. Take the difference seriously: you can execute all three of the earlier moves flawlessly and still get a bad result, simply because you poured the whole job into one giant request and waited for one complete answer.

Break the large task apart

Suppose you have a clinical paper and you want to understand it, to know whether its conclusion applies to your own patients, and to keep a summary for yourself. If you pour all of that into a single message, you get an answer that has done all three jobs half-way: a shallow summary, a generic critique, and a conclusion whose origin is unclear.

The same job, step by step: first only “explain the methods and the study population.” Then, once you have read that and understood what kind of study you are dealing with: “now give me the main findings.” Then: “given this study population, how generalizable is this result to the average patient in a general dentist's practice?”

Why does this work better? Because you are present at every step. The second step is built on something you approved at the first. If the model has misread the study population, you catch it right there, instead of discovering three layers later that the entire conclusion rests on a misunderstanding.

Put a stop between understanding and decision

This one is a particular and stronger form of that same breaking apart, and it may be the most practical move in the whole chapter.

The model's habit is to reach a conclusion quickly. It reads the question and almost immediately starts making recommendations, even when it has not yet read the situation properly. The problem is that once a recommendation has been formed, everything else it says circles around that recommendation; in effect it has been sloping that way since its first sentence.

The solution is simple: explicitly block the conclusion.

“Read this patient's history. For now, only assess the situation and report back: what findings are there, what is unclear or incomplete. Do not give any recommendation yet.”

Once the report arrives, you inspect it yourself. Has it missed something? Has it misread a finding? You correct it right there. And then:

“Now, based on this report, give me the options.”

Two things happened here. First, the model was forced to reveal its understanding before its decision, and understanding is something you can weigh. Second, the final recommendation was built on an understanding you had approved, not on the model's first guess.

This is the same supervisory role that has been with you since Chapter Three, except that this time, instead of checking after the answer, the structure of the work itself forces the model to stop midway and show its cards.

A prompt is a draft, not a shot fired

The common habit is this: we write a request, we get an unsuitable answer, and then we start patching that same conversation: “no, that is not what I meant,” “change this,” “make it shorter.” Sometimes that works. But when the first answer was fundamentally off course, it is usually better to rewrite the request itself instead of patching it.

One small habit that helps a lot: when you finally build a prompt that produced a good output, keep it. Save it somewhere. If a prompt for explaining root canal treatment to a patient worked well, do not start from scratch next time; take that one and change the name of the treatment and the patient's details. This way you gradually accumulate a handful of ready-made prompts for your recurring tasks, and that is exactly what turns prompt writing from an effort started fresh every time into a skill that compounds.

Hand the draft to the model itself

And now the move that makes this whole chapter lighter: you do not have to write the good prompt yourself. You can hand the writing of it to the model.

Instead of wrestling with a blank page, explain to the model what you want and ask it to write the prompt for it:

“I want a home-care instruction text for patients who have just had an implant placed — simple and easy to understand, something that can be printed and handed to them. Write a good prompt for this. Do not write the text itself, only the prompt.”

What you get back is usually more complete than what you would have written yourself, because the model makes explicit the things you had taken for granted: length, tone, audience, structure.

But the work does not end there, and this is the main point. Read that prompt and revise it. The model does not know what kind of people your patients are, does not know what works in your practice, does not know which point you always have to emphasize. Add those yourself. The model wrote the draft; the final judgment is yours.

And one last reminder

Everything you have read in this chapter does one thing: it makes the output more relevant, more precise and more usable. But none of it necessarily makes the model's answer more correct. An excellent prompt can hand you a fabricated reference or a wrong number in the best possible format and in the smoothest possible tone. Skill in prompt writing does not replace the supervisory role; it only makes the supervisor's job more pleasant.

So far you have learned what the model is, where it slips, how to hold a conversation with it, and how to write your request precisely. The question still open is the one a clinician asks before all others: where exactly does this tool belong in my clinical work, and where must it not belong? That is the next chapter.