Every Software Factory Needs a Planning Floor

Build a factory that runs itself and you would expect the output to get more reliable, not less. With software factories, the opposite keeps happening. The faster and more autonomous the line gets, the more spectacular the misses become, because a fast line pointed at a vague target just produces the wrong thing at scale.

The reason is unglamorous. Every software factory automates the floor that turns a requirement into shipped code. That throughput is the part most teams optimize, and it is worth getting right, but a faster line is not the same as a more trustworthy one. Almost none of them automate the floor that turns a fuzzy idea into a precise requirement. That second floor barely exists in most setups, and it is the one that decides whether all the autonomy downstream helps you or quietly works against you.

Call it the planning floor. It is the part of the factory nobody is building, and it is the part that matters most.

#The factory got automated from the wrong end

Look at how the term is being used right now and you can watch the gap form in real time. Factory.ai just shipped Factory 2.0, pitching autonomous Droids that triage a signal, plan it, code it, review it, test it, ship it, and monitor it. Chamath, describing 8090's software factory, was unusually honest about where the hard part lives:

We first help write requirements, expand and frame dependencies and then execute with a more global knowledge of the problem.

Read that order again. Requirements first, dependencies framed, then execute. The execution is the easy half to automate, and it is the half everyone demos. The requirements-and-framing half is the planning floor, and it is the half that actually determines whether the global knowledge of the problem is correct or confidently wrong.

Simon Willison's survey of the model lays out a ladder of automation that most teams climb: assisted, where AI is glorified autocomplete; supervised, where an agent drives and humans manage exceptions; and autonomous, where specs and scenarios drive agents that converge without human review. Notice that the top of the ladder is defined by specs and scenarios. The whole autonomous dream rests on the quality of the input. Climb the ladder without building the floor that produces good input, and you have automated the journey from a bad spec to a shipped mistake.

#The hypothesis: input quality is the new bottleneck

Here is the claim the rest of this rests on. The more autonomous your software factory becomes, the more its output quality is bounded by the quality of what enters the line, and the less anyone is watching that entry point. Speed at the execution stage does not relax this constraint. It tightens it, because a faster line spends your vague requirement faster and in more places before anyone notices the target was wrong.

This is not the familiar complaint that AI writes bad code. The models are extraordinary and getting better every month. That is exactly why the bottleneck moved. When generation was scarce, the quality of your prompt was forgivable, because a human reviewed every line on the way out and caught the drift. When generation is effectively free and the review step is what you are automating away, the only place left to inject correctness is before the agent runs. The plan stops being paperwork. It becomes the load-bearing input.

There is a second-order version of this that makes the planning floor even more valuable. The execution layer is churning weekly. The Latent.Space newsletter recently called it "meta-harness summer", cataloging a wave of new orchestration layers arriving almost faster than you can name them: Conductor, Zed's ACP, Vercel's Eve, HarnessAgent, Databricks' Omnigent. If your factory's value is tied to whichever harness you wired in this month, you are rebuilding it next month. The thing that survives the churn is not the tool. It is the captured intent and the criteria the tool is checked against. The harness is rented. The plan is owned.

#What lives on the planning floor

A planning floor is not a Notion doc full of good intentions. It has machinery, and the machinery does three things the execution layer cannot do for itself.

It interrogates the idea before anyone builds. A real planning floor asks the questions you did not think to answer: what happens to an unauthenticated user, what does a canceled payment do to the plan, which edge cases are in scope. The point is to surface the unknowns while they cost a conversation, not a rewrite. You give a high-level description and the system asks the questions that turn it into something buildable.

It writes acceptance criteria the line can be checked against. This is the difference between "build a CRM" and a target an agent can hit and you can verify. Consider the same feature framed both ways:

Vague: "Add user authentication."

Precise: "A logged-out user hitting a paid route redirects to login. A canceled payment leaves the existing plan unchanged until the period ends. Session expiry forces re-auth on the next protected action. Each of these is a criterion the feature is not done without."

The first is an invitation for the agent to guess. The second is a contract. On an autonomous line, the difference between those two framings is the difference between a feature and an incident.

And it accumulates. Every requirement, decision, and verified criterion becomes part of the product's record, so the next feature starts from what the last one established instead of from a blank prompt. The execution layer is stateless by nature; a fresh agent session remembers nothing. The planning floor is where the memory lives.

