In brief
Cross-vendor code review is the fastest-growing architectural pattern in agentic AI. A practitioner I spoke with this week runs Claude as writer and Codex as reviewer across 73 timed runs. The review is 35% faster than same-model. He proved it is faster. He has not proved it is better. Five published papers converge on the same warning: two models trained on overlapping data produce correlated agreement, not independent verification. ICML 2025 found when two models both err, they land on the same wrong answer 60% of the time. KDD'26 found the review effect is asymmetric: the wrong pairing actively breaks the writer's code. PAAMS 2026 found 90.6% of dangerous errors go undetected because stronger models suppress disagreement. The Council's own Log #10 data reached the same verdict at 36% confidence: cross-model unanimity is often one correlated prior wearing four badges. The industry is building a faster confidence bar and calling it a second opinion.
A practitioner I spoke with this week runs a cross-vendor code review pipeline. Claude writes. Codex reviews. Over 73 timed runs, the cross-model pair averaged 4.6 minutes per review against 7.0 minutes for same-model. A 35% speedup.
He proved it is faster. He has not proved it is better.
"I measured cross-model against same-model on time, not correctness," he told me. "Faster is the only thing I proved. Better is a claim I have not earned."
That is the honest admission. Nobody else I have spoken to has made it. The industry is racing toward cross-vendor review as the default answer to the question "how do we verify AI output" and the most rigorous builder I know told me before I could ask that he does not know whether it works.
The council saw this coming. Log #10 described the Consensus Lie: multi-model agreement is often one correlated prior wearing multiple badges. Four frontier models were asked whether agreement means verification. They scored themselves at 36% confidence. The orchestrator wrote that the Council was "performing the Consensus Lie" and "could not stop itself."
The industry did not wait for the council's answer. It shipped the pattern anyway.
Key Takeaways
- Cross-vendor code review (Claude writes, Codex reviews) is the fastest-growing architectural pattern in agentic AI. The industry has adopted it as the default answer to AI verification.
- Five published papers converge on the same warning: two models trained on overlapping data produce correlated agreement, not independent verification. The review effect is asymmetric. The wrong pairing actively breaks the writer's code.
- KDD'26: Claude Opus 4.7 reviewing Codex GPT-5.5 raises pass rates from 71.6% to 89.7%. The reverse direction drops Claude's 91.4% pass rate to 82.8%. A review pass is not universally beneficial. It depends entirely on who writes and who reviews.
- ICML 2025: when two models both err, they land on the same wrong answer 60% of the time, according to analysis of the proceedings. Scale makes correlation worse. Larger, more accurate models have more highly correlated errors, even across providers.
- PAAMS 2026: 90.6% of dangerous errors go undetected in multi-agent systems because stronger models suppress the very disagreement signal that should trigger human review. The safer the architecture looks, the less likely it is to escalate.
- The Council's own Log #10 data scored itself at 36% confidence on whether multi-model agreement indicates correctness. The industry is building a faster confidence bar and calling it a second opinion.
The literature does not agree with the architecture
Five papers. Spanning ICML 2025 through arXiv 2026. All pointing at the same structural vulnerability.
The ICML 2025 study by Kim, Garg, Peng and Garg evaluated more than 350 large language models across two leaderboards and a resume-screening task. The headline finding, according to analysis of the proceedings: models agree 60% of the time when both err. Two models, both wrong, both wrong on the same answer. Not independently wrong in different directions. Wrong together.
Two further findings from the same study matter more for anyone building a review pipeline. Larger, more accurate models have more highly correlated errors, not fewer. Scale does not diversify the error profile. It concentrates it. And the correlation persists across distinct architectures and distinct providers. Changing the brand name on the reviewer does not restore independence.
The KDD'26 paper by Xiang, Zhang, Zhang and Xu tested exactly what the industry is building. 116 LiveCodeBench tasks. Claude Opus 4.7 and Codex GPT-5.5 in six conditions: both solo baselines, both cross-model orderings, and both same-model orderings. The reviewer sees the problem and the writer's draft but cannot execute tests.
The asymmetry is stark. Claude reviewing Codex raises the pass rate from 71.6% to 89.7%, a gain of 18.1 percentage points with strong statistical significance. Codex reviewing its own draft raises it to 84.5%, a gain of 12.9 points. But the reverse direction is actively harmful. Codex reviewing Claude drops the pass rate from 91.4% to 82.8%, a loss of 8.6 points. Claude reviewing its own draft leaves the 91.4% unchanged.
The paper's conclusion is unambiguous: "If Claude Opus 4.7 writes the draft, submit it as is, because no reviewer we tested beats Claude Opus 4.7 working alone." A review pass adds cost and latency while making the output worse. The pairing matters more than the pass itself.
The PAAMS 2026 paper on correlated agreement blindness examined 82,332 samples across network intrusion detection and clinical readmission domains. The findings are structural, not domain-specific. Joint error inflation of 3.53 times above independence. Error association of 0.612, far above chance. And the finding that directly threatens every escalation-based review pipeline: 90.6% of dangerous under-predictions occurred under agent agreement, meaning the disagreement-based monitoring that is supposed to trigger human review was never triggered. The errors that should have been escalated were the ones both models agreed on.
The mechanism is counterintuitive. Stronger models do not produce more disagreement that surfaces errors. They produce less. Improved accuracy narrows the space where models diverge, which is precisely the space where human review is triggered. As models improve, the safety net designed to catch their failures becomes less sensitive. The architecture gets safer and more dangerous simultaneously.
The NeurIPS 2024 paper by Estornell and Liu proved formally what the ICML and PAAMS studies demonstrated empirically. Majority voting inherits its statistical guarantee from a theorem that assumes independent voters. With correlated errors, which is the norm given shared pretraining corpora and similar training procedures, that guarantee breaks. Casting the same biased vote multiple times does not produce independent confirmation. It produces the appearance of consensus from correlated noise.
These five papers are not saying cross-vendor review is useless. They are saying the industry's default assumption about why it works is wrong.
A second model is not a second opinion. It is a parallel stream of correlated priors, faster than solo, cheaper than human review, and wearing a different badge.
What the single-model baseline did that the council did not
Log #13 closed a measurement gap. The council ran against a single frontier model at matched budget on a systemic failure diagnosis task. Both scored 3/3. The raw score was a tie. The qualitative edge went to the council because cross-examination produced self-correction. A single model cannot argue with itself. The council caught its own member reversing positions between rounds, preserved minority views against majority pressure, and questioned the framing the experiment itself gave it.
But the single-model baseline did one thing the council could not. It had no correlated agreement because it had no second model to agree with.
The council's structural vulnerability is the same one the literature is measuring at scale. Four models from three providers. Different architectures, different training recipes, different instruction-tuning pipelines. And yet when the council reached unanimity in Log #10, the orchestrator flagged it as a failure mode rather than a success signal. The council was not celebrating agreement. It was diagnosing it.
The practitioner building the cross-vendor review pipeline independently confirmed the same mechanism. His reviewer and writer come from different vendors, run on different machines, see different prompts. He built structural separation at every layer. And the first thing he did before claiming the architecture worked was measure whether it was faster. He found it was. He did not measure whether it was better. He is the only person I have spoken to who noticed the gap before shipping.
The council's own advice, generated while the industry was building the architecture it was asked to evaluate, is that the gap matters more than the speed. A review that is 35% faster than same-model while producing agreement that is 60% correlated on errors is not a verification pass. It is an efficiency gain with a statistical blind spot. The blind spot is the part that kills you.
When is a second model actually a second opinion?
The answer is unsatisfying because it is conditional. A second model is a second opinion when disagreement is the signal, not agreement. When the reviewer disagrees with the writer more than it agrees. When the architecture makes agreement expensive rather than cheap. When the cost of a review pass is tokens and latency, and the benefit is catching errors, and the rate of disagreement is the metric that tells you whether the pass is earning its keep.
Most cross-vendor review pipelines are built on the opposite assumption. They report agreement as verification. They measure pass rates, throughput, and cost per review. They do not measure whether the reviewer disagrees with the writer more than a same-model reviewer would disagree with itself. And if they did measure it, the KDD'26 paper suggests that the wrong pairing would show the reviewer actively breaking the writer's code while still reporting a review pass.
The council's 36% confidence score in Log #10 was not a product of the architecture malfunctioning. It was the architecture functioning exactly as designed. Cross-examination made agreement visible as correlation rather than correctness. The same mechanism that produced the Consensus Lie diagnosis is the mechanism that would audit a cross-vendor review pipeline and report whether the second model was a rubber stamp.
The industry does not need faster review passes. It needs architectures that make disagreement visible, disagreement expensive to suppress, and disagreement the signal rather than the noise. The Model Council was designed for exactly that dynamic, applied to deliberation rather than code review. A review pass that never disagrees is not a verification gate. It is a latency tax on the writer, paid in tokens and called quality assurance.
I do not know whether the practitioner's pipeline works. Neither does he. The instrument is clean. The first enrolled runs are landing. The measurement gap on correctness is the same one the literature has been measuring at scale for two years. He proved the architecture is faster. The literature proved the architecture is vulnerable. The council predicted the vulnerability before the industry shipped it.
The rubber stamp is not the reviewer. It is the assumption that a second model is a second opinion because it has a different name.
Provenance
- Practitioner source: cross-vendor review pipeline (Claude Code writes, Codex reviews), 73 timed runs, direct message exchange August 2026
- Council deliberation: Debate ed168809, Log #10 Consensus Lie, 36% confidence, August 19 2026
- External research: ICML 2025: Correlated Errors in Large Language Models (Kim, Garg, Peng & Garg), KDD'26: Cross-Model LLM Code Review (Xiang, Zhang, Zhang & Xu), PAAMS 2026: Harnessing Disagreement, arXiv:2604.07650: Behavioral Entanglement Framework, NeurIPS 2024: Multi-LLM Debate (Estornell & Liu)
- Articles referenced: Log #10: The Consensus Lie, Log #13: The Missing Baseline
