DEV Community

Cover image for Two AI models that attack each other beat one that agrees with itself
Mirza Iqbal
Mirza Iqbal

Posted on

Two AI models that attack each other beat one that agrees with itself

Two AI models that attack each other beat one that agrees with itself

Four times I asked the same question.

Four times I got a confident answer. All four were wrong.

Not vague. Not hedged. Each one arrived with the tone of something settled, and each one was produced the same way, by the same reasoning, looking in the same place.

We solved this exact problem in software a long time ago. Code review exists because one pair of eyes misses things. A pull request exists so somebody who did not write the change is the one who reads it.

Then we started asking a machine to check its own work, and quietly dropped the entire principle.

You have probably done what I did next. Reworded the question. Started a fresh session. Turned the thinking effort up. Asked it to double check itself.

None of that helps, and I took an embarrassingly long time to understand why.

Running it twice is one eye used twice

When your model answers the same way twice, that feels like corroboration. Nothing about it is.

You are watching the same failure arrive a second time, wearing the confidence of agreement.

A model has a shape to how it searches, what it treats as evidence, what it forgets to check. Run it again and you get that same shape back. If the blind spot caused the first wrong answer, the blind spot causes the second one, and now two answers match and you believe them more.

Four attempts sharing one blind spot is one eye used four times.

So the fix had nothing to do with better questions. What I needed was a different pair of eyes, from a model trained differently, failing differently.

Two tools that had never spoken to each other

I already had both installed. Most of us do in 2026.

They sat on the same machine for months, doing separate work, never once checking each other. Two capable colleagues in the same building who had never been introduced.

So I introduced them, and set one rule that changed everything about how useful this is.

Ask the other model to refute. Never to review.

That distinction sounds small and carries the whole thing. A reviewer looks for agreement, and models are agreeable by construction. Ask one to review and you get "this looks solid, here are two small suggestions". Ask one to find where the reasoning breaks, and to default to broken when uncertain, and you get something you can actually use.

First time I ran it properly, the answer came back in a single line and took apart something I had been quietly proud of for a week.

Making it fire without me

Here is the awkward truth about self-checking. The moment you most need a second opinion is exactly the moment you are least likely to ask for one, because you are confident.

I was never going to remember to invoke this while being wrong. Nobody is.

So the trigger runs on my frustration instead of my judgement.

When I am irritated, or repeating myself, or typing the same complaint in capital letters, that pattern is a reliable tell that the machine is confidently off and I have noticed before it has. Those moments now demand a cross-model check before any further answer. Two of them in one session and the check stops being optional.

I want to be honest that this catches the problem late. The trigger fires after the damage, never before it. Anyone selling you frustration detection as prevention is selling you something. The loop shortens from four wrong answers down to one, which is worth having, and the first wrong answer still lands.

What makes a naive second opinion worthless

Here is the part I would have missed entirely, found only because I turned the method on itself.

I described the setup to the rival model and asked it to attack the design. That attack found something real.

When the first model writes the summary that the second model reviews, the first model launders its own error. The summary frames the problem defensively. Out goes the exact output that broke. In comes a slightly softer question, one the first model is more comfortable answering. You get agreement, and the agreement is worthless, because the real question was never asked.

So the handoff carries the unedited original. The exact broken output, word for word. The exact correction, word for word. What correct would concretely look like. No summaries anywhere in that chain.

That single change separates a second opinion from a rubber stamp, and I would not have found it without asking the tool to attack the thing that consults the tool.

What nine rounds actually looked like

One day. Nine cross-model consultations. Seven of them ended with me being corrected.

Seven. On my own work, in my own domain, where I was confident enough to have shipped without asking.

Three of the things it caught.

I proposed a guard that would inspect written code for a layout problem. Reading source text cannot compute what a screen actually renders, so the guard would fire on healthy code, miss real breakage, and get switched off inside a week. Correct on every count. I rebuilt it to check something a machine can genuinely verify.

I proposed measuring a screenshot to find a display bug. Its answer pointed out that the thing being measured already knows its own dimensions exactly, so inferring them from pixels throws away precision I already had. Correct again.

And when I asked it to attack the consultation system itself, it opened with "it mostly fails" and then explained why, accurately, on two of four counts.

A tool willing to tell you your idea mostly fails is worth more than one telling you it looks solid.

Corrections that repeat become permanent

Every round gets logged. Agreed, disagreed, corrected.

The log has one purpose. A pattern needs enough rounds before its shape becomes visible.

When the other model corrects me twice on the same class of thing, bad luck stops being the explanation. That is a blind spot with a shape, and it graduates into a permanent check that runs whether or not I remember to ask.

There is the compounding part. One correction fixes one mistake. A correction that repeats builds something catching the next twenty.

What this is honestly worth

This will not stop you being wrong. Nothing does.

What it shortens is how long you stay wrong, and it makes the expensive kind of wrong, the confident kind that ships to a client, much rarer.

The cost is a habit and a little humility. You have to be willing to hear a rival tool say no about work you were proud of, then agree with it out loud rather than quietly picking your own answer.

If two of these tools already sit on your machine doing separate work, you are one rule away from a real check. Ask the other one to attack. Give it the raw evidence, never your version of events. Reconcile in the open, including when you lose.

Mine has told me I was wrong seven times today.

Best day it has ever given me.

Your turn

When did an AI last tell you no.

If this was useful

I work through this in public, the wins and the freezes both, mostly on LinkedIn and YouTube. If the real version of building in the open is useful to you, that is where it lives. Find me on X, GitHub, and the work at next8n.com.

Top comments (1)

Collapse
 
ggle_in profile image
HARD IN SOFT OUT

I read your post and immediately felt like someone had just published the missing chapter of my own experiment. I spent weeks running two models against each other, measuring phi correlations, and watching the numbers shift from +0.42 to -0.80. And then you come along and put it into words that actually make sense to a human being instead of a statistics textbook. I am honestly a little annoyed I did not write this part myself.

The "laundering" point is the one I did not catch in my own work, and it is genuinely the most valuable insight here. In my experiment, I handed the raw output from Model A to Model B, because I was measuring statistical independence and I needed clean data. But I never stopped to think about what would happen if someone summarized first. The fact that the first model frames the question defensively, and the second model just agrees with the framing, is the exact mechanism that breaks the whole adversarial setup. Now I know why it worked when I did it, and why it would fail if I did it sloppily.

Also, the "seven corrections in one day" line made me laugh out loud—mostly because I have been there, and the first time it happened I genuinely questioned my entire career. There is something humbling about asking a tool to refute your work and having it actually find the cracks, especially when you were confident enough to ship without asking. My experiment gave me the numbers, but your post gave me the permission to admit that it happens more often than I want to acknowledge.

One question for you: have you tried measuring the correlation before and after switching from "review" to "refute"? I would be curious to see if the numbers line up with what I found (phi goes from +0.42 to -0.80). My bet is you would see a similar drop, but I would love to know if your experience matches.

Anyway, this is the perfect companion piece to the statistical work. You gave it a pulse, and I just gave it a spreadsheet. Great writing.