When to Ask AI a Question Before Asking for an Answer

A model can answer a vague request by silently choosing an assumption. That is fine for a low-stakes brainstorm. It is risky when the assumption changes the work. Imagine this request: Design a save system for my game. Before writing an architecture, I need to know whether players have accounts and whether progress must move between devices. Those answers change the design. Asking about the button color does not. Before generating code, Prompting for a Small Feature: Requirements Before Code shows how to turn answers to those clarifying questions into testable requirements.

I ask the model to question me only when the missing fact affects one of three things: Behavior: Would the feature work differently? Risk: Would the wrong assumption expose data, lose progress, or break a promise? Cost: Would one answer require a much larger implementation? Here is a prompt that limits the back-and-forth: I want players to save progress. Ask only the two or three questions whose answers would change storage, account, or sync choices. For each question, explain which design decision it affects. If you can propose a reversible first version without asking, do that and label your assumptions. This is better than “ask me everything you need,” which can turn a small project into a questionnaire. It also avoids pretending a missing fact was supplied.

If the task is “give me five theme ideas for a puzzle game,” the model can make reasonable assumptions and generate ideas. I can refine later. A question is worth the delay only if its answer materially changes the result.

A good clarifying question names the tradeoff. “Do players need cross-device saves?” is useful because yes points toward an authenticated server-backed solution; no may permit a smaller local first version. “Tell me more about your app” is too open. Try it: Give AI one vague task and ask for no more than three consequential questions. Reject any question that does not change behavior, risk, or cost. Answer the remaining ones, then see whether the resulting plan is more specific. Keep learning: Break a Large Request Into Smaller Prompts, Prompting for a Small Feature: Requirements Before Code, and Ask for Alternatives, Then Choose With a Rubric. Further reading: prompting guide.