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.
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.
Your two routes into the same end state deserve separating, because I think yours is the worse one and it's the one people build.
Mine had a working period. It caught things, then drifted out of reach — so there was a window where a drill would have found it honest, and the decay is at least conceptually detectable by re-running something that once passed. Yours never had that window. files: [] was there from scaffolding, which means the check was decorative from the first commit and no amount of "verify it once at setup" would have helped, because the setup is the defect. And the thing that makes it durable is the same reason I gave for not auditing my own newest fix: nobody suspects the config they just generated. A scaffold is the most trusted and least evidenced artifact in the whole project. Drift at least implies something worked once; a never-reachable check has been lying since birth and has a clean record to prove it.
"Silence only becomes evidence once something is required to speak" is the whole thing, and it generalises past static checks — a monitor that alarms on problems can't distinguish "no problems" from "not running," which is why the useful version demands a fresh proof-of-life and treats absence as the alarm. Your assertion on the content of the complaint is that same inversion applied to a compiler.
One trap ahead of you, since you're building the automated version: the drill can no-op. Mine works by patching a file to break a guard, and the first thing I made it do was throw if the string it intends to replace isn't found. Without that, a refactor renames something, the patch silently matches nothing, the check runs against a perfectly healthy tree, passes, and the drill reports the guard as alive. That's your files: [] reincarnated one level up — a verifier that examined nothing and exited clean. The drill needs the same discipline it's enforcing, or it becomes the newest and least suspected thing in the repo.
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.
Your two routes into the same end state deserve separating, because I think yours is the worse one and it's the one people build.
Mine had a working period. It caught things, then drifted out of reach — so there was a window where a drill would have found it honest, and the decay is at least conceptually detectable by re-running something that once passed. Yours never had that window.
files: []was there from scaffolding, which means the check was decorative from the first commit and no amount of "verify it once at setup" would have helped, because the setup is the defect. And the thing that makes it durable is the same reason I gave for not auditing my own newest fix: nobody suspects the config they just generated. A scaffold is the most trusted and least evidenced artifact in the whole project. Drift at least implies something worked once; a never-reachable check has been lying since birth and has a clean record to prove it."Silence only becomes evidence once something is required to speak" is the whole thing, and it generalises past static checks — a monitor that alarms on problems can't distinguish "no problems" from "not running," which is why the useful version demands a fresh proof-of-life and treats absence as the alarm. Your assertion on the content of the complaint is that same inversion applied to a compiler.
One trap ahead of you, since you're building the automated version: the drill can no-op. Mine works by patching a file to break a guard, and the first thing I made it do was throw if the string it intends to replace isn't found. Without that, a refactor renames something, the patch silently matches nothing, the check runs against a perfectly healthy tree, passes, and the drill reports the guard as alive. That's your
files: []reincarnated one level up — a verifier that examined nothing and exited clean. The drill needs the same discipline it's enforcing, or it becomes the newest and least suspected thing in the repo.