24 Use independent review effectively

A second agent reads a patch and agrees with the first. This may be useful, but the number two does not establish independence. Both agents may have received the same mistaken requirement, trusted the same passing test, and followed the same persuasive explanation. Two approvals can therefore be two presentations of one blind spot.

Effective review creates an opportunity to challenge the work from a different position. The reviewer needs enough context to understand the promise, enough access to inspect the result, and enough freedom to disagree with the implementer's account. The goal is a justified acceptance decision, not a ritual exchange of approval.

Give the reviewer a question worth answering

“Review this for bugs” can be a useful broad request, but it should not be the only instruction for a consequential boundary. For the acquisition change, ask whether failed replacement preserves the usable old version, whether completion corresponds to consumer availability, and whether cancellation can release resources still in use.

Supply the exact candidate revision, the intended behavior, the diff, relevant contracts, and reproducible evidence. Include known failures and unrun checks. Let the reviewer inspect the implementer's rationale, but do not make agreement with it the assignment. A reviewer who cannot verify a claim should be able to report that limitation without inventing a defect.

A bounded review brief could read:

Review candidate R against base B for the replacement lifecycle. Focus on publication ordering, old-version survival, and cancellation while blocking work remains active. Inspect production paths and the tests that claim to cover them. Do not modify the candidate. Return actionable findings, material uncertainty, and the scope you actually inspected. A clean report applies only to R and that scope.

The read-only role makes it easier to separate findings from repairs. If the reviewer silently fixes the code, the author may never understand the defect, and the reviewed revision becomes ambiguous. A reviewer can propose a repair or be given a subsequent implementation task; the transition should be explicit.

Require a finding to carry its consequence

Consider an illustrative finding:

Behavior: Cancelling the public waiter releases the candidate directory while a blocking checker can still read it.

Location: The boundary that starts the checker retains the task handle but does not retain the directory's ownership capability.

Consequence: A replacement attempt can acquire the same directory before the first checker finishes.

Counterexample: Hold the checker, cancel the waiter, and try the competing acquisition. It must remain excluded until the checker returns.

Uncertainty: This follows from the inspected lifetime path; the competing acquisition has not yet been exercised on the target platform.

This report is useful even before a patch exists. It names the violated promise, the mechanism, a distinguishing observation, and its present evidential limit. “Race condition, high severity” without those details can consume more attention than it saves.

Severity should follow consequence and reachability, not dramatic terminology. A race in an unreachable fixture differs from a race at a public cancellation boundary. A style disagreement can be valuable without being a release blocker. The reviewer should distinguish a demonstrated defect, a plausible risk requiring investigation, and a preferred alternative.

Allocate human understanding deliberately

Practitioners disagree about how much source a human must read. That disagreement deserves more than a compromise slogan. Simon Willison argues that unreviewed generated patches can transfer the real work to collaborators; his proposed contribution standard includes a small understood change and evidence of testing. This is a responsibility norm rather than a measured defect-detection rate. Anti-patterns.

Salvatore Sanfilippo's July 2026 essay places more emphasis on controlling design ideas, comparative checks, performance, and QA than on routinely reading every generated line. He still describes reading Redis code for its maintainers and users, and leaves some skill-development questions open. His position challenges universal line-review requirements without removing the need to understand the system. Control the ideas, not the code.

Daniel Stenberg describes AI review after human review while retaining human architectural and merge responsibility for curl. That is a different allocation suited to a long-lived shared system, not proof that a particular sequence always finds more defects. A human in control.

The decision should reflect what must be understood and who will maintain the result. In a disposable personal experiment, behavior-focused QA may be sufficient. In a shared parser that handles hostile input, accepting a large generated change without a maintainer able to reason about its structure may be unacceptable. These settings do not differ merely in how enthusiastic their authors are about AI.

Design review, source review, runtime testing, and differential comparison reveal different failure classes. One cannot be substituted for another solely because it is easier to automate. Conversely, requiring every method on every tiny change can make review too costly to perform well.

Close findings against the repaired revision

Once the author changes the candidate, verify that the repair addresses the counterexample and preserves neighboring behavior. A passing new test is useful, but inspect whether the test actually reaches the former defect. Review the incremental repair instead of repeatedly regenerating the whole implementation and forcing everyone to start again.

The final acceptance record should name which findings were fixed, rejected with reasons, or deferred under an explicit decision. A later unrelated commit does not inherit an unlimited clean bill of health. Nor must a bounded review expand forever into every architectural concern a reviewer can imagine.

For an exercise, give a reviewer the chapter 23 acceptance claim and a candidate with premature completion deliberately introduced. Withhold your proposed diagnosis. Ask for a counterexample and a scope-limited conclusion. Repair the defect, then ask the reviewer to check the new revision. The observable result is a traceable finding-to-repair-to-verification sequence, including any claim the reviewer could not establish.