TL;DR
- One model = one blind spot. Claude and Gemini were trained on different datasets, have different architectures, and will miss different things.
- Consult for breadth, not consensus. The goal is to widen your analysis surface and catch blindspots, not to reach agreement. If all three models agree, that’s suspicious—run stress tests.
- The bridge is simple: Playwright drives a logged-in Gemini tab via Chrome DevTools Protocol, pastes your prompt, and scrapes the response when done. Real session, no API key.
- Two modes: (1) cold second-opinion—hand off a problem and ask for an independent take; (2) adversarial debate—assign sides, force defense, then reconcile. Both work; adversarial is brutal and useful for high-stakes calls.
- Anchoring is the trap. If you show Model B what Model A said and ask “do you agree?”, you get theater. Always pose cold or ask for the opposite argument first.
Every Model Has Its Blind Spot
I make the same mistakes in code as everyone else. My reasoning hits walls. I miss architectural gotchas and cut corners on testing. An LLM does the same, just in different places.
Claude is strong on deep reasoning chains, code patterns, and refactoring. It’ll catch logical inconsistency and trace a hypothesis to its breaking point. But it has a knowledge cutoff and training data gaps. Gemini has seen more recent internet crawl, different codebases, and approaches I’ve never encountered. But it drifts on long reasoning chains and sometimes confuses correlation with causation.
If I only ask Claude, I get Claude’s blindspots baked in. Same with Gemini alone. The only way to widen the aperture is to ask both—not to get agreement, but to see where they diverge. That divergence is where I’m most likely to be wrong.
The Philosophy: Widen the Surface, Don’t Seek Consensus
Here’s the mental trap: when two LLMs agree, it feels like truth. It isn’t.
Consensus between models often means they’re pattern-matching the same biases in training data, or they’re both leaning on the most obvious-sounding argument because that’s what humans upvoted. It’s not triangulation—it’s an echo chamber with extra steps.
The actual insight comes from disagreement. When Claude says “this architecture is sound” and Gemini says “you’re missing concurrency issues here,” that’s the data. I still make the call—but now I’m making it with more surface area covered.
The framework I use: consult 2-3 models to widen the analysis surface. The final call stays mine. Consensus is not evidence of correctness; divergence is evidence I should dig deeper.
The Bridge: Playwright + Chrome to Gemini
I automated this because running to a Gemini tab manually every time is a friction drain. The bridge is a Playwright script that:
- Opens or attaches to a logged-in Chrome session (DevTools Protocol on
localhost:9222) - Finds the gemini.google.com tab (or creates one if needed)
- Pastes the prompt into the input field (it’s a contenteditable div)
- Clicks send
- Waits for generation to finish (watches for the “stop” button to vanish or timeout after ~120 seconds)
- Scrapes the response text from the DOM
- Logs the exchange to a dated file (prompt + response, timestamped)
No API key. No rate limits. Just a real logged-in session automated. The Chrome session is persistent, so I can keep it running in the background and feed it prompts.
The round-trip is straightforward—pseudocode-ish:
open_chrome_session(cdp_endpoint="localhost:9222")
tab = find_or_create_gemini_tab()
paste_prompt(tab, "your question here")
click_send(tab)
response = wait_for_response(tab, timeout=120s)
log_exchange(prompt, response, filename=f"gemini_log_{today}.txt")
return response
In practice, the script handles tab state, detects when Gemini is generating, and bails gracefully if the session logs out. It’s not rocket science, but it removes friction.
Two Modes: Cold Second Opinion and Adversarial Debate
Mode 1: Cold second opinion. I ask Claude about an architecture problem. Then, without showing Claude’s answer, I ask Gemini the same question cold. Same with code reviews, research synthesis, anything analytical. The point is independence—each model sees only your prompt, not the other’s answer.
I log both and then sit with them. Usually one catches something the other missed. Sometimes they agree, and I scrutinize harder (see: consensus trap).
Mode 2: Adversarial debate. For high-stakes decisions (should I ship this? is this security hole real? does this design trade-off make sense?), I assign sides. “Claude: argue for this approach. Gemini: argue against it, as hard as you can.” Each takes one round to stake a position, then a third round to reconcile or defend. It’s messy, it’s opinionated, and it surfaces arguments I wouldn’t generate on my own.
Adversarial mode is slower and overkill for reversible decisions. It’s worth it for choices that have blast radius.
When It Helps, and When It’s Noise
It helps:
- Architectural reviews before committing to a design that’s hard to change
- Security-adjacent decisions (risk modeling, threat surface)
- Research synthesis where I need orthogonal perspectives
- Code patterns where “the obvious way” might hide gotchas
It’s noise:
- Quick refactoring questions (just ask one model and move on)
- Trivial syntax or API lookups
- Decisions you can reverse in 30 minutes
- When you’re already confident in your analysis
Also: paralysis. If I convene a panel for every decision, I stop shipping. The rule is: Panel for the decisions that have escape velocity. Solo for everything else.
The Gotchas: Anchoring, Groupthink, Contamination
Anchoring. If I ask Model B to review Model A’s answer (“does this look right to you?”), I get agreement theater. Model B will agree with 80%+ confidence because I’ve primed it. The fix: ask cold, or ask for the opposite (“poke holes in this approach”) before revealing the other answer. This is the same cognitive bias Kahneman explores in his work on judgment under uncertainty—Thinking, Fast and Slow is a brutal read on how anchored we all are, and how hard it is to escape.
Groupthink in loops. If I run a multi-turn debate where models see each other’s responses, they converge toward consensus even if they started out disagreeing. To fight this: cap rounds (1-3 max), give each model a distinct persona so they don’t blend, and always run a stress-test round at the end (“assume your own answer is wrong—what would break it?”).
Confirmation bias in data. If I feed the bridge only the data that supports thesis A, I get a rigged debate. The fix is obvious but easy to skip: feed all the relevant signals—the arguments for and against—and ask each model to weigh them.
Session expiry. The Gemini tab can log out. When it does, the bridge fails. Keep the browser session alive or add a health-check that re-authenticates before prompting.
Parallel contamination. If I run two automations against the same Gemini session in parallel, their conversation contexts bleed into each other. Solution: give each automation its own chat or conversation ID, or use different browser profiles.
Cost and latency. More opinions = more overhead. Don’t call a panel for a five-minute decision. And Claude + Gemini round-trips add latency—this is async work, not synchronous consulting.
Wiring It as a Skill
I’ve wrapped the bridge in a /gemini-bridge skill so I can invoke it without context-switching. The skill handles session management, retry logic, and logging. It’s a thin wrapper around the Playwright script, but the wrapper saves setup friction every time I want to consult.
The flow is: pose a question in Claude Code → /gemini-bridge "your question" → Gemini’s answer lands in my transcript alongside Claude’s perspective. No manual tab-flipping, no copypaste.
For adversarial mode, I string two calls together with assigned sides and then manually review the output. It’s not fully automated, but that’s intentional—the reconciliation step is where I do the real thinking.
A Worked Example: Should I Redesign This?
I had a microservice that started as simple but grew into spaghetti. Should I refactor now or wait until it breaks under load?
Cold second opinion:
- Asked Claude: “Refactor now, sunk cost fallacy will make it worse later, modularity compounds.”
- Asked Gemini cold: “Depends on your load forecast. If you’re not hitting the wall, refactoring is a distraction. Wait for the signal.”
Different answers. Both defensible. The real insight: my decision hinged on a load forecast I hadn’t done. So I did that first, then both models had better input.
Adversarial mode (to pressure-test my decision):
- Claude arguing for refactor now: upfront cost, prevents worse technical debt, morale boost
- Gemini arguing against: lock in uncertainty, miss requirements, opportunity cost
- Reconciliation: “The decision hinge is load forecast and staffing. If you have spare cycles and the forecast is in your direction, refactor. If you’re at capacity, don’t.”
I still made the call. But I made it armed with explicit tradeoffs instead of hunches.
The Human Call Stays Yours
This is not delegation. It’s widening the surface before I commit. The LLMs are tools to poke holes, expose blindspots, and offer patterns I might not see. The judgment call—the willingness to take the blame if I’m wrong—stays mine.
That’s also why consensus is suspicious. If both models agree, it doesn’t mean I’m right. It means I should stress-test harder.