This is the floor BrainGrid is built to be. The Planning Agent turns an idea into a requirement with explicit acceptance criteria, challenging vague intent and asking the clarifying questions before any code is written. The Builder Agent then executes against that spec, in a managed cloud sandbox with a live preview or directly in your GitHub repo through Claude Code, Cursor, or Codex over MCP, so the harness underneath stays swappable. Then the step the execution-first factories skip: a feature is not done until every criterion is met with evidence. Plan, build, verify, repeat. The plan is what the verifier checks against, which is the whole reason verification is possible at all. You cannot verify if you do not have a plan.

#What this changes for you on Monday

If you are wiring coding agents into anything that resembles a factory right now, the practical implication is specific. Your instinct is to spend your effort on the execution layer, picking the best harness, tuning the agent loop, wringing more speed out of the line. That effort has sharply diminishing returns, because the harness you tune this month is obsolete next month and the speed you gain is speed at producing whatever you pointed it at.

The real return is upstream. The hour you spend making a requirement precise, framing its dependencies, and writing down what "done" means is the hour that determines whether the next fifty automated steps converge on the right thing. On a manual team that hour was optional, because a human in the loop corrected the drift continuously. On an autonomous line there is no continuous human correction, so the correction has to be front-loaded into the plan. Build the planning floor first, and the factory above it gets trustworthy. Skip it, and you have built a very fast way to be wrong.

#The honest trade-off

A planning floor costs you the first hour of every feature, and that hour feels like friction when the agent is sitting right there, ready to generate. On a throwaway prototype, it is friction, and you should skip it. If the thing will never have a user, a payment, or your name on it, point the line at a loose target and let it rip. The software factory's pure-speed mode is genuinely the right call there.

The moment the thing is real, the math inverts. Anything someone depends on cannot afford a planning floor that does not exist, because the time you save skipping it gets repaid with interest the first time the autonomous line ships a confident, plausible, wrong implementation across twenty files you never read. Match the rigor to the stakes. For a demo, no floor. For a product, the floor is the load-bearing part.

The skeptics have a point worth taking seriously. The Register recently called loop engineering "the latest AI buzzword" and quoted Addy Osmani with the line that actually settles the question:

The loop changes the work, it does not delete you from it.

That is exactly right, and it is the whole argument for the planning floor. Automation did not remove the human. It moved the human's job to the front of the line, to the part where intent gets made precise. The factory can run the line. It cannot decide what should come off it. That decision is yours, and the planning floor is where you make it.

Automate the line all you want. Just build the floor that tells it what to make.

#FAQ

#What is a software factory?

A software factory is a structured, repeatable approach to producing software: standardized pipelines, reusable components, and automation that turns requirements into shipped code with less manual effort each cycle. The metaphor frames development as an assembly line where the process itself is engineered, not just the individual product. The idea predates AI by decades, but it has surged again as teams wire coding agents into the line so that agents, not humans, do most of the writing, reviewing, and testing.

#Why does input quality matter more in an autonomous software factory?

Because the human review step that used to catch mistakes is the thing autonomy removes. On a manual team, a person reviews each change on the way out and corrects drift continuously, so a vague requirement still gets fixed downstream. On an autonomous line there is no continuous human correction, so the only place to inject correctness is before the agent runs. That makes the precision of the plan the binding constraint on output quality. A faster line just spends a vague requirement faster.

#What is the difference between planning and execution in a software factory?

Execution is the part most factories automate: turning a written requirement into shipped, tested code. Planning is the part that turns a fuzzy idea into a precise requirement with framed dependencies and explicit acceptance criteria. Execution can be automated relatively easily and is what most demos show. Planning determines whether the execution is pointed at the right target, and it is the floor most factories never build.

#What are the phases of building software with AI agents?

A reliable loop has four: plan, where intent becomes a requirement with acceptance criteria; build, where an agent implements against that spec; verify, where the result is checked against each criterion with evidence; and repeat, where what was learned and verified accrues to the product's record so the next feature starts ahead. The plan phase is the one teams under-invest in and the one that bounds the quality of everything after it.

#Does building a planning floor slow you down?

At the start of each feature, yes. Writing acceptance criteria and framing dependencies before the agent runs costs an hour that feels like overhead when generation is instant. On a throwaway prototype, it is overhead and you should skip it. On anything real, that hour is what keeps the autonomous line from converging confidently on the wrong implementation, and it gets repaid the first time you would otherwise be debugging twenty files you never read.

If you are building something real and want the line pointed at a target your agent can hit and you can verify, start with a plan instead of a prompt.

BrainGrid is the plan-first app-building platform that makes intent precise before the agents run, then proves every feature against the criteria you set. Try it at braingrid.ai.