The 8 Questions to Answer Before Your AI Agent Writes a Line of Code

The best way to get bad software out of a good AI agent is to give it a good prompt. Not a lazy one. A confident, detailed, one-paragraph prompt that sounds like you know exactly what you want, handed to a capable agent that will build precisely what you said and quietly invent everything you didn't. The agent isn't the problem. The eight things you never decided are.

This is the gap underneath almost every "I thought AI would build my app for me, here's what actually happened" thread. The builder had an idea, described it in a sentence, watched a working preview appear in ten minutes, and then spent the next three weeks discovering all the decisions the agent made on their behalf. So here is the checklist that goes in front of the build: the eight questions you answer before your agent writes a line of code, and why skipping any one of them is how you end up scared to ship.

#The hypothesis: your agent is only as good as the questions you answered first

Here is the claim, stated so you can push back on it. The quality of AI-built software is set before the build starts, not during it. The agent's job is to execute a definition of done. If that definition lives only in your head, the agent fills the gaps with guesses, and it guesses differently every time you regenerate. The reason two people using the same tool get wildly different results is not skill with the tool. It is how much they decided before they pressed go.

A builder in r/ClaudeAI put the working version of this better than any tutorial:

"For me the line is whether the human is still making the product/architecture calls. Vibe coding is 'make something and hope'. Agentic engineering is more like: write a spec, constrain the files, run tests, review the diff, then let the agent do the boring execution."

The eight questions below are how you make the product and architecture calls before the agent does. Answer them and you get to hand off the boring execution with confidence. Skip them and the agent makes those calls for you, silently, in code you now have to reverse-engineer.

#The eight questions

You do not need a document. You need answers, in plain English, that you could say out loud in two minutes. Most of these are decisions only you can make, because they are about what the product is, not how the code works.

1. Who is the user, and what one thing are they here to do? Not the feature list. The single job. "A signed-in freelancer logs their hours against a client." If you can't name the one job, the agent will build for a user it imagined, and that user is always more generic than yours.

2. What is the smallest version that is actually useful? The agent will happily scope up. It will add settings pages, role systems, and a dashboard you didn't ask for, because more looks like better. Decide the first useful slice yourself. Everything past it is a later loop, not this one.

3. What has to be true for this to count as done? This is the one everyone skips and the one that matters most. Write the conditions in behavior, not vibes. "The streak count survives a page refresh." "A signed-out user hitting /dashboard lands on /login." These are your acceptance criteria, and they are the only thing that lets you check the result instead of squinting at it.

4. Who is allowed to do what? Auth is not a feature you add later. It is a decision that shapes every screen. Who can see this data, who can edit it, who is locked out. The agent will build a working app with no real access control and it will look fine in the demo, because in the demo you are the only user.

5. What is the data, and what are its rules? Name the core things your app stores and how they relate. A habit has a name, a frequency, and a list of completion dates. A completion belongs to exactly one habit. Get this wrong and every feature built on top inherits the mistake, which is why "it worked until my data got real" is such a common wall.

6. What happens when it goes wrong? The empty state before any data exists. The duplicate submission. The expired session. The network that drops mid-save. Demos only ever show the happy path, so if you don't name the unhappy ones, the agent won't build them, and your users will find them for you.

7. What are you explicitly not building? A boundary is a gift to the agent. "No payments yet. No mobile app. No admin panel." Naming the non-goals keeps the agent from wandering into scope that quietly triples the surface area you have to trust.

8. How will you know it works, without reading the code? This is the question that makes the other seven real. If your answer is "I'll click around," you have no gate. If your answer is "I'll walk down the done conditions from question three and confirm each one," you have a way to trust the result you didn't write. That is the whole difference between shipping and hoping.

#Vague prompt versus answered prompt

The gap is not effort. It is specificity. Watch the same idea, unanswered and answered.

Unanswered: "Build me a client invoicing app with login and a dashboard."

Answered: "A signed-in freelancer creates an invoice for a client with line items, a due date, and a total. They see a list of their own invoices, filterable by paid or unpaid, and can mark one paid. Only the invoice's owner can see or edit it. An unpaid invoice past its due date shows as overdue. Signed-out users go to /login. Not building: payments, PDF export, multi-user teams."

The second prompt is not slower to think of. It is the same app, with the eight decisions made out loud. And every phrase in it is a place the first prompt would have handed the agent a coin to flip: who owns an invoice, what "overdue" means, whether filtering exists, where signed-out users go. The agent building the vague version isn't worse. It just had to guess, and you will spend your afternoons discovering which way it guessed.

