The Factory Starves at the Spec

Most software organizations still manage the line as if typing were the constraint. They break work into coding tasks, assign those tasks to people, and celebrate when each person completes more of them. That operating model made sense when implementation consumed most of the schedule. It becomes absurd when a fleet can turn a clear decision into tested code before the next decision is ready.

The factory does not eliminate scarcity. It moves it upstream. Someone still has to decide what the product must do, which tradeoffs are acceptable, what may never break, and what evidence counts as finished. Agents can produce options at machine speed. They cannot own the consequences of choosing among them. When those decisions arrive late or muddy, the line does not slow down gracefully. It manufactures ambiguity at scale.

A useful specification is not a long document. It is a decision package the factory can consume without guessing. It names the outcome, the boundary, the failure conditions, and the proof required at the end. If a behavior must survive a retry, say so. If an operator must be able to reconstruct a change, require the evidence. If two rules conflict, decide which one wins before an agent decides for you.

This changes the economics of planning. In the old system, a weak requirement could hide inside a long implementation cycle. Engineers asked questions as they encountered the gaps, meetings filled the holes, and the delay looked like ordinary development. An agent hits those gaps immediately. Give it room and it will fill them with plausible choices. Give ten agents the same room and you get ten locally reasonable systems pulling in different directions.

That is why specification becomes production inventory. The line needs a ready supply of decisions with consistent interfaces and explicit acceptance gates. A backlog full of titles is not inventory. It is a pile of labels waiting for somebody to do the actual work.

Agent dashboards make it easy to count motion: tasks started, changes opened, tests run, tokens spent. None of those numbers tells you whether the organization is feeding the right work into the factory. A fast line pointed at an unresolved question creates more review, more rework, and more confidence in decisions nobody actually made.

Measure the upstream constraint instead. How much work reaches the line with its outcome decided? How often does the factory stop to request a product decision? Which acceptance gates reject work because the requirement changed after implementation began? Which rules keep getting rediscovered because nobody turned them into durable constraints? Those signals expose the real queue: judgment waiting to be made explicit.

The uncomfortable consequence is that adding implementation capacity can reduce progress. If the specification supply is thin, every new agent competes for the same unresolved context and produces another branch of interpretation. More output is not more throughput when most of it returns to the line.

The highest-leverage engineers are no longer the ones who personally close the most tickets. They are the ones who turn product intent into constraints a fleet can execute and checks the fleet cannot negotiate away. They find the missing decision before it becomes five implementations. They define the invariant once, then make the factory enforce it on every run.

Product leaders move too. Their job cannot end with a roadmap phrase and a handoff. They have to make tradeoffs consumable: who the behavior serves, what happens at the edges, what failure costs, and what evidence earns release. That is not asking product people to write code. It is asking them to stop outsourcing decisions to the people who happen to encounter ambiguity last.

Some roles built around translating vague work from one human queue to another will disappear. The valuable work inside those roles does not disappear; it concentrates at the specification and acceptance gates. People who can own those gates gain enormous leverage. People who only move the ticket between them are standing where the factory is going.

Do not begin by asking how many agents you can run. Begin by tracing one piece of work from request to release. Mark every place where somebody supplies missing context, settles a conflict, or decides that the evidence is good enough. Those are not interruptions to automate away. They are the control surfaces your factory needs.

Then make each decision durable. Put product rules where the work can retrieve them. Turn critical boundaries into executable checks. Separate the agent producing the change from the system verifying the result. Record why an exception was accepted so the next run does not rediscover the argument from scratch. Only then add capacity.

Our position is simple: software factories will make implementation abundant, but abundance does not rescue weak intent. It exposes it. The organizations that win will not be the ones with the most agents generating code. They will be the ones that can make clear decisions, encode them once, and keep the line fed without surrendering judgment to the machinery.