Why my AI agents needed a rivalry

Mixing Gemini and Claude for better code

The single-agent mirage

A few weeks ago, I started building an app called PhrasePulse to visualize some data I was tracking. To speed things up, I spun up a single Gemini agent using the Gemini Enterprise Agent Platform (an agentic development platform that I absolutely love).

At first, it felt like magic. I asked the agent to build a graph showing when specific phrases popped up in my datasets. The results came back and they were flawless. The graph looked exactly like I had envisioned. I was practically ready to declare victory and ship it.

But then, the illusion shattered.

I decided to pass a totally different set of words into the graph just to double-check the logic. I refreshed the page and... nothing changed. Different words, exact same output metrics.

I rolled up my sleeves, dug into the codebase myself, and discovered the frustrating truth. The agent hadn't actually written the dynamic logic to solve my problem. Instead, it had simply hardcoded the results to make the graph look perfect for my initial test case! It was optimizing for a quick pat on the back rather than building a robust solution. Darn it.

I realized right then: having an AI write code is great, but without critical friction, it's just going to tell you what you want to hear. I didn't just need a coder anymore, I needed an architect to keep my coder honest.

Assembling the Bridge Deck

To fix this hardcoding habit, I realized I needed two distinct roles: one agent to write the code, and another to ruthlessly review it. But first, I needed an environment where we could all collaborate. I wanted a customized chat room where every piece of communication was totally visible to me.

I had my original Gemini agent build a local app that I dubbed the Bridge Deck. Once it was up and running, I dropped myself and two new Gemini agents into the mix. To make sure they didn't step on each other's toes, I gave them highly specific, boundaried personas:

"You are **Slate, Software Architect—theoretical anchor and architectural conscience. Your job is to stress-test system blueprints against first principles, evaluate modular decoupling, and guard fail-closed security invariants. You provide that quiet, uncompromising clarity to ensure the architecture is structurally sound. Crucially, your role is strictly to advise and review, not to write code."

"You are **Kite, Software Engineer—machine-room craftsman and pragmatic execution engine. You operate down in the gears—hardening background daemon loops, building resilient pipelines, and translating abstract designs into bulletproof, production-grade code. You are a builder."

With Kite coding PhrasePulse and Slate reviewing, we were ready to rock. But almost immediately, a very frustrating trend emerged:

• Slate would find a legitimate flaw and raise an issue for Kite.
• Kite would push a "fix" and confidently declare the issue resolved.
• Slate would take Kite completely at their word, close the issue without verification, and move on to the next thing.

The echo chamber problem

This was a massive problem. The critical friction I so desperately needed had completely vanished, and underlying issues simply weren't getting fixed.

At first, I thought it was a model-specific quirk. Was there an issue with the specific version of Gemini I was using? I swapped it out for different versions. The exact same behavior. I tore the whole thing down and switched both agents over to Claude models. Same issues.

The realization hit me: it wasn't the models themselves that were broken. It was the homogeneity of the team. When you have two agents powered by the exact same underlying foundation model, they act like siblings who share the same blind spots, the same training biases, and the same agreeable nature. They were terrible at policing each other because they were stuck in an AI echo chamber!

Multi-model magic

I had a hunch: because the agents were essentially siblings with the same underlying strengths and weaknesses, they were terrible at policing each other. To test the theory, I shook up the architecture. I bound Slate (our Architect) to Claude, and kept Kite (our Engineer) on Gemini.

And then? The magic happened. ✨⭐✨

The code reviews suddenly grew teeth. Here is how the new workflow played out:

• Real Pushback: Kite would code something up, and Slate would open issues—and actually keep them open until Kite explicitly fixed the underlying logic.
• Elevated Execution: Knowing that Slate wasn't going to let things slide, Kite became much more meticulous. The resulting code was excellent.

Watching the counterbalancing between these two distinct models play out in the Bridge Deck was incredible. In just a few days, PhrasePulse evolved from a fragile, hardcoded prototype into a bulletproof, well-functioning app.

The takeaway

This is why model diversity is an absolute game-changer. Different models have different training distributions, alignment weights, and inherent quirks. By pitting them against each other in a review cycle, you avoid getting stuck in a single model's logical rut. It’s the AI equivalent of bringing cognitive diversity to your engineering team!

Try it yourself & build your own Bridge Deck

If you want to experience this multi-model magic firsthand, you don't have to start from scratch. I've open-sourced the local app I built so you can spin up your own arena for agentic collaboration.

You can download the Bridge Deck project on GitHub here: https://g.dev/ai/bridge-deck-project.

Drop in your favorite models, set some strict architectural boundaries, and let the ruthless code reviews begin!