The Proof Must Outrank the Builder

Tests are supposed to constrain the implementation. They describe behavior the code must preserve, then fail when the code does something else. That relationship gives a passing test its meaning. The builder did not get to move the finish line after seeing where the work landed.

Agent-run delivery makes it tempting to collapse that separation. Give one agent a request, let it change the production code, let it update the tests, and celebrate when the suite turns green. The loop is fast, clean, and dangerously agreeable. If the agent misunderstood the requirement, it can encode the same misunderstanding on both sides of the check.

The problem is not dishonesty. The agent is following the route it was given. The problem is authority. You asked one worker to build the result, define the evidence, and judge whether the evidence was enough. A green check inside that loop reports consistency. It does not prove correctness.

Requirements written in ordinary language are useful because the people who understand the domain can read them. A product owner should be able to recognize the promised behavior without translating fixtures, mocks, and helper functions. An agent also benefits from that language because it carries the nouns, rules, and consequences the code is meant to express.

Readability alone is not the breakthrough. A polished requirement can still become stale documentation. The useful move is making the statement executable: connect the human-readable behavior to a check the system can run, and give that check the power to stop the work. Now the same artifact explains the destination and enforces it.

That changes the specification from context into control. Context helps the builder make a better guess. Control decides whether the guess survives. A software factory needs both, but only one of them gets the last word.

The safest sequence is simple. Decide the behavior first. Turn it into an executable boundary. Confirm that the boundary fails against the missing or broken behavior. Only then send an implementation agent to make it pass. The builder can inspect the contract, but it cannot quietly redefine the contract to fit its answer.

That does not mean tests can never change. Requirements change, weak checks get discovered, and some refactors legitimately alter the shape of the proof. It means those changes are a different kind of work. A changed claim about correct behavior deserves its own review, authority, and evidence instead of hitching a ride inside the implementation it is supposed to judge.

Factories should encode that distinction mechanically. Route specification changes separately from production changes. Record who or what approved each one. Require proof that a new check can catch the failure it names. If both must move together, make the reason visible and send the combined result through an independent gate.

Once the contract can execute, it becomes a shared object for the whole factory. A planning agent can break work down against it. An implementation agent can use it as the target. A review agent can challenge the change against the same behavior. The release gate can run it again under conditions the builder did not choose.

This is how parallel agents stop becoming a pile of conversations. They do not need one person to remember what each session was told or reconcile five plausible interpretations at the end. They coordinate through an artifact that carries intent forward and produces a clear failure when the work diverges.

The model is not the durable advantage here. Models will change, and the workers assigned to each station will change with them. The asset is the contract that survives those swaps: readable enough for judgment, executable enough for machinery, and authoritative enough to reject a confident result.

This also shows where human work is going. People will spend less time translating decided behavior into routine test code, running predictable checks, and manually comparing an implementation with a written requirement. Agents can do that repeatable work faster, retain the route, and apply the same standard every time.

Human judgment belongs earlier and higher. Someone still has to decide which behavior matters, which exception is acceptable, and whether the specification describes the right world. That decision becomes more valuable when it governs every later agent instead of being repeated in review comments after the code already exists.

Our position is that software factories will eliminate jobs built around performing this translation and coordination by hand. Keeping the proof informal will not preserve those jobs for long. It will preserve a bottleneck until a competitor encodes the decision and removes it.

Write the behavior so a person can challenge it. Make it run so the factory can enforce it. Then keep the builder below that boundary. The goal is not a test suite that agrees with the code. The goal is proof with enough authority to tell the code no.