Code Review Cannot Carry the Factory

Code review is useful. It exposes surprising choices, spreads context, and gives another person a chance to challenge the change. But it has never proved that software works. A reviewer reads a representation of the change and reasons about likely consequences. The running system still gets the final word.

Agents make that distinction impossible to ignore. They can change more files, follow more call paths, and produce more plausible code than a person can inspect with equal attention. The old answer is to ask the reviewer to read harder. That does not scale. Attention thins, queues grow, and approval becomes a ritual performed after the reviewer has already lost the full shape of the change.

The uncomfortable conclusion is simple: human review cannot remain the primary acceptance system. It should govern consequential decisions and investigate uncertainty. Repeatable correctness has to move into machinery that can run as often as the agents do.

A diff tells you what changed. It does not tell you whether the right thing changed. That answer starts with a concrete promise: the behavior the user should gain, the behavior that must not move, and the evidence that will distinguish success from a convincing imitation.

The factory needs that contract before implementation begins. Otherwise the agent writes toward an ambiguous request, invents the missing decisions, and hands a reviewer thousands of locally reasonable choices. The reviewer is then asked to reconstruct intent from code after the most important decisions have already been buried inside it.

Write the acceptance boundary first. Name the allowed surfaces, the forbidden effects, and the conditions the finished behavior must survive. An agent can still choose an implementation. It just cannot quietly choose what done means.

Agents are excellent at producing evidence that agrees with their own interpretation. They can write a feature, add tests for the path they selected, run those tests, and report a clean result. Every step can be sincere and the whole chain can still prove the wrong requirement.

Acceptance needs independence. Run checks derived from the original contract, not only from the implementation. Exercise the change in an environment the builder did not configure. Test adjacent behavior, permissions, failure paths, and rollback. Preserve the evidence so another system can decide whether the release gate actually held.

This is where the factory earns its name. It does not merely summon an agent and collect a patch. It separates specification, construction, verification, and release authority. One stage can challenge another because no single agent gets to define the problem, make the answer, and declare itself correct.

Removing line-by-line review as the default does not remove people from the decision. It changes what they are deciding. A person should choose whether the requirement is worth pursuing, whether the risk is acceptable, and whether the evidence answers the question the business actually asked.

When a reviewer catches a repeatable defect, the result should not be one more comment on one more pull request. Turn the lesson into a test, a lint rule, an architecture boundary, or better context for the next run. The correction then survives the reviewer, reaches every agent, and compounds across the line.

Some changes will still deserve close reading. New security boundaries, irreversible data operations, and unfamiliar architecture can justify it. The point is to route attention by consequence instead of making exhaustive reading the tax on every change. Human judgment is scarce. Spending it on mechanically checkable repetition is a choice to waste it.

Our position is that agents will absorb the repeatable work of implementation and much of the routine checking around it. That removes roles built around moving patches through queues and restating standards by hand. The jobs that remain will own the destination, the controls, and the consequences the machinery is allowed to create.

To get there, treat every review comment as a clue about a missing part of the factory. If the issue can recur, encode it. If the evidence is weak, strengthen the gate. If the requirement leaves room for a dangerous interpretation, fix the route before asking another agent to try again.

Keep code review, but stop asking it to carry a load it cannot bear. A reviewer can sharpen judgment. A factory must prove behavior. The organizations that separate those jobs will increase output without surrendering control. The ones that do not will turn their best engineers into a human throttle on machines built to run without one.