DEV Community

Cover image for Most AI Second Opinions Are Fake. I Built a Two-LLM Review Engine to Prove It.

Most AI Second Opinions Are Fake. I Built a Two-LLM Review Engine to Prove It.

Debashish Ghosal on August 27, 2026

Most AI "second opinions" are fake. Not because there is no second model. Because the second model usually sees the first model's framing, assum...
Collapse
 
heinrichneb profile image
Heinrich Neb

would_resolve_if is the best thing in this post and I think you undersell it by putting it under "worked better than expected". A disagreement artifact that names the experiment which would settle it is not a fallback output - it is the only output in the whole space that a human can act on without re-doing the reasoning. Verdicts tell you what to think; that field tells you what to run.

The uncomfortable part is that your headline table may be ranking the wrong thing, and you have the evidence for it in your own post.

DeepSeek + Mistral tops the ranking at 0.982 and 97 % verdict rate. Four sections later: "The strongest pair by convergence later turned out to have a major quality caveat: capitulation cascades. One side would concede everything in round 1 without real rebuttal."

Those two statements are about the same pair, and the second one does not qualify the first — it inverts it. A pair that capitulates converges fast and produces verdicts. So the ranking is at minimum ambiguous between "these two reason well together" and "one of them folds", and the pair at the top is the one you later identified as folding. The 80 capitulation cascades sit in the summary table right above "Theater cases: 1", with no marker distinguishing them, and a reader scanning that table takes away the opposite of what you learned.

I do not think this is a flaw in the work - you found it, which is the hard part. I think it is a flaw in where it appears. The caveat belongs in the table, not four sections down, because the table is what gets screenshotted.

This is a shape I keep running into from the other side: a metric that improves in the wrong direction. I derived alert thresholds last week from a 24-hour baseline that was missing the noisiest of three machines, because its log shipper had been dead for 45 hours. The thresholds came out more stable-looking than reality. A number that degrades toward "better" is the one nobody investigates.

On your fourth question - the right standard for proving independence - I would push past transcript structure and architecture guarantees, because both are claims about the system made by the system. Neither can go red.

The version that can: plant a canary in reviewer A's output. A token that appears nowhere in the diff, nowhere in the prompt, and has no reason to exist - then count how often it surfaces in B's independent review. Expected result is zero, every run, and any non-zero is a leak with a number attached. It costs one string and it turns "the architecture guarantees isolation" into a claim that a stranger can falsify without reading your code.

Your GPT + GPT control is the right instinct, but as stated it cannot fail: "if leakage had been happening, identical-model behavior would have looked far more suspiciously aligned" has no threshold in it. GPT + GPT scored 0.688 with a 57 % verdict rate - mid-field. What number would have counted as suspicious? Without that written down beforehand, the control reports whatever it reports and gets read as passing.

One question back, since it is the thing I would most want to know before adopting this: has the isolation ever been observed to fail? Not "could it" - has it. A guarantee with no recorded violation and no test that could produce one is indistinguishable from a guarantee that was never exercised.

Collapse
 
debashish_ghosal profile image
Debashish Ghosal

Thank you for the detailed feedback on this and another article. I managed to use these to find several issues in the pattern and ended up fixing. Thanks again

Collapse
 
heinrichneb profile image
Heinrich Neb

That's the best possible outcome and I'm glad it was useful - finding several issues in your own pattern from a comment thread is a better result than anything I could have written about it.

If any of the fixes turn out to be interesting on their own, I'd read that follow-up.

Collapse
 
vinhnguyenthanhdn profile image
Vinh Nguyen

The number I would check first is the 0 no-match out of 7,612 claims. A matcher that never once fires its negative verdict on a corpus that size is more likely to be lenient than the debates are to be accurate, and the 49/49 headline inherits that leniency directly rather than measuring the engine.

The control is cheap relative to your $0.53: run the same matcher with the pairings shuffled, claims from one PR scored against the documented outcome of a different PR. If the match rate stays anywhere near what you report, the number is measuring the matcher; if it collapses, 49/49 means what you want it to mean. The matching pass is offline, so the permutation run costs no tokens at all.

Collapse
 
debashish_ghosal profile image
Debashish Ghosal

