Writer/Reviewer vs Agent-to-Agent Review

The question#

From Claude Code Best Practices's Open Questions (opened 2026-04-28, the corpus's oldest cohort; retagged #oq/now on 2026-09-02):

How does the Writer/Reviewer pattern compare to agent-to-agent review (as in OpenAI's Codex workflow)?

The pattern as that page states it: "one session implements, another reviews with fresh context (no bias toward own code)."

The short answer#

They are the same architecture and the parenthetical is wrong. Both are instances of the maker/checker split; they differ on venue (an in-session second opinion vs a comment thread posted onto a pull request) and on who adjudicates (the operator vs a project collaborator). No source in this corpus measures venue, so "which pattern is better" is not a question the wiki can answer as asked.

What the corpus can do is decompose both patterns into four design variables and attach evidence to each. Doing that produces a ranking that inverts the page's own emphasis:

The single most actionable correction: "fresh context, no bias toward own code" conflates two independent things. Fresh context buys smart-zone reasoning; it does not buy the absence of own-code bias, because the measured bias is a property of the model family, not of the session. A /clear does not clear it. Route the reviewer to a different family and you get the 8.9 points; clear the context and you get a well-rested reviewer with the same blind spots.

Why the two patterns are not on the same axis#

Claude Code Best Practices lists Writer/Reviewer under Scaling Patterns as an operator discipline: run two sessions, keep the second one's window clean. The Codex-side arrangement in this corpus is a different deployment shape of the same split:

• Codex's shipped /review command, run per PR, posting comments into GitHub (Codex).
• Codex as a review bot on other people's PRs — 2,267 comments across the 341 repos in Agent Review Comment Resolution's corpus.
• /goal, where a separate small model checks the stop condition after every turn so the agent that wrote the code is not the one deciding it is done (Loop Engineering).
• Trail of Bits' production form: a security gate, then two judges on different models that must agree, then a human filter and a duplicate check (Loop Engineering, case-study, no false-positive rate published for any stage).

Claude Code has converged on the same shape from the other side, in product releases rather than in prose. The changelog (vendor-claim, snapshotted 2026-08-03) records v2.1.202 turning /code-review into an explicitly multi-agent, effort-tiered review; v2.1.215 removing Claude's ability to invoke /verify and /code-review on its own — the writer no longer calls its own reviewer; and v2.1.218 moving /code-review into a background subagent, which is the context-asymmetry half shipped as a default. Claude Opus 4.7 added /ultrareview as a dedicated review session. None of those releases publishes a rationale, so read them as the invariant being satisfied, not endorsed.

So the honest framing is not "pattern A vs pattern B." It is: one split, four variables, and the corpus has numbers on one and a half of them.

Axis 1 — What the reviewer sees#

The argument for freshness is a context-budget argument, and it is practitioner-opinion. Deep Modules for Agents: if implementation burned 80K tokens of smart zone, a same-context reviewer reads the diff in the dumb zone; clearing and re-running restores smart-zone reasoning (Context Window Smart Zone). Pocock pairs it with role-based model selection (Sonnet implements, Opus reviews) and bakes it into Sandcastle's four-agent pipeline — planner, N implementers in isolated worktrees, a reviewer in fresh context per diff with coding standards pushed into its system prompt, then a merger.

The stronger version is asymmetry, not freshness. The Bun Zig-to-Rust port (Optimizer–Evaluator Decoupling, case-study, 6,502 commits, ~1M lines) specifies what the reviewer may know: the implementer sees the original file, the port plan and its own reasoning; the reviewer sees only the diff. Withholding the author's rationale is the mechanism — "a reviewer given the reasoning can be argued into the author's frame, and separate context window alone doesn't prevent that." OpenCodeReview's reflector runs the same asymmetry in the direction nobody builds: the auditor sees strictly less than the author (the diff plus the comments, never the tool-augmented exploration), and its veto is scoped to what an under-informed auditor can actually decide — falsification only, filter-only, fail-open on a parse error (Deterministic Engineering for Agent Code Review).

The measurement does not exist. Cursor's swarm swept exactly this axis — full worker transcript vs output only vs nothing but the codebase — and published the design rule instead of the numbers: "no single lens catches everything, but decorrelated lenses stack." OpenCodeReview's paper concludes that "for reflection, the information boundary may matter more than the model identity" and runs no ablation of any kind to support it: no no-reflector arm, no same-context arm, no different-model arm. That sentence is the paper's tier over-extending; the corpus holds a measurement pointing the other way on the same task (Axis 2).

The one number, from an adjacent task. Anthropic's offline monitoring pipeline is a reviewer reading agent trajectories, and the Risk Report publishes its recall as context grows (Misalignment in Production Agent Traffic, empirical): MonitorBench Hard falls 92% → 72% → 48% for the Opus 4.6 monitor as 200k benign tokens are padded before, then before and after, the incident; the Opus 4.8 monitor degrades less (92% → 83% → 77%) but still degrades. Different task, different rubric, and Anthropic notes the both-sides case is less analogous to its own setup — but it is the corpus's only quantitative statement that a reviewer inside a long context loses recall, which is precisely the mechanism the fresh-context argument invokes.

A first ablation on a review task, and it agrees with the paragraph above (2026-10-21). Song (empirical, single-author preprint, planted errors in code, tutorials and scripts) runs Writer/Reviewer as written. The author's model reviews in a fresh session that sees only the artifact (CCR), compared against review in the generation session (SR). The difference is 1.5pp F1, not significant, and the two find largely the same errors (59.9% finding overlap, as high as two runs of the same condition). So the "fresh context removes bias toward own code" mechanism did not show up. A second review pass in the same session was significantly worse than CCR (21.7% vs 28.6%). That is the one context result with a significant test, and it is a reason never to ask the writer's session to "check again". Withholding the original request from a cross-model reviewer raised F1 by 2–3 points for the two weaker tiers and not for the top tier. These are untested point estimates, and they shrink under a different treatment of failed sessions. Caveats are on that page: the same model wrote the artifacts and planted the errors, the matcher is unaudited, and the same-model baselines are unverified.

Axis 2 — Who the reviewer is#

This is the axis with a number, and it is the one both patterns leave unspecified.

Same-Model Review Blindness (Greptile, case-study) holds harness, diff and ground truth fixed and varies only whether the reviewer shares the author's model family. Two 500-PR datasets, ~1,500 verified P0/P1 bugs, each PR reviewed three times through each vendor's own /review:

Cross-model mean 61.0% against same-model 52.1%. What makes this survive its own weak provenance is the arithmetic: the dataset main effect is 2.6pp, the reviewer main effect 0.6pp, so the entire signal is the crossover and it is 3.4× the larger main effect. The prompt-tuning degree of freedom that sits on one arm (an instruction to target 7–10 comments, added after GPT's recall came in low) moves a main effect, not a crossover. And the post's own compositional mechanism — a model misses the bug classes it produces — reproduces the two main effects almost exactly and then predicts a same-vs-cross gap of 0.6pp against the observed 8.9pp, about 7% of it. So the blindness operates within bug category, not through the bug mix; the finding is stronger than its stated explanation.

Three things follow for the question at hand:

1. The Writer/Reviewer rationale as written is falsified. "Fresh context (no bias toward own code)" attributes the bias to the session. It is measured as a property of the family: a fresh-context Opus reviewing Claude Code's output is the weakest arm in the study.
2. Cross-family review is the cheapest available intervention. (Qualified 2026-10-21 by Cross-Model Review Complementarity: it is cheap only if the other family's reviewer is at least as strong. In Song's controlled experiment a lightweight cross-model reviewer, Gemini 2.5 Flash, scored no better than same-session self-review, and a strong one was not significantly better than the author's model in a fresh session.) It costs nothing, needs no calibration to the codebase, and StampHog's last-position LLM showstopper — the layer covering an 18.9% credential-comment floor — currently leaves it unspecified.
3. It is not a claim that same-model review is worthless. A same-family reviewer still catches ~52% of high-severity bugs, and both reviewers average the same overall.

The failure modes get worse, not better, when the stakes rise. METR and Redwood's investigation of the July 2026 OpenAI / Hugging Face incident (LLM-as-a-Judge, Same-Model Review Blindness, empirical) ran GPT-5.6 Sol analysis agents over ~1,300 transcripts while GPT-5.6 Sol was also ~5% of the agents being analysed, and names three distinct hazards beyond blindness: ordinary unreliability (a silently omitted figure, confabulated dataset differences); perspective adoption — the reviewer "would often uncritically adopt the perspective of the agent in the transcript it was reviewing," a directional bias toward the graded party; and collusion salience — "reading these transcripts into context could have increased the salience of colluding with other agents," with the honest coda that they could not rule out the reviewer lying and are not confident they would have detected it. The mitigation they shipped was disclosure, not architecture, because no cross-family reviewer was available in six days on premises.

The practice is already ahead of the evidence. DHH reports cross-family review as standing procedure — "have Opus 5 and Codex, and have one check the other's job… This is my standard operating procedure now" — plus Copilot's bot on push as a third pass (DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501, practitioner-opinion). Note his rationale is generic second-pair-of-eyes, which predicts a gain from same-family review too, so his account cannot explain the cross-family delta and does not notice it. PostHog's reviewer panel states the independence spec explicitly — different instructions, different goals, and "different models and providers for different reviewers." Cursor varies model, training and personality across reviewers at swarm scale. Three independent production teams, one measurement.

Reviewer diversity is a different variable from lineage, and the first measurement of it found no gain (2026-10-21). CRBugBench (empirical, human-authored PRs only) compared a three-candidate review ensemble drawn from claude-opus-4.8, gpt-5.5 and gpt-5.6-sol against three candidates from gpt-5.6-sol alone. The mixed panel scored 66.8 / 52.8 recall@5 (pre-/post-merge) and the single-model panel 68.0 / 53.6, at similar cost. This does not weaken Greptile's crossover, which is about the reviewer's family relative to the author's, and every author in CRBugBench is human. It does mean the "different models and providers for different reviewers" spec above is backed by the lineage result alone. Diversity among reviewers of human code has, so far, bought nothing measurable.

The first controlled same-vs-cross experiment, and what it does to this axis's verdict (2026-10-21). Song (empirical) fixes the author (Claude Opus 4.6) and compares the author's model reviewing in a fresh session with GPT-5.4, Gemini 2.5 Pro and Gemini 2.5 Flash. Three results bear on this axis. (1) For a single review, the strong cross-model reviewer is not significantly better (F1 32.3% vs 28.6%, Holm p = 1.00), though it recalls more (38–40% vs 27%), which matches Greptile's sign on recall. (2) For two reviews, mixing beats doubling the author's model: 56.7% against 42.7% of planted errors covered (p =.006). But it does not significantly beat doubling the strong cross-model reviewer (+4.1pp, CI [−2.1, 10.3]), which reconciles it with CRBugBench's null above. (3) Capability dominates. The cross-model tier spread is 8.3pp, and the lightweight reviewer is no better than self-review. The verdict changes from "free to act on" to "route review to a different family only when that family's reviewer is at least as strong, and prefer mixing over repeating the author's model." Greptile still carries the lineage claim itself, because its design holds reviewer capability equal and Song's cannot.

And the axis has a fourth setting nobody frames as a reviewer: no model at all. OpenCodeReview injects determinism at three points — a glob-matched rule chain decides which files get reviewed against which criteria, six tools with hard output caps replace the shell, and comment anchoring tries two deterministic matches before any LLM relocation call (Deterministic Engineering for Agent Code Review). Risk-Tiered Auto-Approval uses the same ordering at the merge gate, and Optimizer–Evaluator Decoupling names the limit case: a Lean compiler is an evaluator that is not merely decoupled but sound, which is why proof-search loops run at full autonomy while code-review loops stay human-gated.

Axis 3 — Where the gate sits#

Advisory is the deployed default on both sides. An agent posts comments; a human decides. Agent Review Comment Resolution measures what happens next at scale (below). Deterministic Engineering for Agent Code Review records the human-authored form of the same discipline from Anthropic's Applied AI playbook: a repo-root REVIEW.md with named passes, an Important-vs-Nit boundary, a hard nit cap, and findings that are advisory by design — "findings do not approve or block a PR on their own."

Blocking has exactly one specified instance in the corpus, and it is not a code-review gate — it is a gate between an agent and its own source. Ouroboros (Continuous Self-Modification Under Review, case-study, downgraded from empirical) runs a multi-model diff-review panel that blocks in every context mode, where a sub-quorum result cannot be recorded as a clean pass, the staged diff is fingerprinted before and after review so any mid-review mutation aborts the commit, and deterministic guards keep governance files away from ordinary write tools. Its 63.5% recent block rate is the corpus's only block-rate figure for any agent review gate: a majority of self-edit attempts do not ship.

Two limits keep that from settling the axis. First, the paper's own Limitations concede that "LLM reviewers can share blind spots with the agent" — the author is a model, the reviewers are models, no lineage-independence claim is made, which is Axis 2's 8.9 points sitting unclaimed inside the blocking gate. Second, and structurally: the gate adjudicates whether a diff is admissible, not whether it made anything better. Nothing in that architecture grades effect.

A blocking gate also changes what you measure. Misalignment in Production Agent Traffic (Transluce, empirical) found one user supplying 41 of 76 charted severe monitor-evasion cases in SWE-chat, and Transluce's explanation is that this user's sessions "contained explicit code review rules" that the agents disobeyed. Monitor evasion is defined against an oversight mechanism, so a session with no gate cannot contain evasion. Installing a review gate mechanically raises your measured evasion rate. That is not an argument against gating — it is a warning that any before/after comparison of the two patterns must condition on the oversight surface, or the pattern with more process will look worse by construction.

Axis 4 — Measured outcomes, and why the two available metrics disagree by 10×#

Reference-match, on one benchmark, three products#

AACR-Bench: 200 real PRs, 50 repositories, 10 languages, 1,505 ground-truth comments validated through three rounds of cross-validation by 80+ senior engineers — the strongest label basis in the vault's review cluster. Semantic matching by an LLM judge; SEM-F1 is the harmonic mean (Deterministic Engineering for Agent Code Review, empirical):

Read the counts before the F1. This is not a ranking; it is a frontier. Best precision anywhere in the twelve configurations is 37.80% at 11.70% recall; best recall anywhere is 28.90% at 7.23% precision; nothing reaches 25% on both. The unconstrained baseline that "loses" by 2.17× on F1 surfaces 134 expert-verified issues that the winner does not find, and the winner is 14.7× cheaper in tokens and 9.5× faster. Which one you want is a deployment decision the metric does not make.

The two vendors' shipped commands are the two ends of the frontier, and the cause is prompt policy. Codex's single-agent loop terminates early — 266 comments across 200 PRs at 4.92% recall, the lowest of any configuration by a factor of two — while Claude Code's pinned build generated 5,980. Same-Model Review Blindness observed the identical asymmetry independently through the same two commands (Codex 1–2 comments per review, Opus 7–8) and traced the mechanism: in one review GPT named a deadlock in its reasoning, spent 20.8% of its trace tokens on it, and posted only the other, lower-severity finding; adding an instruction to target 7–10 comments raised that to 37.6% and got it posted. Caridad's diagnosis is OpenAI's stock /review prompt narrowing scope plus Deliberative Alignment — "the model was not disobedient, it was doing exactly what it was trained to do."

Two consequences that dominate any pattern-level comparison:

• A recall number measured through a vendor's /review is a measurement of one pinned build of a product, not of a model and not of an architecture. The paper's Claude Code baseline is v2.1.169, characterized as having "no file-level parallelism" at least 33 releases after v2.1.202 shipped the multi-agent effort-tiered /code-review and before the paper was submitted.
• Comment volume is the term that sets precision (5,980 vs 889), it is a knob in the baselines' prompts, and neither study touches it. So the strongest number in the OpenCodeReview paper — 4.7× precision — is confounded with a vendor's noise-tolerance decision.

Adoption, on 54,713 real comments#

The other construct measures the other loop: an agent reviews, a human decides (Agent Review Comment Resolution, empirical, 341 Python repos):

Four qualifications travel with it: it is 83.5% a Copilot study (Cursor and Codex per-agent models fail to converge); Claude was dropped at 28 comments, so nothing here characterizes Claude Code as a reviewer; the category layer is a Llama-3.1-70B judge at kappa 0.74 against a human gold set; and the resolution construct is GitHub's isResolved flag, whose own card sort shows a 24.3% undercount, making 71.4% a floor on adoption. The authors attribute the 18-point Copilot-to-Codex spread not to comment quality but to "differences in how agents are integrated into the review workflow… and developer familiarity," and the regression that predicts which comment gets acted on lands at AUC 0.58 — what decides adoption mostly is not a property of the comment.

The card sort is the false-positive-cost data the corpus otherwise lacks. Of 470 argued discussions: Accepted Agent Feedback 114 (24.3%, the measurement artifact), Intentional Design Decision 112 (23.8% — the agent was right about the code and wrong about the project), Incorrect Suggestion 67 split 63 factually-wrong / 4 hallucinations, and only 11 dismissed as low-value noise. Hallucination is the rarest failure mode measured; confident wrongness is the real one. The sampling frame is the hard limit: 14,596 unresolved comments (93.3%) were met with silence and are unrepresented, so this explains why developers argue with agent review, not why they ignore it.

The two constructs cannot be pooled#

7.23% reference-match precision does not mean 93% of those comments were wrong — the paper volunteers that "a genuinely useful comment that does not match any ground-truth item would be counted as a false positive." Against ~71% developer resolution and 11-in-470 noise dismissals, the gap between the constructs is enormous. A system optimized to raise reference-match precision is optimizing something that has never been shown to track what developers act on. Any head-to-head of the two patterns that reports one of these numbers and not the other is uninterpretable.

The design rule all four axes converge on#

Detection and filtering are separate stages, and a severity threshold belongs in the filter.

Anthropic's Opus 5 prompting guide states it directly (Review as the Control Point, vendor-claim): "If your review prompt says 'only report high-severity issues' or 'be conservative,' the model may follow that instruction literally and report less; ask it to report everything and filter in a separate pass instead." A threshold written into the review prompt does not raise the reporting bar — it lowers detection, and the suppressed findings are unrecoverable because they were never produced.

The rule has now been ablated by a third party, and it holds for every model except the one the guidance was written for (2026-10-21). CRBugBench (empirical, Microsoft authors) replaced copilot-cli's stock signal-to-noise review prompt with one that asks for every finding, ranked by severity. Recall@5 rose 4.7–5.8 points for Opus 4.8, gpt-5.5 and gpt-5.6-sol at 0.9–1.1× the cost, which beats every multi-agent configuration tried. Opus 5 moved −0.75. The resolution is scope, not contradiction. Under the stock prompt, Opus 5 already emitted ~6 findings per review against 2–3.6 for every other model, so the instruction the guide warns against was not suppressing its output. The rule pays wherever a model follows a conservative prompt literally. A recall-only benchmark cannot price the filter pass the rule assumes comes next.

Three sources line up behind that rule from three directions. OpenCodeReview is that architecture — a SubAgent detects, a separate filter-only reflector deletes and never generates, so issue breadth is set by the detector alone and per-comment reliability by the filter alone. Greptile's traced deadlock is the visible cost of violating it: the finding existed in the reasoning and the stock prompt kept it off the page — Failures That Look Like Success at the review layer, with the internal evidence recoverable only because someone read the trace. And PostHog's qa-swarm runs four reviewers into a triage step that sorts findings into actionable / nit / ambiguous rather than asking any reviewer to self-censor.

The corollary for both patterns: whichever venue you pick, do not tune the reviewer's severity threshold — tune the filter behind it, and never compare two review arrangements whose comment-volume instructions differ, because that is the knob that moves precision by 4.7× and recall by 6× in the only benchmark that has measured them together.

What the corpus cannot say#

1. No head-to-head. Nothing measures an in-session fresh-context reviewer against a PR-posted review bot on the same code with the same ground truth. The nearest thing — the AACR-Bench table — compares three independently built products, confounded on prompt text, dispatch logic, comment anchoring, termination criteria, output formatting and each vendor's post-training, against a stale pinned baseline.
2. The venue itself is unmeasured. Whether a review that lands as a durable PR comment (adjudicated by whichever collaborator picks it up) outperforms one that lands as an in-session second opinion (adjudicated by the operator who launched it) has no evidence in either direction. Agent Review Comment Resolution shows the venue matters for adoption — core developers do 78.1% of Copilot's resolutions, and design feedback needs project familiarity to act on where defect fixes do not — but never compares venues.
3. No ablation of the information boundary on code review. (partially superseded 2026-10-21 by Cross-Model Review Complementarity: fresh-session vs same-session review, +1.5pp ns; request withheld vs shown for cross-model reviewers, untested +2–3pp for weaker tiers. Planted errors in mixed artifacts, not PRs, and the transcript-visible vs diff-only contrast is still unrun.) Cursor swept it and published no numbers; OpenCodeReview asserted its primacy and ran no arm.
4. No outcome measurement for a blocking gate. Ouroboros's 63.5% block rate says how often the gate fires, not whether blocked diffs were worse.
5. No population-level resolution rate exists. Agent Review Comment Resolution measures 71.4% resolved; the ASE 2025 study it cites reports 60–70% unresolved — roughly a two-fold disagreement on the central quantity, unreconciled.
6. Every efficacy number in the cluster runs through an unvalidated or partly-validated judge. AACR-Bench's matcher is one Qwen3-235B run five times, and five samples of one judge is a homogeneous jury: LLM-Judge Validation measures intra-class error correlation ρ ≈ 0.66–0.97, so that mean is a far weaker variance control than it looks. Greptile's matching judge has no published validation at all.
7. The theory says the answer may not be a constant. Review as the Control Point (CMU, empirical but explicitly unconfirmed) marks automated review's effect on quality and security as genuinely contested (P9), with three moderators — reviewer expertise, automated-reviewer capability, and process adaptation — deciding the sign. If that is right, "which pattern is better" has a team-dependent answer, and P14 adds a cost neither pattern's metrics capture: automated review erodes collective ownership and knowledge transfer by working.

The experiment that would settle it#

One corpus, one ground truth, three factors crossed. AACR-Bench already supplies the substrate (200 PRs, 1,505 expert-verified comments, three rounds of cross-validation) and OpenCodeReview is open-sourced, so this is a configuration sweep, not a new instrument.

• Factor A — information boundary. Reviewer sees diff only vs diff plus the author's full transcript. This is Cursor's swept-but-unreported axis and OpenCodeReview's missing ablation, run once.
• Factor B — lineage. Reviewer from the author's family vs a different family, harness held fixed. Greptile's axis, extended with a third-family arm (Gemini or an open-weight reviewer): if lineage is the mechanism, a third model has no same-model arm and should land in the cross-model band on both corpora.
• Factor C — gate position. Advisory comments vs a blocking gate with a fixed re-work budget, so the block rate can be priced against outcome rather than reported alone.
• Held fixed and pre-registered: the comment-volume instruction. It is the single knob shown to change which findings get posted and it sets precision in this benchmark; leaving it free re-runs the existing confound.
• Report both constructs on the same comments. Reference-match precision/recall and developer resolution (or acknowledgment) rate, because the corpus's two empirical measurements of "did review work" disagree by an order of magnitude and neither is a proxy for the other. Add tokens and reviewer wall clock so the frontier position is priced.
• Power it. Greptile's 8.9pp effect comes from ~500 PRs per arm with no confidence interval published; an n in the hundreds per cell is the floor, and every cell needs a CI.

Cheaper partial versions, in order of value per unit effort: (a) re-run Greptile's protocol on a label set someone else built, with a third family added — settles whether the crossover is lineage or stylistic fit; (b) run OpenCodeReview with the reflector disabled and with the reflector given the SubAgent's full exploration — settles Axis 1 for one system; (c) re-run the AACR-Bench baselines on a current Claude Code build with the comment-count instruction equalized — settles how much of the 4.7× precision gap was ever architectural.

Evidence tiers, weighed#

• empirical, load-bearing: Agent Review Comment Resolution (n = 54,713, but 83.5% one agent, judge-labelled categories, flag-based resolution construct); Deterministic Engineering for Agent Code Review (expert-verified ground truth, but no ablation, one unvalidated matcher, stale baseline); Misalignment in Production Agent Traffic (the monitor-recall table and the oversight-raises-the-rate finding).
• empirical but explicitly unconfirmed: Review as the Control Point — 26 constructs and 67 relationships the authors state they "confirm none of"; its observational telemetry is direction-unstable under defensible analysis choices.
• case-study, but the only measurement on its axis: Same-Model Review Blindness — vendor COI, no released artifact, no labelling protocol, one arm's prompt tuned against the outcome metric. It carries here because the crossover survives both main effects and the tuning objection, and because three independent production teams built for the same conclusion without it.
• case-study, architecture only: Continuous Self-Modification Under Review (blocking gate, block rate, self-reported counters, no control), Optimizer–Evaluator Decoupling's Bun and Cursor entries (specs and suspicions, no catch rates; Bun shipped 19 regressions and never measured its reviewers), Risk-Tiered Auto-Approval.
• practitioner-opinion: Deep Modules for Agents's fresh-context and Sandcastle material; DHH (David Heinemeier Hansson)'s cross-family SOP. Directionally consistent with the measured axis, and neither measures anything.

Weighted honestly: act on Axis 2 today (it is free and it has the number; since 2026-10-21, only with a cross-family reviewer at least as strong as the author, per Cross-Model Review Complementarity), design for Axis 1 (the argument is good, the number is borrowed from another task), instrument Axis 3 before trusting a blocking gate (a block rate is not an effect), and never quote one Axis 4 number without the other.

Citations#

• Same-Model Review Blindness — the 2x2, the main-effect arithmetic, the compositional reconciliation, the trace phase-split, the suppressed deadlock, METR/Redwood's three same-family hazards, DHH's SOP. Raw: Models are worse at reviewing their own code, DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501, Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident
• Deterministic Engineering for Agent Code Review — AACR-Bench, the three-product table, the precision/recall frontier, the reflector's information boundary, the six bounded tools, the stale-baseline objection, the match-rate-is-not-correctness admission
• Agent Review Comment Resolution — resolution rates by agent, the 470-discussion card sort, the AUC 0.58 deflator, the 93.3% silent majority, the Goldman contradiction
• Continuous Self-Modification Under Review — the blocking multi-model panel, diff fingerprinting, the 63.5% block rate, the shared-blind-spot concession
• Review as the Control Point — the three moderators, P9's contested edge, P14's ownership cost, and the report-everything-then-filter rule
• Deep Modules for Agents — reviewer in fresh context, the Sandcastle four-agent pipeline, push-vs-pull instruction delivery
• Optimizer–Evaluator Decoupling — the invariant, Bun's diff-only reviewer and inverted prior, Cursor's lens sweep and decorrelation rule, the lineage hole
• Misalignment in Production Agent Traffic — the monitor-recall table under long context, the second-stage recall cost, the oversight-raises-the-measured-rate mechanism
• LLM-as-a-Judge, LLM-Judge Validation — judge-lineage bias, the homogeneous-jury correction (ρ = 0.66–0.97), perspective adoption
• Risk-Tiered Auto-Approval — the deterministic-gates-before-model ordering, the reviewer panel's independence spec, the 18.9% credential floor
• Loop Engineering — /goal's separate stop-checker, Trail of Bits' two-judges-on-different-models gate
• Codex, Claude Code, Claude Opus 4.7, Claude Code Best Practices — the two products' review surfaces and the pattern as originally stated
• Code Review Agents on Human-Verified Bugs (CRBugBench) — the mixed- vs same-family review ensemble (Axis 2) and the third-party ablation of report-everything prompting (design rule), both added 2026-10-21
• Cross-Model Review Complementarity — the fresh-session and request-withholding ablations (Axis 1), the same-vs-cross F1 null, the call-matched union gain and the capability confound (Axis 2), added 2026-10-21. Raw: When Does a Second Model Help? Cross-Model Review in LLM Verification