The Factory Is Built From Refusals

A coding agent can open a pull request. Ten coding agents can open ten. That is more production, but it is not yet a production system. If people still choose every task, prepare every workspace, inspect every attempt, and rescue every collision, the organization has automated typing while keeping the rest of delivery manual.

That arrangement feels fast at first because code is the visible output. The queue fills, dashboards move, and demonstrations look alive. Then review backs up. Two agents touch the same assumption. A plausible change passes a friendly test and reaches a person who has to reconstruct why it exists. The apparent speed upstream becomes human waiting downstream.

A software factory has a different shape. Work enters through rules. Each run gets a controlled place to operate. Tools arrive with bounded authority. Evidence decides whether the change advances. Exposure depends on consequence. The agent matters, but the surrounding refusals are what turn its output into something the business can absorb.

Intake should refuse work that is vague, duplicated, too broad, or not worth its cost. Isolation should refuse access the task does not need and prevent one run from contaminating another. Verification should refuse a change that cannot prove its behavior outside the builder's own account. The release gate should refuse exposure when the blast radius exceeds the evidence.

These are not delays pasted onto an otherwise autonomous process. They are the process. A gate makes a decision from recorded conditions and sends failure somewhere useful. Sometimes that means another agent attempt. Sometimes it means a narrower plan. Sometimes it means stopping for human judgment. What matters is that the route is explicit before the exciting output arrives.

A gate that only reports a problem is not enough. If the work advances anyway, the gate is decoration. If an agent can rewrite the acceptance condition after missing it, the gate belongs to the builder. If an unknown result is treated as a pass, uncertainty has quietly become permission. A factory needs refusals that hold under pressure.

The answer is not to place a person after every agent action. That simply turns machine throughput into a larger review payroll. People should decide the destination, define unacceptable consequences, and own the few gates where context cannot be reduced to a durable rule yet. Repeatable checking belongs in machinery.

This changes the job of review. A reviewer should not be discovering that the code does not compile, the requested file was never touched, or the agent wandered outside scope. Those are mechanical failures, and the factory should catch them before asking for attention. Human review is valuable when it judges whether the result belongs, whether the tradeoff is acceptable, or whether the evidence answers the business's real question.

As those judgments repeat, encode them. A rejected dependency becomes a policy. A missed edge case becomes a test. A risky release becomes a narrower exposure rule. The factory compounds when a person's decision changes the next run for every agent, not when the same person has to repeat the decision on every pull request.

You do not need a fleet to begin. Find the point where agent work creates the most rework and install one refusal there. If vague tickets produce wandering changes, tighten intake. If parallel runs collide, isolate them. If reviewers keep finding failures a command could catch, run that command before review and prevent advancement when it fails.

Order the checks by cost. Format and type checks should fail before an expensive test environment starts. Scope checks should fail before a domain expert is interrupted. A reversible, low-risk change should not wait behind a change that can alter customer data. The line gets faster by spending the cheapest evidence first and reserving scarce judgment for work that survived it.

Then record the failure and its route. Without that record, disposable environments become disposable memory. You need to know what was attempted, which boundary stopped it, what evidence existed, and what changed before the next attempt. That trail is how the system learns without depending on whoever happened to watch the run.

Our position is that the model is rarely the durable advantage. Models will change, prices will move, and agents will improve. If replacing one breaks your production system, you built an integration around a worker. You did not build a factory.

The durable asset is the sequence around the worker: how work qualifies, how authority is granted, how environments are created, how proof is collected, and how consequences control release. Those rules survive a model swap. They also make performance comparable, because every worker faces the same task boundary and the same independent standard.

Software factories will eliminate roles built around moving tickets, preparing routine environments, performing repeatable checks, and shepherding ordinary changes through human ceremonies. The remaining human work moves toward destination, standards, and consequence. That shift does not happen because agents can produce more. It happens because the factory can refuse bad work without waiting for a person to catch it. Build that capability first.