Bots found the contact form on this site and started filling it with junk. I had Claude Code write a small server-side filter: spot the machine-generated gibberish in a submission and drop it before it reaches me. Claude wrote the code. Claude wrote the tests. Every test passed, and the change looked done.
The takeaway: A model reviewing its own work shares its own blind spots — and so do the tests it writes. Running the change through Impasse, an independent cross-provider review, surfaced two false-positive bugs — each able to silently discard a real sales lead — that the green test suite never touched. Verification has to come from outside the author.
Before I shipped it, I ran the change through Impasse, an open-source Claude Code skill I built. It hands finished work to an independent reviewer running on a model from a different company, tells that reviewer to attack the work and back every claim with evidence, checks each finding against the actual code, and surfaces only what survives. It came back with two findings. Both were real, and both were the same kind: false positives, the worst kind of bug a lead-capture form can have.
The catch
The first bug: a legitimate role someone might enter in the form would have been thrown out as junk. The second: some real customer names would have been rejected outright. In both cases the person on the other end would have seen nothing wrong — a normal success message — and I would have received no notification at all. The form's one job is to capture leads, and it would have quietly dropped them on the floor. I fixed both the same afternoon and added a test for each.
Nothing crashed. No test failed. No alert fired. The most expensive software bugs rarely announce themselves; they pass every check and quietly cost you something you never watch leave.
Why the green tests missed it
The tests passed because they were written from the same understanding of the problem that produced the bug. Claude wrote the filter and the tests in one sitting, working from one mental picture of what "gibberish" looks like — and you cannot write a test for an input you never imagined. That is the reason code review exists at all: the author, human or machine, is the worst-placed person to catch the assumption they didn't know they were making. The blind spot that writes the bug also writes the test that misses it.
Why an independent reviewer, not just a second model
The obvious move is to ask a second AI, "is this good?" That mostly buys you agreement. Models are trained to be helpful, two of them will talk each other into a shared mistake, and a model asked to bless the work usually blesses it. Point the same model at its own output and you get the original blind spot back, now wearing a second opinion that shares it.
Impasse is built to avoid that. The reviewer runs on a model from a different company — trained on different data by a different team, so it fails in different places. It is told to refute, not review: its job is to find what's wrong, and every finding has to carry evidence — a specific line, a rule, a case that breaks. Impasse then checks each finding against the real code, reconciles the two models, and escalates only the disagreements that genuinely need a human. The independence comes from using a different lab; the usefulness comes from the discipline around it. A raw model on its own — including the exact one Impasse used here — could have missed these two bugs completely if I had only asked it to take a look.
What makes it work is a reviewer that shares none of your blind spots, forced to argue with evidence, with a human kept in the loop for the calls that are genuinely his to make. A bigger model would not have bought me that.
What I'm deliberately not publishing
One thing I'm leaving out: exactly how the filter decides what counts as junk. Publishing that rule would hand the bots an evasion guide. The categories of bug are safe to describe — false positives that reject real people. The mechanism that catches the spam is not.
Older Than AI
The code was mostly right, written in minutes, and shipped the day it was reviewed. The lesson is older than AI: a single author cannot audit their own work, because the same mind that made the error is the one deciding whether an error was made. Independent verification has to come from outside — true of engineering organizations, financial controls, and scientific peer review long before it was true of language models.
Impasse applies that discipline to code, but the pattern isn't specific to code. I've pointed it at business decisions, essays, and research claims, and written about why the disagreements matter more than the agreement. If you build with AI, a reviewer that shares none of its assumptions is worth more than another increment of raw capability — and it's the one thing another copy of the same model can never give you.
AI Workshop for CEOs
Wiring an independent check into how your team ships AI-built work — and knowing which disagreements deserve your attention — is the kind of operating discipline the workshop builds with your team. Three hours live with a group of eight CEOs, plus a 1-on-1 to fit it to how your work actually gets done.
Reserve Your Seat →