You Cannot Retrofit a Factory Around a Pull Request

Most teams introduce coding agents at the place where a developer used to type. The agent receives a ticket, changes the repository, opens a pull request, and waits for a person to decide whether the work is safe. That can be a useful improvement. It can shorten implementation and let several changes move at once. But the operating shape has not changed. Human attention still determines how much work the system can finish.

That is the trap in calling every agent workflow a factory. The new worker inherits a pipeline designed around scarce human production. Tickets carry informal context. Code review catches whatever the specification missed. Release depends on somebody recognizing the risk. Production feedback lives in another tool and reaches the next change only when a person remembers it. The agent accelerates one station while every surrounding station keeps its old capacity.

The result looks impressive at first because output rises before the queues become visible. Then reviewers receive more plausible changes than they can reconstruct, approval gets thinner, and unfinished work piles up behind the merge button. Faster production has not removed the bottleneck. It has made the bottleneck expensive enough to see.

A pull request is a good container for a change. It records a diff, gathers discussion, and gives existing tools somewhere to run. What it does not do is decide whether the change satisfies the business outcome. When approval means a reviewer reading until they feel comfortable, the real acceptance system is still a person with limited time and incomplete context.

Adding another model to review the first model does not settle this. Both workers can inherit the same missing requirement, reward the same shallow proxy, or mistake consistency for correctness. A builder that writes its own test can prove that its implementation agrees with its interpretation. A critic can add a second interpretation. Neither one creates an independent definition of what the business will accept.

The factory needs a verdict the builder cannot rewrite. That may be a contract, a state invariant, a replayable scenario, a permission boundary, a measured operating threshold, or a combination of them. The form changes with the consequence. The rule does not: acceptance must come from outside the worker's attempt and survive when the worker changes.

A real factory begins upstream of code. Work arrives with a destination, boundaries, and evidence requirements that an agent can execute. The repository exposes stable commands instead of tribal knowledge. Credentials grant only the authority the task needs. Verification runs in conditions the builder does not control. Release evidence travels with the change, and production signals can change the next route.

This is a redesign, not a better prompt. If a requirement matters, encode it where the route can stop. If a failure has happened twice, turn it into a replay or a gate. If an approval keeps asking the same question, capture the rule and let machinery answer it. Human judgment should define the standard and own the exceptional consequence, not repeatedly perform a check the system already knows how to make.

The order matters. Scaling agents before building those controls creates a flood of inventory and then asks people to absorb it. Building the controls first gives every additional agent a route that can reject bad work, retain the reason, and try again without consuming another round of coordination. The factory is not the number of workers. It is the system that lets their accepted output scale.

Some software outcomes have crisp mechanical answers. A calculation matches a reference. A migration preserves every required record. A latency budget holds under a defined load. Those are ideal factory gates because the worker can receive an unambiguous result without owning the judge.

Product work is messier. Whether an interaction is useful, a tradeoff is acceptable, or a consequence is worth taking may require accountable human judgment. Pretending otherwise does not create autonomy. It hides a decision inside a proxy and lets the system optimize the wrong thing faster.

The answer is not to keep a person at the end of every change. It is to separate judgment from repetition. People decide the destination, define unacceptable outcomes, and resolve genuinely new ambiguity. The factory turns those decisions into specifications, policies, examples, and gates that routine work can reuse. Each repeated judgment should leave machinery behind.

Our position is that software factories will remove roles built around carrying repeatable work from one human checkpoint to another. That does not happen because an agent types faster. It happens when the operating system can accept ordinary work, reject weak work, and escalate the narrow remainder without a person supervising every unit.

You can measure progress by watching the approval button. If agent output rises and human reviews rise with it, you have accelerated the old pipeline. If the same classes of change begin passing independent gates while exceptions arrive with specific evidence and bounded choices, the route is becoming a factory. The human layer is moving toward judgment instead of serving as runtime.

Keep the pull request if it is useful. Keep the tools your team knows where they still earn their place. But stop confusing familiar packaging with a new production system. A software factory starts when the route can prove routine work without asking a person to bless every diff. Until then, the agents are faster workers standing on the same old floor.