#Where this gets hard, honestly

There is a real cost here, and ignoring it makes this advice worse. Answering eight questions feels like friction at the exact moment you are most excited to just start building. And some ideas genuinely aren't worth it. A throwaway script, a landing page you'll delete next week, a weekend experiment, planning that is wasted ceremony. The line is durability: the moment real people or real data depend on the thing, the two minutes of questions saves you the three weeks of archaeology.

The other failure mode is the opposite one, and the audience calls it out constantly. One builder described the trap as being "stuck writing md files 80% of the time instead of actually getting stuff done." That is real. If your eight answers grow into a folder of design documents you maintain by hand, you have traded a fast mess for a slow one. The answers are a paragraph, not a project. They exist to define done, then get out of the way.

#What this changes for you

If you are building in Cursor, Lovable, Claude Code, or Replit right now, here is the concrete version. Your first feature will feel great either way. The eight questions won't change that. What they change is feature three and four, when the agent is editing a system it can no longer fully see. With the questions answered and written down, there is a record of what each earlier piece was supposed to do, so the agent, and you, can tell when a change breaks something load-bearing. With nothing written down, the agent breaks behavior it never knew was load-bearing, and you inherit a bug "disguised in a way no sane human could have come up with," to borrow a line from a builder on Hacker News describing exactly this.

This is the gap BrainGrid is built to close, and to close it without the md-files-all-day tax. You describe the feature in plain English, and BrainGrid's Planning Agent asks these questions for you, the ones about users, edge cases, access, and done, the ones you'd have skipped in the rush. It turns your answers into a requirement with explicit acceptance criteria, the kind you'd get from a good AI PRD generator that actually interrogates the idea instead of formatting it. From there you build in BrainGrid's managed sandbox with a live preview, or in your own GitHub repo with Claude Code, Cursor, or Codex over MCP. The Builder Agent works against those criteria, and a feature isn't done until every one is verified with evidence. The loop is Plan, Build, Verify, Repeat. The eight questions are just the Plan step, made explicit, before the agent can guess.

#The checklist, in one line

Before your agent writes anything, decide who it is for, the smallest useful version, what counts as done, who is allowed to do what, the data and its rules, what happens when things break, what you are not building, and how you will check the result. Two minutes of answers buys you a product you can trust instead of a demo you are afraid of. If you want the fuller method, read how to vibe code the right way, and if you are still choosing tools, start with our guide to vibe coding tools.

#FAQ

#What should I plan before building an app with AI?

Plan the product decisions the AI can't make for you: who the user is and their one core job, the smallest useful version, what has to be true for the feature to count as done, who is allowed to do what, the core data and its rules, what happens in error and empty states, what you are explicitly not building, and how you will verify the result without reading the code. These are answers in plain English, not a formal document. The build goes well or badly depending on how many of them you settled before pressing go.

#What questions should I ask before building software with AI?

Start with the eight in this post. The most important one is what counts as "done," written as checkable conditions ("a signed-out user is redirected to /login," "the total updates when a line item changes") rather than a vibe. Those conditions become the standard you check the agent's output against. Without them you can only judge the result by gut, one prompt at a time, which is how vague requirements turn into weeks of rework.

#Do I need to write a spec before using an AI coding agent?

You need answers, not necessarily a spec document. For anything durable, write a short paragraph that defines the feature and its done conditions, then let the agent build against it. For throwaway work, skip it. The trap on one side is starting with no plan and letting the agent invent your product decisions. The trap on the other side is turning planning into a folder of documents you maintain by hand. A paragraph per feature is the balance.

#Why does AI build the wrong thing even when my prompt is detailed?

Usually because the prompt is detailed about what you want and silent about the edges: access control, error states, data rules, and what "done" means. A capable agent fills every silence with a guess, and it guesses differently each time you regenerate. The fix is not a longer prompt, it is answering the specific decisions the eight questions surface, so the agent is executing your intent instead of improvising around its absence.

#How do I know if my AI-built app is actually done?

Check it against the done conditions you defined before the build, one by one, rather than clicking around and calling it finished when nothing obviously breaks. "Done" for a feature is a list of behaviors that have to be true, and verification is confirming each one with evidence. If you never wrote the list, you have no way to know the app is done, only a feeling that it seems to work, which is exactly the feeling that collapses the first time a real user does something you didn't test.

BrainGrid is the plan-first app-building platform that asks the questions you'd skip and turns your answers into criteria your agent builds against. Try it at braingrid.ai.