Volver a los artículos
engineering2 min de lectura

Before a bug report ships, someone tries to prove it isn't real

Why adversarial verification catches what a single confident finding misses

Rob Vasquez·

AI-assisted code review finds a lot of real problems fast. It also produces a specific failure mode that took me a while to notice: a finding that reads as confident and specific, cites the right file and line, and is simply wrong. Not malicious, not lazy, just a plausible-sounding conclusion that doesn't survive contact with the actual code path.

The fix I landed on isn't a better prompt. It's a second pass whose only job is to disprove the first one.

Here's the shape of it. One reviewer finds a candidate bug and writes it up with a concrete failure scenario: these inputs, this state, this observable break. Before that finding ships anywhere, a second, independent reviewer gets the same finding and one instruction: try to refute it. Not confirm it, not polish the writeup, refute it. Find the guard clause that already handles this. Find the test that already covers it. Prove the failure scenario can't actually happen.

Only findings that survive an honest refutation attempt make it to a human. The ones that get refuted are quietly dropped, and dropping most of them is the point, not a failure rate to optimize away.

The reason this works comes down to what each pass is actually good at. Finding an interesting-looking problem and building a case for it are the same skill, done by the same reasoning process, so a self-review just re-runs the same reasoning and confirms itself most of the time. Refuting a specific, concrete claim is a different task: you're not searching for problems anymore, you're checking one claim against the code as written. That asymmetry is what catches the plausible-but-wrong findings a single pass waves through.

The generalizable version of this: any process that generates confident-sounding output benefits from a second pass whose job is explicitly adversarial, not confirmatory. A reviewer told to "check this" tends to agree with what's already written. A reviewer told to "try to break this" finds the gaps the first pass couldn't see, because it wasn't looking for them.

I didn't get to skip human judgment either way. What changed is where a person's attention goes: instead of reading ten findings and deciding which ones to trust, I'm reading the two or three that already survived someone actively trying to kill them.

EngineeringLeadershipSoftwareEngineeringTechnicalJudgmentCodeReview

¿Necesitas un camino práctico hacia la entrega habilitada por IA?

Comienza con una auditoría de preparación para IA de precio fijo y sal con una hoja de ruta concreta.

Ver la auditoría de preparación para IA