Why We Made Our Agent Ask Questions Before It Builds

The obvious way to build an AI product builder is to make it obedient. You describe what you want, it builds exactly that, fast, no friction. That is the demo everyone wants to give. It is also the reason so many AI-built apps arrive looking finished and behaving like a stranger wrote them. We built the opposite on purpose. Before our Planning Agent writes a requirement, it stops and asks you the questions you didn't think to answer.

That decision gets pushback in almost every demo. Why add a step? Why slow down the one part of AI that finally feels effortless? The honest answer is that the step is not friction. It is the difference between an agent that builds what you said and an agent that builds what you meant, and those two things diverge the moment your idea leaves the sentence you described it in.

#The hypothesis: the agent worth trusting is the one that won't build blind

Here is the claim, stated so you can argue with it. The value of an AI coding agent is not how fast it goes from prompt to preview. It is how few of your unstated decisions it has to guess. A capable agent handed a vague prompt does not fail loudly. It succeeds at building something, quietly inventing every detail you left out, and hands you a working app whose behavior you now have to reverse-engineer to trust. The interrogation up front is not a tax on speed. It is what makes the speed worth having.

You can watch this happen with any coding agent today. Tell one to "ask clarifying questions" before it builds and it turns out most of them can, well. A commenter on Hacker News put it bluntly:

"I think the asking clarifying questions thing is solved already. Tell a coding agent to 'ask clarifying questions' and watch what it does!"

The reframe hiding in that line is the whole point. The capability was never the hard part. The models are already good enough to ask sharp questions. What almost nobody does is make asking the default instead of a trick you have to remember to invoke. Left to its defaults, an agent optimizes for producing output, because that is what looks like progress. Asking first has to be designed in, not prompted in, or it does not happen when it matters most.

#What the questions actually catch

A builder describing an idea leaves out the things that feel too obvious to say. That is not carelessness. It is how human communication works. When you tell a contractor you want a kitchen island, you do not specify that it should be attached to the floor. You assume it. The agent does not share your assumptions, and unlike the contractor, it will never look at you funny for leaving them out. It will just pick.

Consider what "build me a contact form" leaves undecided. Who can submit it, anyone or only logged-in users? What happens after submit, a thank-you page, an email, a database row, all three? What counts as a valid email, and what does the form do with an invalid one? Where do the submissions go, and who is allowed to read them? None of those are in the prompt. Every one of them is a decision the agent will make silently if you let it, and each wrong guess is a bug you find in production instead of a question you answered in ten seconds.

This is why we made asking the first move. When you describe a feature to BrainGrid, the Planning Agent does not race to code. It interrogates the idea the way a good senior engineer would in a hallway conversation: what did you not decide, what did you assume, what breaks if I guess wrong. Then it writes those answers down as a requirement with acceptance criteria, a plan you can read and correct before a single line is built. The questions are cheap. The re-derivation you avoid is not. We wrote up the specific decisions worth catching in the eight questions to answer before your agent writes a line of code; this post is about why the agent should be the one asking them.

#The believable version, side by side

The difference is easiest to see in the gap between what you say and what a build actually needs.

What you typed: "Add user login."

What the agent has to decide silently: Email and password, or social sign-in, or both? Password reset flow, yes or no? What happens to a user who is half-registered? Do sessions expire? Is there a "remember me"? What does a wrong password say, and after how many tries does it lock? Where does an unauthenticated user land when they hit a protected page?

Hand that four-word prompt to an obedient agent and you get login. It will work in the demo. It will also have made nine decisions you never saw, and you will discover them one at a time, usually when a real user hits the edge you didn't know existed. Hand the same idea to an agent that asks first and you spend three minutes answering, then get a plan that names every one of those decisions before it becomes code. Same feature. One version you can trust because you can see what it decided. The other you can only hope about.

#The honest trade-off

