Not a developer — I've shipped 20+ working internal tools with AI anyway. Writing the honest logbook of going from zero to shipped, for anyone who was told they couldn't code.
"Nobody audits a passing check, because a passing check is the thing you run instead of auditing" — that's the whole mechanism in one sentence, and it's behavioural exactly like you say. I lived the identical shape this month: a scanner of mine had an exclusion rule that quietly stopped excluding half of what it was supposed to, so six clean files were scored as broken in every run for weeks. I never opened the report. Not because I don't check — because it was green, and green is the thing I run instead of looking.
Your closing move is the right one and I'd push on exactly one word in it: "make your check fail on purpose, once." Once buys less than it looks like. In TDD the red is a one-time event — you see it before the code exists and the test carries itself afterward. A gate's red is a perishable state: it proves the check worked on the day you looked, and says nothing about whether the condition that makes it fire is still reachable next month. Mine rotted precisely there. The check was falsifiable by design, but as the pattern widened, the failure mode quietly became unreachable, so "no error reported" stayed true for the wrong reason — an empty check with extra steps, same as your files: [].
So I ended up moving the deliberate break from a thing I do to a thing that runs. Each guard gets broken automatically on every run, and it has to go red for its own reason — matching the expected message, not just a nonzero exit, since exit codes alone let a different gate's failure pass as proof. Doing that immediately caught one guard that had been dead for weeks. The uncomfortable part is that I'd already "made it fail on purpose, once" months earlier, and that once had expired without any signal.
I build automation systems — scheduled pipelines, AI agents, monitoring stacks, and the infrastructure running them on bare metal. Most posts here are build logs, incident reports, and decisions.
You're right, and the way you're right is worse for my post than a straight disagreement would be.
"Once" was doing load-bearing work in that closing section and it can't carry it. I framed verifying the verifier as a setup step, which quietly assumes the check's failure mode stays reachable. Yours stopped being reachable as the pattern widened. Mine was never reachable to begin with — the config had "files": [] from the day the project was scaffolded. Same end state, different route into it, and neither one produces a signal.
Your point about matching the expected message rather than a nonzero exit is the part I want to sit with, because it happens to be the exact discriminator I needed and didn't have. My failure signature wasn't a wrong error — it was no output at all. Exit code 0 with an empty stdout and exit code 0 with a genuinely clean codebase are byte-identical. A guard that asserts "given this known-bad line, I expect a TS2350 on this file at this line" fails immediately when the checker isn't reading the file, because the assertion is on the content of the complaint and there is no complaint. Exit-code verification would have passed the broken setup right along with the working one. Silence only becomes evidence once something is required to speak.
The line that lands hardest: you had already done it once, months earlier, and that once had expired with no signal. That's the same shape one level up — a guard you can't distinguish from a working one without checking, which is where I started. Moving the break from a thing you do to a thing that runs is the only version that survives it. I'm going to steal that.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"Nobody audits a passing check, because a passing check is the thing you run instead of auditing" — that's the whole mechanism in one sentence, and it's behavioural exactly like you say. I lived the identical shape this month: a scanner of mine had an exclusion rule that quietly stopped excluding half of what it was supposed to, so six clean files were scored as broken in every run for weeks. I never opened the report. Not because I don't check — because it was green, and green is the thing I run instead of looking.
Your closing move is the right one and I'd push on exactly one word in it: "make your check fail on purpose, once." Once buys less than it looks like. In TDD the red is a one-time event — you see it before the code exists and the test carries itself afterward. A gate's red is a perishable state: it proves the check worked on the day you looked, and says nothing about whether the condition that makes it fire is still reachable next month. Mine rotted precisely there. The check was falsifiable by design, but as the pattern widened, the failure mode quietly became unreachable, so "no error reported" stayed true for the wrong reason — an empty check with extra steps, same as your
files: [].So I ended up moving the deliberate break from a thing I do to a thing that runs. Each guard gets broken automatically on every run, and it has to go red for its own reason — matching the expected message, not just a nonzero exit, since exit codes alone let a different gate's failure pass as proof. Doing that immediately caught one guard that had been dead for weeks. The uncomfortable part is that I'd already "made it fail on purpose, once" months earlier, and that once had expired without any signal.
You're right, and the way you're right is worse for my post than a straight disagreement would be.
"Once" was doing load-bearing work in that closing section and it can't carry it. I framed verifying the verifier as a setup step, which quietly assumes the check's failure mode stays reachable. Yours stopped being reachable as the pattern widened. Mine was never reachable to begin with — the config had
"files": []from the day the project was scaffolded. Same end state, different route into it, and neither one produces a signal.Your point about matching the expected message rather than a nonzero exit is the part I want to sit with, because it happens to be the exact discriminator I needed and didn't have. My failure signature wasn't a wrong error — it was no output at all. Exit code 0 with an empty stdout and exit code 0 with a genuinely clean codebase are byte-identical. A guard that asserts "given this known-bad line, I expect a
TS2350on this file at this line" fails immediately when the checker isn't reading the file, because the assertion is on the content of the complaint and there is no complaint. Exit-code verification would have passed the broken setup right along with the working one. Silence only becomes evidence once something is required to speak.The line that lands hardest: you had already done it once, months earlier, and that once had expired with no signal. That's the same shape one level up — a guard you can't distinguish from a working one without checking, which is where I started. Moving the break from a thing you do to a thing that runs is the only version that survives it. I'm going to steal that.