Open the Problem Before You Build

Up to this point in the chapter, we’ve been talking about what to work with and how to keep errors out. Now we take one step back, to before the work even starts.

A familiar scene. You want to write your patients a text about what to expect after implant surgery. You type: “Write an educational text about post-surgical care for dental implants,” and the model starts right away. Thirty seconds later you have a complete, tidy piece of text.

Then you read it and realize you can’t actually use it. It’s longer than a patient would ever read, its tone is written for a colleague rather than a patient, it warns about things your own protocol doesn’t even raise, and the one point that mattered to you never showed up at all.

The question is whose fault that was. The model didn’t do anything wrong; it took the most likely reading of what you told it and built from there. The problem was that at the moment you gave the instruction, you yourself hadn’t yet made precise what you wanted. The length, the audience, how many points to include and which ones — all of that was still vague in your own mind, and the model was forced to guess at every one of them.

And here’s the worst part: now that the text is sitting in front of you, it’s actually harder to think about what you really wanted. Your mind settles on whatever it just saw and starts editing that, instead of asking from scratch what the problem even was. The same thing we talked about in Chapter 5 happens here too.

Two moves block this, and both do the same thing: they open up the problem before the model starts building anything.

Move One: Tell It to Ask You First

Instead of laying out the whole context yourself in advance, you tell the model to ask you whatever it needs before it starts.

In that same example above: “I want to write an educational text about post-implant surgical care. Before you write anything, ask me whatever you need to know.”

What comes back is usually a handful of questions: where will this text be published, will the patient read it before surgery or after, is it a simple surgery or one that includes a bone graft, do you want warning signs included or just instructions, how long should it be.

The point is that these aren’t hard questions. If you had sat down and thought about it yourself from the start, you’d have landed on exactly these. What this move does is take the burden of that thinking off your shoulders and hand it to the model — and, more importantly, it forces you to answer those questions before you see any output at all.

This is different from what we said in Chapter 3, and it’s worth not mixing the two up. There, we said the model doesn’t know you, so you have to frame yourself: who you are, what you want, for whom. Here the direction is reversed. Instead of you filling in the model’s gap, you’re asking it to fill its own gap from you.

It’s also different from the move in Chapter 4. There, the model worked first and reported back, and you inspected the report. Here, nothing has started yet at all.

One caution. The model also asks plenty of pointless questions — questions asked purely out of politeness, or ones whose answer wouldn’t change the output at all. That’s fine; you can leave them unanswered. The real risk is elsewhere: when the model asks a few genuinely on-target questions, it feels like it understood. That feeling isn’t reliable. Asking a question isn’t evidence of understanding — it’s just as much a probable-text output as answering one is. The model writes the questions that are usually asked in that kind of context.

Move Two: Ask for a Mockup First, Then the Whole Thing

The second move is for when the job is bigger than a short piece of text. Something like a multi-part series for your practice’s website, an educational presentation, or anything where, if it’s built all the way through and comes out wrong, you’re left with a lot of rework.

Instead of saying “write the whole thing,” you ask for a small sample first. A mockup. For example: give me the overall structure with headings, then write out just one section in full so I can see the tone and depth.

What you get out of this is two things. First, within a few minutes you learn how the model understood the problem, and if it got it wrong, you fix it right there, cheaply, instead of after ten finished pages. Second — and this matters more — seeing a small sample is often what tells you what you actually wanted. Very often a person doesn’t know they don’t want something until they see it.

The difference from that opening scene earlier in this part is that there too, you saw something and formed an opinion — but that something was the entire job, and it locked you into itself. A mockup is small enough that throwing it away costs nothing.

And let me flag one more thing here for the next chapter. If you work with agentic tools — the kind we talked about in Part 1, the ones that take several steps in a row — you’ll see the model build its own mockup, catch its own flaw, fix it, and move forward. Watching it is genuinely interesting. But why that behavior shouldn’t be generalized to scientific writing is a discussion for the next chapter.

Why These Two Sit Side by Side

Because they both do one thing: they stop the model from starting to build on its very first guess.

One does it with words, the other with a small sample. For short work, the first is usually enough. For bigger work, I use both, one after the other: I first tell the model to ask me anything it needs before starting, then I ask for a mockup, and only after approving the mockup do I finally give it permission for the whole job.

And notice that none of this is about whether the output is correct. The same thing we said at the end of Chapter 4 holds here too: these moves make the output more relevant, not necessarily more correct. Verification is a separate task, one we talked about in the last part.

And Next

Up to this point we’ve assumed the work fits inside a single conversation. For a lot of work, it does.

But when the job gets bigger, when it takes several sessions or its sources exceed what a single conversation can hold, you run into the same ceiling I mentioned in Part 1 and promised we’d fully get to by the end of the chapter. The next part is exactly that.