Asking questions is not free, and pretending otherwise would be its own kind of dishonesty. Sometimes you genuinely do just want the throwaway version now, the rough prototype to see if the idea has legs, and a barrage of questions is exactly the wrong response to "just show me something." The interrogation earns its keep when the app matters, when someone other than you will use it, when you will still be changing it in three months. For a weekend experiment you will delete on Sunday, the questions are overhead. We know that, and the answer is not to remove them but to keep them proportional: ask what changes the build, skip what doesn't.

There is a second limit worth naming. Asking good questions does not rescue a builder who cannot answer them. The agent can surface the decision "what happens to a half-registered user," but it cannot make that call for you well, because it does not know your product or your users. This is the part that stays human. Clarity is still your job. What the questions do is make sure you spend it on the decisions that matter, up front, instead of paying it back with interest later.

#What this changes if you're building right now

If you are shipping features with Claude Code, Cursor, or any capable agent, the practical move is small and it pays immediately. Stop handing your agent a confident one-paragraph prompt and letting it run. Before it builds, make it enumerate what it is about to assume. In a raw coding tool you do this by ending your prompt with "ask me clarifying questions before you write any code," and then actually reading the list instead of skimming it. In BrainGrid the step is the product: the Planning Agent asks, you answer, the answers become acceptance criteria, and the Builder Agent builds against a target you can verify instead of a hope you have to inspect.

The measurable effect shows up in regeneration. The vague-prompt loop is: describe, build, discover a wrong guess, re-describe, rebuild, repeat, four or five times per feature before it settles. Answering the questions once collapses that. You are trading a five-minute conversation for the three or four rebuilds you would otherwise pay in tokens, credits, and afternoons. We put real numbers on that waste in the real cost of a vague prompt. Every decision you make explicit before the build is one the agent cannot get wrong during it. This is the front end of spec-driven development: the questions produce the spec, and the spec is what the build is checked against.

Strip out the trending hook and the argument still stands: an agent that builds from your assumptions will build your assumptions, including the ones you were wrong about. The questions are how you find the wrong ones while they are still cheap to change. Speed was never the scarce thing. Knowing what "done" means before the agent decides for you always was.

#FAQ

#Why would an AI agent ask clarifying questions instead of just building?

Because the prompt you write is almost never a complete specification. A short description leaves out the decisions that feel too obvious to state, and the agent does not share your assumptions, so it fills those gaps by guessing. Asking first surfaces the guesses as questions you can answer in seconds, instead of bugs you find in production. The capability is easy for modern models; making it the default, rather than something you have to remember to request, is the design choice that matters.

#How do I get my coding agent to ask questions before writing code?

End your prompt with an explicit instruction like "ask me clarifying questions before you write any code," then read the list carefully and answer it before you let the agent proceed. Most capable agents handle this well when told to. The failure mode is not the agent's ability, it is skipping the step because generating output feels like faster progress. Tools built around planning, like BrainGrid, make the questions a required part of the flow so you do not have to remember to invoke them.

#Doesn't asking questions slow down building with AI?

It adds a few minutes up front and removes the rebuild cycles that vague prompts cause. The typical vague-prompt loop runs four or five regenerations per feature as you discover wrong guesses one at a time. Answering the questions once collapses that into a single well-aimed build. For a throwaway prototype the questions are overhead; for anything you will ship or maintain, they are faster overall.

#What kinds of decisions do clarifying questions catch?

The ones you left implicit: who is allowed to do the thing, what happens on success and on error, what counts as valid input, where data goes and who can read it, and what the edge cases do. A prompt like "add user login" hides a dozen of these. The agent will decide every one silently if you do not answer them first, and each wrong default is a defect you inherit rather than a choice you made.

#Is BrainGrid's Planning Agent the same as prompting an agent to ask questions?

The behavior is related but the design is different. Prompting a coding agent to ask questions works, but it is opt-in and the answers live in a chat that scrolls away. BrainGrid's Planning Agent asks by default, then writes the answers down as a requirement with acceptance criteria, a durable plan the Builder Agent builds against and verifies. The questions become a record you can review and reuse, not a conversation you have to remember.

BrainGrid is the plan-first app-building platform that asks the questions you didn't think of, turns your answers into a requirement with acceptance criteria, then builds against a target you can verify. Try it at braingrid.ai.