The Wrong Answer That Proved More
Nobody found the division bug in the original Pentium by running division and watching it come back right. Correct answers, run a billion times, tell you the chip can divide. They tell you nothing about how.
What found the bug was the opposite: a set of divisions that came back wrong, and wrong in a way that repeated. Feed the chip certain divisor patterns and the result would be off, not randomly, but by a consistent small amount, always in roughly the same decimal place, only for inputs that hit a particular bit pattern. That specificity is what let engineers trace it. The flaw turned out to live in a lookup table at the core of the division circuit, a handful of entries out of around a thousand that were simply wrong. The failure had a shape, and the shape pointed at exactly one place.
Compare that to what a pass tells you. A correct answer is consistent with every circuit design, every lookup table, every rounding convention that could in principle produce a correct answer, which is most of them. Testing a chip by checking that division works is really testing "is there at least one mechanism in here that gets this right," and the space of mechanisms that clear that bar is enormous. You learn that the thing functions. You learn almost nothing about what it's doing inside.
A wrong answer collapses that space, but only if the wrongness is structured. Random noise is as uninformative as success, maybe more so, because it's consistent with sloppy construction, environmental interference, a dozen unrelated failure modes. The informative failure is the one that's right in structure and wrong in one specific way, every time, for a specific class of input. That kind of wrongness has a signature, and a signature usually traces back to a single cause rather than a family of them.
The same thing turns up in work trying to figure out what a neural network is doing by inspecting its weights instead of running it. Ask a weight-reading model to guess which shape a generative model draws, and getting the shape right proves little, there are plenty of ways to encode "draws a circle." But when it gets the shape right and the fill wrong, calling every shape an outline when the real outputs are solid, that one specific miss is worth more than a hundred correct guesses. It rules out almost everything except the one story that would produce exactly that mistake: something reading the geometry of an output layer's weight directions and inferring edges from where they concentrate, never actually simulating the computation. A success there is compatible with memorization, pattern-matching, lucky correlation, or genuine understanding of the mechanism. One wrong answer, wrong in that particular way, is compatible with almost none of those.
This is backwards from how most testing gets framed. Pass/fail is built for the question "does it work," and for that question a pass is the goal and a fail is waste. But the moment the real question becomes "how does it work," the value flips. A pass stops being an answer and becomes a non-event, the system cleared a bar that thousands of different internal designs could also clear. A fail, if it's the right kind of fail, becomes the only data point in the pile that actually discriminates between candidate mechanisms.
It's why debugging by exhaustive correct cases is close to useless and debugging by the one case that's almost right is where the actual work happens. It's why a diagnostic test that's negative across the board tells a doctor less than a result that's normal on every marker but one. It's why an interviewer watching someone solve a problem correctly learns less about how they think than watching them hit a wrong turn and seeing exactly which turn it was.
Correctness is cheap to produce and expensive to interpret. A specific kind of wrongness is the opposite: hard to produce on purpose, but once you have it, you're not left guessing which of a hundred mechanisms you're looking at. You're looking at one.