Post · 23 October 2026
Two models walk into a codebase.
Why I have a second model review the first one’s work, and why its opinion still gets checked.
I think there’s a lot of value in using more than one model when building software. It’s easy to get comfortable with Claude or Codex and let that become your entire workflow, but for complex tasks, especially anything involving security, I want another opinion.
Even if models reach similar levels of capability, I don’t think that makes their opinions interchangeable. Different models have their own nuances, and having another one check the work can give you something useful to investigate.
My setup is simple. One model builds the change and a different model reviews it. Which one does which depends on the task.
Security is where this has paid off most. The reviewing model has picked up unsafe input handling that the model that built the change had missed. I wouldn’t have had that lead with one model, because the one that wrote the code had already decided it was fine.
- 1The changeCode and requirements
- 2Model A builds itWhichever fits the task
- 3Model B reviews itA different model, reading fresh
- 4The verdictFlags somethingA lead to investigateSays it’s fineStill gets checked
- 5Check itAgainst the code and the tests
- 6Fix what’s realThen verify again
A second opinion is still just an opinion, though. If the reviewer flags something, I check it against the code and the tests before I act on it. If both models agree the work is fine, that isn’t proof either, so I check that too. Agreement means two models made the same call. It doesn’t mean the call was right.
I wrote about this in Trust the tests, not the vibes: good verification takes you further than a good plan. A second model gives me more things to verify. The disagreements are the useful part, because one of the two is wrong and I have to find out which.