Three Questions Before You Prompt AI
By Lovro Lucic ·
Three questions. Answer them and most of the prompt is structured. The third tends to do the most work, and on anything you have not built before it is the one with no answer to look up, which is where this gets interesting.
What do I need? Not "help me with X." What's the deliverable? A decision, a draft, an analysis, a list. One sentence. If that sentence won't come yet, the prompt isn't ready: the thinking comes before the typing.
What can't the model know? The model knows what is public and general. It doesn't know YOUR situation. Your audience, your constraints, your history, your deadline. Think about what a sharp person would ask before starting work on your task. Those questions, answered, are your context.
How will I know it worked? The one that changes the output the most, and the one a prompt most often leaves out. Not "make it good." What does DONE look like for this specific task? "Every recommendation references something specific from our Q4 data." "I can hand this to the exec team without editing." In practice, that one sentence moves the output more than anything else in the prompt.
A fourth question sharpens it further: what would failure look like? "Failure is if this reads like a generic project update that could be about any project." That gives the model something concrete to avoid. Avoiding is more specific than aiming.
The difference in practice:
Before: "Help me write a project update for my team."
After: "Write a project update for my engineering team (12 people) about the authentication migration. We're 3 weeks in, 2 weeks behind schedule. The delay is from an unexpected dependency on the billing service API. Team morale is fine but stakeholders are nervous. Done means the team knows exactly what's behind, why, and what we're doing about it. No sugarcoating."
Same task. 30 seconds longer to write. The output is different because the model has constraints instead of infinite interpretation space.
Underneath all three questions is one mechanism: together they make the model's generic default path more expensive than doing your specific task (Why AI Defaults to Generic). This is that mechanism turned into questions you can ask before typing.
The project update was the easy case: you have written those before, so you already know what done looks like. The hard case is the task you have never done, where the most important question, what does done look like, is also the one you cannot answer yet, because you do not understand the task well enough to say. That is not the framework failing. It is the framework pointing at where the real work is.
Say you have to write the design doc for a system nobody on your team has built before. Ask what done looks like and the honest answer is that you do not know yet, because you do not know the tradeoffs until you are in them. There is no prior version to copy. So you write a bad one, rough and wrong, and the moment it exists you have something to push against: this assumes the current data model, this hand-waves the failure mode, this is solving for scale you do not have. Each objection is a criterion you could not have listed on a blank page. The draft did not produce the design. It produced the definition of done, which was the part you were missing.
Two moves get you unstuck. The cheap one is the failure question: you can usually name what would be wrong before you can state what would be right, which names the target from the other side. The stronger one is what that draft did: make your own rough attempt first, before prompting. It does not have to be good. Producing it surfaces the criteria you could not state cold and gives you a model of the answer to judge the model's version against. Reacting to the model's draft instead skips the step, and you pay for it later: you approve something fluent, ship it, and find it solved the convenient version of the problem, not the real one (The Construction Trace).
So the recipe is not answer three questions, then type. When you can answer them, answer them. When you cannot, the work that comes before the prompt is producing the definition of done yourself.
What survived testing
- In the 2x2 I ran, specificity was the strongest lever for verifiable form, not perceived quality (Hedges g=1.34 on raw marker count, 95% CI [0.74, 2.32]; 1.62 at density).Copy link
- Quality demands did little on their own in that test (near zero, scoring just below the bare prompt) but combined synergistically with specificity: the both-present condition scored higher than the two separate effects predicted.Copy link
- Adding constraints beat adding context in the case I tested: on an already-thorough prompt, more information barely moved the output, while a few constraint sentences changed it (Context Serves Search).Copy link
What didn't survive
- "Three questions are always sufficient" untested. Some tasks need domain-specific framing.Copy link
- "Structure outperforms descriptive instruction" as a clean rule: how much structure helps is model-specific (large on one generator, uninformative on another where the output already sat at the scoring ceiling, reversed on a third), so it is a heuristic, not a tested result.Copy link
Honest limits
- The three-question framework is craft knowledge, not experimentally tested as a unit. What is measured here is the specificity effect and the constraints-over-context comparison; the framing around them is operator craft.Copy link
Explore other threads
The Fabrication Problem
5 findingsMost AI numbers are fabricated. Source material fixes it. Self-checking fails. Trust signals are backwards.
The Evaluation Problem
2 findingsJudgment goes quiet. You can't see the gaps. Satisfaction is the trap. Stronger evaluators discriminate less.
The "It Depends" Problem
5 findingsSame instruction, opposite results. Specificity is the lever. Context redirects, not informs. The measurement itself was wrong.
New findings when they land.
No spam. Just what held up.