The person who wrote the check is the worst person to break it

You write a gate. Something that refuses bad input: a validator, a lint, a policy check. Then you do the responsible thing and try to break it. You sit down and write a list of hostile inputs, you run them, and the gate holds. You ship it feeling reasonably good.

Someone else looks at it a week later and walks through it in an afternoon.

This has a specific cause and it is not that you were lazy. You attacked the gate with a model of the gate that you built while writing it, and that model is missing exactly the things the gate is missing. The blind spot is shared, because it is the same blind spot.

You test the rule you were thinking about

When you write a check, you hold a mental picture of what a bad input looks like. The code implements that picture. Then you write attacks, and the attacks come from the same picture, so they explore the space the code already covers.

The inputs that break the gate live outside that picture by definition. They are not harder versions of the cases you thought of. They are cases you did not think of, which means no amount of effort spent generating variations of your own ideas will reach them. Trying harder makes the list longer, not wider.

The tests inherit the blind spot too

The uncomfortable part is that the test suite does not save you, because you wrote that as well. A suite written by the author protects the author’s model of the rule rather than the rule. It goes green, and green is read as coverage.

So the attack has to reach the test, not only the code. A useful question is not “can I get bad input past this check” but “can I write something that passes the check and also passes the suite that is supposed to prove the check works”. A construct that does both is telling you the suite is decorative in that region.

The version of this that costs the most is a check that never runs at all. The suite asserts what the output should be, the output happens to match for an unrelated reason, and the assertion passes without the code under test ever executing. A green test proves the assertion held. It does not prove the code ran. Those are separate claims and they need separate assertions.

What actually works is unglamorous

Hand the gate to someone who has not read the implementation. Give them the rule in plain words, the interface, and permission to be adversarial. Do not give them the source.

The reason this works is not that the second person is smarter. It is that their mental picture of the rule was built from the description rather than from the code, so it disagrees with the code in places, and every disagreement is a candidate. They are not searching a space you already covered.

A reviewer who reads your implementation first loses most of this. Once you have seen how something works, you start reasoning about whether the code does what it appears to intend, which is a different and much weaker question than whether the rule holds.

One attacker is not enough

Two people attacking the same gate from the same angle will find overlapping problems and miss the same class of thing together. A blind spot that comes from a shared angle is structural, and adding more people at that angle does not shrink it.

What helps is deliberately different surfaces. One person reasons about the decision logic: what the rule says, where it is ambiguous, what falls between its cases. Another reasons about the boundary the code sits on: encoding, whitespace, path handling, what the shell or the filesystem does to a string on its way in. These two find almost disjoint sets of problems, and neither set is a subset of the other.

There is a corollary that is easy to skip. When an attack finds a real defect and you fix it, the fix has been applied in one place. The same defect very likely exists in the sibling module that was written the same week by the same person holding the same assumption. A fix is not finished until someone has looked for it somewhere it was never made.

The cost

This is slower and it is socially awkward. You are asking someone to spend real time trying to make your work look bad, and you are declining to explain your design to them, which feels like withholding.

The trade is that the alternative is not “no attack”. The alternative is that the gate gets attacked later by real input, in production, and the report arrives as damage rather than as a list. The list is cheaper every time.