My most important test had never failed — because what it proved was 1 = 1

Read on: measuring the noise floor before trusting a delta · 繁體中文版

Do this first — it is uncomfortable and it takes five minutes

Pick the test or check script you have the most confidence in. Then break the thing it claims to protect, on purpose.

Not something adjacent. The actual load-bearing thing: make the function return null forever, push the threshold somewhere unreachable, empty the data source it reads.

If it stays green, what you own is not an acceptance check. It is a decoration — and it is worse than having nothing, because it is why you stopped worrying.

The setup

I keep a notebook of production potholes — a year and a bit of markdown files recording what broke and how I fixed it. The problem with a notebook is that it only helps when somebody thinks to open it, and the most expensive class of mistake is defined by nobody feeling any need to check: the wrong road is smooth the whole way down.

So I built a tool. Give it a task description, it surfaces the relevant potholes.

Its most important feature is the red-flag list — marking which entries are the ones that produce no signal at the moment you get them wrong. I wrote an acceptance check for it and called it, in the commit message, "the most important check in this tool":

The notebook declares 48 red flags → the tool must be able to display 48.

Reasonable, right? 48 against 48. If the numbers match, no red flag got dropped.

Then I handed it to a different model

I asked a model from a different lab to review it. (Different lab matters. Models from the same family share blind spots; three of them looking together is still one pair of eyes.)

The first thing it did was not read my code. It ran a mutation:

make the fuzzy-match function return null unconditionally
→ selftest still 14 passed, 0 failed
→ the reconciliation still reads "48 / 48 ✅"

I re-ran it myself. Reproduced exactly.

Why it could never go red

Unfolded, it's obvious:

// numerator: how many rows are flagged red in the notebook
const declared = rows.filter(r => r.flag === '🔴').length

// denominator: how many the tool can actually display
let shown = 0
for (const file of files) shown += computeRedFlags(file).length

And computeRedFlags is:

for (const row of rows) {
  if (row.flag !== '🔴') continue
  const hit = findSection(row)      // found → carries a line number
  allRed.push({ ...row, line: hit ? hit.line : null })   // pushed either way
}

It pushes every row unconditionally. Found gets a line number, not-found gets null — but both count as "can display."

So shown and declared are two spellings of the same filter. They are mathematically incapable of differing. I had not written an acceptance check. I had written 1 === 1.

And the failure mode is at its most toxic here: it was always green, and green is what stopped me looking.

I made the same shape of mistake three times in one day

First: the tautology above.

Second: I rewrote it as an end-to-end assertion — run a real query, check the output string contains the red flag and its line number:

say(out.includes('TRUNCATE') && out.includes(':257'))

Ran the mutation. Still green.

Because :257 was arriving from a different line of the output. My output has two sections: the red-flag list (affected by fuzzy matching) and "closest entries by literal match" (unaffected). With fuzzy matching broken, the red-flag line did lose its line number — and the section below printed :257 anyway.

I was asserting on "does this whole blob of output contain this substring", and the substring had two possible sources.

Third: while fixing the counting logic I found a bug (a last-wins map dropping two entries), fixed it in the main code — and then made the identical mistake inside the test itself.

What the working version looks like

Three things.

1. Bind the assertion to the load-bearing line, not to the whole output.

const redLine = out.split(/\r?\n/)
  .find(l => l.trimStart().startsWith('·') && l.includes(needle))
const ok = !!redLine && /`:\d+`/.test(redLine)

2. Do not bind to something that legitimately changes.

My first version asserted the line number equals 257. Then I added a few lines to the top of that file, it became 261, and the test went red.

That was not catching a defect. That was an assertion bound to something allowed to move. A guard that barks at legitimate change is as bad as one that never barks — both train you to ignore it.

Assert that there is a line number, not that it is a particular one. That still survives the mutation: fuzzy match broken → that row prints a cross-entry label → no line number → red.

3. Every check must name the mutation that turns it red.

I ended up labelling each assertion with the mutation it guards:

What I broke on purpose	Which check goes red
fuzzy match returns null forever	end-to-end #3 (16 pass / 1 fail)
put the if (!x.length) continue back	the P0 check (16 pass / 1 fail)
push the first-stage threshold to 9999	13 failures
delete the plain-language line in the file header	real-corpus 7/7 drops to 2/7 (19 pass / 5 fail)
change nothing	24 pass / 0 fail

A check whose red-making mutation you cannot name is a candidate tautology.

One more trap: a prove-it-goes-red run must control its input

Later the same day I wrote a sentinel monitoring whether the tool's zero-hit rate had gotten too high. To prove it fires, I appended 16 fake zero-hit records to the real log.

It did not go red.

The file already held 241 records from my own testing. The ratio moved from 46.9% to 49.0% — nowhere near the 70% threshold.

A prove-red stacked on real data gets diluted by the existing denominator. The right move is to lift the judgement into a pure function and feed it fully controlled input:

const mk = (n, zeros) => Array.from({length: n}, (_, i) => ({ hits: i < zeros ? 0 : 2 }))
// ★ red: 13 of 16 at zero hits (81%) → must exit 1
// ★ boundary: exactly 70% does not count as over → exit 0; 75% → exit 1

Why having the rule written down did not save me

The part that bothers me most: my project documentation already contained this rule, verbatim:

A thing that emits a green light must positively observe the load-bearing thing itself.

That day I quoted it, believed I had followed it, and then got the same shape wrong three times.

Written down, correctly placed, remembered — and still no help.

What did help was: a model from a different lab, breaking my code with mutation, and watching whether my check made a sound.

The lesson isn't "be more careful." It is:

"I feel confident about this check" carries no evidential weight whatsoever. The only thing that does is "I broke what it protects and it went red."

The one-minute version

1. Pick the check you trust most
2. Break the thing it claims to protect, on purpose
3. Still green → it is a decoration, fix it now
4. Then label each check with the mutation that makes it red
5. Bind assertions to the load-bearing line — not the whole output, not something allowed to change
6. Run prove-red on fully controlled input, never stacked on real data

By the way — after step 3 you may find more than one. I found three.

---

Originally published on my blog: My most important test had never failed — because what it proved was 1 = 1

I keep a running index of every pothole I've hit building a real production system solo — symptom on the left, what to grep in your own repo on the right: coffeeshooters.com/potholes

And if your team is shipping AI-written code faster than anyone can read it, that's the thing I do for a living: coffeeshooters.com/code-audit