Code Review Needs a Named Job

Teams say a change needs review as though review were one operation. It is not. One reviewer may be checking whether the behavior matches the request. Another may be protecting an architectural boundary. A third may be deciding whether the evidence is strong enough for a risky release. Someone else may simply be learning how a part of the system now works.

Those jobs need different inputs and produce different decisions. A person judging product intent needs the approved behavior and the tradeoffs behind it. A security authority needs the changed trust boundary and its failure paths. A maintainer learning the system needs the reason for the design, not a scavenger hunt through renamed variables. Sending everyone the same diff does not create alignment. It hides the question each person is supposed to answer.

Agents make this weakness expensive. They can produce plausible changes faster than people can reconstruct the purpose behind them. If every change enters one general review queue, attention gets spread evenly across work whose consequences are not even close to equal. The queue grows, reviewers skim, and an approval starts meaning only that nobody found a reason to stop in time.

A review request should say what remains undecided. Does this implementation preserve a boundary the factory cannot test directly? Is the migration reversible enough for the proposed release route? Does the evidence cover the business consequence, not merely the code path? A reviewer can answer a concrete question. They cannot reliably discover which question mattered while reading the answer the builder already chose.

This changes where human judgment enters the factory. People should decide the destination, the acceptable consequences, and the uncertain boundaries before an agent builds through them. The review then tests a named decision against visible evidence. It does not ask a person to recover the destination from the tire tracks after the machine has arrived.

The author matters too, but authorship is not authority. Whether a person or an agent wrote the change, the route should identify who owns the consequence and who may accept it. An agent can explain its choices. A human can write convincing code. Neither fact proves the change belongs in production. Responsibility has to attach to the decision, not to whoever typed the patch.

A reviewer should not spend Tuesday repeating a rule the organization settled on Monday. Formatting, dependency policy, required test surfaces, forbidden imports, and known permission boundaries belong in executable controls. If the same comment can be predicted, the factory should make it before a person sees the change.

This is not about automating every review comment. Some objections depend on context, consequence, or taste that has not earned the force of a rule. Keep those visible as judgment. But when a decision repeats, force a choice: encode it, narrow it to a route where it applies, or admit that it is a preference and stop blocking work with it.

Every recurring comment left in the review queue is a tax on scarce attention. Agents will make that tax impossible to ignore because they do not get tired of presenting the same class of mistake. Organizations that keep paying people to restate mechanical standards will turn their best engineers into slow, expensive lint rules. Organizations that harden those standards will keep those people on decisions the machinery cannot make alone.

Code review is often defended as the way a team learns the system. That can happen, but it is a fragile way to preserve knowledge. A sequence of comments may explain why one patch changed. It rarely records the product promise, rejected options, operating constraints, and failure consequences in a form the next worker can find and use.

Keep those decisions beside the machinery they govern. Record why a boundary exists, what evidence protects it, and which authority can change it. Feed production surprises back into that record. Then let agents use it while planning and let gates test it during delivery. Knowledge that only appears after implementation is too late to guide the implementation.

People do not need to memorize every line agents produce. They need a durable account of what the system promises and how the factory proves those promises still hold. That account should survive the current reviewer, the current model, and the current shape of the code. A pull request can point to it. The pull request should not be the only place it exists.

Start each change with a route. Low-consequence work with strong automated proof can move without a person blessing every line. A new authority boundary, an irreversible data change, or behavior the factory cannot observe should stop for accountable judgment. The stop should name the question, the evidence available, and the person or role allowed to answer it.

Then measure what the review changes. If reviewers repeatedly catch a class of defect, build a control for it. If they approve without affecting the outcome, remove the stop or sharpen its job. If a decision keeps arriving after implementation, move it upstream. The goal is not fewer reviews as a vanity metric. The goal is to spend attention only where attention changes the result.

Our position is simple: code review will shrink as a universal ceremony and grow more important as a precise authority boundary. That shift will eliminate work built around moving patches and repeating standards by hand. Good. Agents should carry repeatable checking. People should own the judgments with consequences. A review with a named job makes that division real. A review without one is just another queue the factory will outrun.