AI made writing code almost free, which should have finally ended the old argument about how much to plan before you start. Why design carefully when regenerating the whole thing takes thirty seconds? Instead the opposite happened. The cheaper the code got, the more the planning started to matter.
That is not a paradox once you watch where the time actually goes. This week in r/nocode, someone who had burned through Lovable, Replit, and Cursor credits and still had nothing working asked which AI app builder to buy next. An experienced builder replied with a ratio, not a tool: you should spend about 1 hour designing the specs and 20-30 minutes actually building. Then the line that turns it from advice into a diagnosis: if you find yourself cursing the AI that it is not what I asked for, it is largely because you didn't set the requirements properly.
Two to one, planning to building. From someone whose building step is an agent that writes the code for him. That is the number worth explaining.
The hypothesis: unplanned time doesn't vanish, it moves
Here is the claim this post is built to test. The hour you skip up front does not disappear. It reappears downstream as debugging, reprompting, and rework, and it costs more there than it would have cost as planning.
The old wisdom was that planning trades slow-now for fast-later, a tax you pay to avoid mistakes. With an AI agent that math gets sharper, because the agent removes almost all of the "building" time but none of the "deciding what to build" time. When the code was the expensive part, a vague plan cost you a few extra hours of typing. Now the code is nearly free and the vague plan costs you something worse: an agent that confidently builds the wrong thing, fast, and reports done.
You have felt this if you have ever watched an agent produce a beautiful, complete, working feature that solves a problem you did not have. It did exactly what you said. You just had not decided what you meant. The gap between those two is where the skipped hour went.
Cursing the AI is a requirements bill coming due
The r/nocode builder's reframe is the whole argument in one sentence. When the output is wrong, the instinct is to blame the tool and go shopping for a better one. Sometimes the tool is genuinely weak. Far more often, the requirements were never set, and no tool can build what you did not specify.
This shows up as a specific, repeatable feeling. Builders in r/ExperiencedDevs described feeling illiterate about the codebase as agents generate faster than anyone can read, and one named the root cause bluntly: people run agentic loops to solve problems they do not even understand themselves. That is not a model problem. An agent handed a fuzzy goal will fill the gaps with its best guess, and its best guess is a coin flip that looks like a decision. You do not discover the mismatch until you are three features deep and the auth logic it invented in feature two fights the state management it invented in feature four. This is the same drift that makes your agent keep breaking things that already worked: nothing carried your intent forward, so each feature quietly renegotiated it.
The planning hour is where you catch that before it's written. Not because planning is virtuous, but because it's the only place the mismatch is cheap to fix. A wrong sentence in a spec costs one edit. The same wrong assumption discovered in a shipped feature costs a debugging session, a reprompt, and the quiet erosion of your trust in the whole app.
The ratio is not the point. The exit condition is.
Two-to-one is a useful anchor, but do not turn it into a rule. The honest version is that planning time should scale with how much of your intent the agent would otherwise have to guess. A one-file script needs almost none. A multi-screen app with auth, data, and money needs a lot, because every unstated rule is a decision the agent makes for you.
What you are actually buying with that hour is a definition of done the agent can be measured against. This is the difference between a loop that converges and a loop that just burns tokens. A builder in r/AI_Agents put the failure mode precisely while defending the idea of agent loops against the skeptics: a bare loop with no verifiable exit is guaranteed token burn with fingers-crossed results. Planning is how you write the exit condition. Without it, "build until it looks done" is the only stopping rule the agent has, and looks-done is exactly the thing that fails in production.
Consider the same feature, planned two ways.
Vague: "Build me a client portal with login and file upload."
Structured: authenticated users land on a dashboard listing their own files in a table with name, size, and upload date; clicking a row downloads the file; uploads accept PDF and images under 10MB and reject everything else with a visible error; unauthenticated users redirect to /login; a user can never see another user's files. Every clause in the second version is a line the finished build can be checked against. That is the skill underneath the planning hour, and it has a name: writing acceptance criteria an agent can actually verify. The agent still moves at agent speed. It just can no longer quietly ship the version where any logged-in user can download everyone's files, which is the kind of gap a demo hides and production reveals.
Where BrainGrid fits
That planning hour has a shape, and doing it well is a skill most builders are learning on the fly. This is the gap BrainGrid was built to close, so the hour is spent on decisions instead of on staring at a blank requirements doc.
You describe the idea in plain English, and the Planning Agent turns it into a structured requirement with acceptance criteria, data models, and designs. It asks the clarifying questions you did not think to answer and pushes back when the intent is vague, which is precisely the "set the requirements properly" step the r/nocode builder was pointing at. Then the Builder Agent runs the build against that spec, either in a managed cloud sandbox with a live preview or in your own GitHub repo through Claude Code, Cursor, or Codex over MCP. And the part almost nobody does by hand happens automatically: verification checks the finished build against every acceptance criterion, so the feature is not done until the evidence says it matches what you asked for.
That is the two-to-one ratio turned into a workflow, and it is the whole idea behind spec-driven development: the planning is where you decide what you mean, and the verification is where the agent proves it built that and not its best guess. Charity Majors made the underlying point in The Pragmatic Engineer: when you did not write the code, you have to move your trust to the other end of the process, to validation. The plan is what validation checks against. Skip the plan and there is nothing to verify against except vibes.
What changes for you
If you are shipping with an AI coding agent right now, here is the concrete implication. Your instinct is to measure progress by how fast the agent produces code, so a slow planning step feels like the agent is idling. Invert it. Measure progress by how few times you have to say "no, not like that." The builders who spend an hour framing the feature say it once or zero times. The builders who skip straight to building say it five times across three reprompts, and each round quietly rewrites something that already worked.
The trade-off is real and worth stating. On a genuine throwaway, a scratch script, a one-day prototype nobody will maintain, the planning hour is pure overhead, and you should skip it and vibe. The ratio only pays off when the thing has to keep working after you stop looking at it. That is also exactly the moment most builders wish they had planned, and by then the skipped hour has already been spent, at a worse exchange rate, on figuring out why the app broke.
So how much time should you spend planning before coding with AI? Enough that the agent is executing a decision instead of making one. The code was never the expensive part. Deciding what it should do always was, and pretending otherwise just moves the bill to the end and adds interest.
FAQ
How much time should you spend planning versus coding?
There is no universal ratio, but builders working with AI agents converge on planning taking as long as or longer than the build, often around two-to-one for anything non-trivial. The reason is that an AI agent collapses the coding time to near zero while leaving the "decide what to build" time untouched, so planning becomes the larger share by default. Scale it to ambiguity: a small script needs minutes, while a multi-feature app with auth, data, and permissions needs real planning because every unstated rule becomes a decision the agent makes for you. The goal is not a fixed percentage. It is that the agent should be executing decisions you made, not guessing at ones you skipped.
Is it better to plan before coding or just start coding?
For a small, well-understood task you have done before, starting directly is fine because you are effectively planning as you type. For anything with multiple moving parts, planning first wins, and it wins harder when an AI agent is doing the building. Unplanned work does not save time, it relocates it: the decisions you skip come back as debugging, reprompting, and rework, which are more expensive than the same decisions made up front. The practical test is whether you can state what "done" looks like before you start. If you cannot, you are not ready to build yet, you are ready to plan.
Why does my AI agent keep building the wrong thing?
Almost always because the requirements were underspecified, not because the model is weak. An agent handed a vague goal fills the gaps with its best guess and reports success, so "wrong" usually means "technically what I said, not what I meant." The fix is to write the acceptance criteria before building: the specific behaviors, edge cases, and constraints the result must satisfy. When those exist, the agent has something concrete to build toward and you have something concrete to check the result against. When they do not, you are relying on the agent to read your mind, and it cannot.
What is the 80/20 rule in coding?
The 80/20 rule (the Pareto principle) observes that roughly 80% of outcomes come from 20% of causes, and in software it shows up several ways: a small fraction of the code causes most of the bugs, a small set of features drives most of the value, and the last 20% of a project often takes 80% of the effort. For AI-assisted building, the useful version is that a small amount of upfront planning prevents a large amount of downstream rework. The 20% you spend deciding exactly what to build is what keeps the other 80% from turning into a debugging spiral.
Does planning still matter when AI writes the code so fast?
More than before, not less. When writing code was slow, a vague plan cost you extra typing. Now that an agent writes code in seconds, a vague plan costs you a confident, fast build of the wrong thing, which is worse because it looks finished. Speed makes the mismatch cheaper to produce and more expensive to catch, so the planning that prevents the mismatch is the best-paying time you spend. The bottleneck moved from writing code to deciding what the code should do, and that is exactly the part AI does not do for you. It's the same reason a vague prompt costs more than it looks like it should: the cost is just deferred.
BrainGrid is the plan-first app-building platform: it turns your idea into a spec with acceptance criteria, builds against it with your agent, and verifies the result before you call it done. Try it at braingrid.ai.
Originally published on the BrainGrid blog.
Top comments (0)