Here's a habit worth building: whenever one AI assistant produces something that matters, have the other one check it. Not as a rubber stamp, but as a genuine review, done cold, by an assistant that never saw the conversation that produced the work. It catches things. Reliably. And it costs you almost nothing.
The reason it works is the same reason human code review works, and it has nothing to do with the reviewer being smarter. The reviewer simply has no attachment to the work and no memory of the reasoning that led to it. The assistant that wrote something is, in a loose sense, committed to it. It built a line of thinking and the output sits at the end of that line. A second assistant, handed just the result, has no such commitment. It reads what's actually there, not what was meant.
Fresh eyes beat clever eyes
When you write something yourself, you read what you intended. Your eyes slide over the gap between what you meant and what you actually wrote, because your brain helpfully fills it in. AI assistants have a version of the same problem. Inside a long conversation, the assumptions pile up, and the assistant carries all of them forward, including the wrong ones.
Strip that away and things change. Hand the output to a fresh assistant with none of that history, and it evaluates what's in front of it on its own terms. It doesn't know what you meant, so it can only respond to what you said. That's precisely the value. The gap between intent and result is where bugs live, and a cold reviewer stands right on top of it.
This is why I don't just ask the same assistant "are you sure?" A tired reviewer and a tired author sharing the same context give you one viewpoint asked twice, not two. The fresh context is the whole point.
How to run the check
The mechanics are simple, and a couple of details matter.
- Give it the output and the goal, not the chat. Paste in what was produced and a plain statement of what it was meant to achieve. Don't hand over the original conversation, because that just re-imports the assumptions you were trying to escape.
- Ask it to find problems, not to approve. "Is this fine?" invites a yes. "What's wrong with this, where could it fail, what did the author likely overlook?" invites actual scrutiny. Frame the job as fault-finding.
- Read the review as evidence, not a verdict. The reviewer will sometimes flag things that are fine and miss things that aren't. You're still the judge. The review is input to your decision, not a replacement for it.
I used this constantly while building htmlEdit, my visual editor for AI-generated HTML documents. When one assistant produced a chunk of logic I couldn't fully vouch for, I'd hand it to the other cold and ask what was wrong with it. Often the answer was "nothing obvious," which was reassuring. Sometimes it was a specific, real problem the first assistant had glided straight past. Either way, I knew more than I did before.
It doesn't replace understanding
One caution, because it's easy to over-trust this. A cross-check is not permission to stop understanding the work yourself. If both assistants are confidently wrong about the same thing, and that happens, the review will sail through and you'll merge a mistake with two approvals attached. That's arguably worse than one, because it feels safe.
So treat the cross-check as one layer, not the whole defence. It pairs with the discipline I keep coming back to: never merge what you don't understand, which I've written about in lessons from shipping htmlEdit. The review sharpens your understanding; it doesn't substitute for it. When the reviewer flags something, the real value comes next: you now have to go and understand whether the flag is right, and in doing so you understand the work.
Used that way, it's one of the highest-return habits I've picked up. Two assistants, one building and one checking, with you holding the final say. Simple, cheap, and it catches the errors that would otherwise catch you.