Vinh, you're right that 0 NO_MATCH across 7,612 claims is suspicious — the matcher could be lenient and the headline number inherits it. The permutation control (shuffle claim-revert pairings, see if match rate collapses) is a clean diagnostic and costs zero tokens since the matching pass is offline. Filed as adversarial-debate#164. Thank you.

Collapse
 
vinhnguyenthanhdn profile image
Vinh Nguyen

One thing to pin down before you read the result: the permuted rate will not go to zero, because claims and outcomes from the same repo share file paths, identifiers and issue idiom, so a share of pairs will match on vocabulary alone. Run the shuffle many times and treat that spread as the null, then report how far 49/49 sits above it rather than whether the permuted rate looks small. Otherwise a residual around 40% reads as a failed control when it is actually the floor for that corpus.

Thread Thread
 
debashish_ghosal profile image
Debashish Ghosal

Thanks - Updated #164 with ollow-up nuance. Key change: the null is not zero — shared vocabulary (file paths, identifiers, issue idioms) means the permuted rate will have a corpus-specific floor. Updated acceptance criteria: N ≥ 100 shuffles for a stable null distribution, report real match rate as a z-score/percentile above that floor, and document that "~40% residual is the expected floor, not a failed control."

Collapse
 
alex-zaporozhan profile image
Alexandr Zaporojan • Edited

I barely even experimented with traditional multi-agent swarms because I went down the exact opposite path: building interconnected instruction files deeply cross-referenced with explicit links, protocols, and constraints. I kept asking myself: why isolate what should be uniting?

I recently open-sourced the result as the LEO Framework, largely out of frustration with how fragile AI coding has become and not wanting the reputation of AI-native engineering to collapse under a wave of brittle vibe-coding.

The system spans ~127 files under a single .cursorrules root, driven by a CHAIN PROTOCOL under a central @LEAD orchestrator. The roles aren't isolated sandbox bubbles — they are mutually aware of each other’s constraints, passing task states and requirements down a deterministic handoff chain.

On paper, conventional wisdom says this looks like cognitive bloat that should cause the LLM to hallucinate and lose context. In practice, the exact opposite happened: the interlocking rules created a structural gravity well. I used this exact architecture to build a full-scale 12-node visual AI pipeline constructor (similar to n8n, powered by LangGraph, with atomic chapter-level RAG and semantic retrieval) with virtually zero manual code — working entirely solo.

I only clicked the "Add Agent" tab in Cursor once. The moment I realized it isolated the agent's context from the rest of the system, I closed it. To me, that felt fundamentally anti-systemic.

For a while, I had serious imposter syndrome — wondering if I was just an amateur who didn't "get" why the entire industry was obsessed with isolated multi-agent swarms. But as the pipeline constructor grew in complexity and the codebase remained rock-solid without regressions, that doubt vanished.

Your article hits the nail right on the head: the links must communicate within the system, not live in isolation. When you isolate agents, you force the LLM to "guess and please" an environment it cannot see. And when an LLM is forced to guess, hallucination is the only possible outcome.

Collapse
 
debashish_ghosal profile image
Debashish Ghosal

Alexandr, the LEO Framework sounds like a fascinating counterpoint — interconnected constraint files creating a "structural gravity well" instead of isolated sandboxes. I think both approaches share the same root conviction: that an LLM left to guess its environment will hallucinate. We just disagree on whether the fix is isolation (my bet) or dense interconnection (yours). I'd be curious to see what happens when your system encounters a genuinely adversarial input — does the chain protocol propagate the constraint or does the interlocking make it harder to locate the failure point? Starred the repo, interested in where this goes.

Collapse
 
pankaj_gupta_0a01a1f6ba71 profile image
gmin_step

Really interesting, but I’m not sure the 49/49 result is as strong as it sounds. “At least one claim matched the actual cause” can coexist with plenty of false positives, and the post doesn’t show false-positive/false-negative rates or a blinded human score. Also, the 97% vs 4% verdict-rate gap may measure how readily a pair converges or capitulates more than review quality.

Collapse
 
debashish_ghosal profile image
Debashish Ghosal

You're right on both points. The "at least one claim matched" metric is weak — it coexists with false positives, and the 0 NO_MATCH rate is suspicious. We shipped false-negative measurement in v0.2.1 (#129) and just filed a permutation control for the LLM judge (#164) to validate whether the matcher is lenient. Blinded human scoring is still an open gap — tracked as part of the ground-truth methodology improvements for v0.3.0.