Developers ignore a lint run that emits thousands of warnings - how do you make the ruleset trustworthy again?

### The failure being described A ruleset that produces more findings than anyone can act on does not produce zero value — it produces negative value. People learn, correctly, that the output is not worth reading, and that learned reflex applies to the one finding a year that would have mattered. Warning fatigue is not laziness; it is a rational response to a channel with a bad signal-to-noise ratio. So the fix is never "tell people to read the warnings". The fix is to make the channel worth reading. ### Attention is the budget Treat findings as spending from a fixed, shared attention budget. Every enabled rule buys a claim on that budget and must pay for it in defects prevented. This reframes the ruleset from a catalogue of everything the tool can check into a *curated set* where each rule has an owner and a justification. A rule that has never caught anything anyone cared about is not neutral; it is consuming the budget that the leak-detection rule needs. ### The three-state model, and why the middle state rots Most rule engines offer three states per rule: off, report as a warning, report as an error. The third state interrupts; the second does not. In practice the middle state is where rules go to die: a rule that has warned continuously for eighteen months has been decided against by the organisation, just never in writing. So force the decision. Each rule ends up either **off** (nobody is going to act on it, so stop printing it) or **enforced** (we mean it, and an occurrence stops the change). "Warning" survives only as a temporary, dated state while a rule is being measured — never as a resting place. Note that the severity you assign a rule and the technical severity of the defect it finds are different things: a rule that finds a low-impact issue with 99% precision may be worth enforcing, while a rule that finds a scary issue one time in ten is not. ### Measure precision before you argue about it Ruleset arguments run on anecdote unless you bring numbers. A concrete audit that finishes in an afternoon: take a run over the appointment scheduler — 4,317 findings from 63 enabled rules — and first sort by rule, not by file. Four rules produced 3,880 of the findings; the remaining 59 produced 437 between them. Sample 40 findings at random from each of the top rules, have two engineers independently classify each as "a thing we would change" or "not a thing we would change", and compute the rate. Now the conversation has evidence, and you can set an explicit budget: a rule may be enforced only if it is right in at least 92 of 100 sampled findings. Two of the four noisy rules came in near 12% and were deleted the same day; one came in at 96% and was promoted; the fourth was right almost always in application code and almost never in generated code. ### Scope before you disable That last case is the important one, because "the rule is noisy" and "the rule is wrong" are different diagnoses. Rulesets support per-path overrides: a base configuration for the repository, with narrower configurations layered over specific directories. Generated sources, vendored third-party code, database migration scripts and test fixtures each have legitimately different conventions, and a rule that is right about production code and wrong about generated code should be *narrowed*, not deleted. Keep the override list short and readable, though — a configuration with 40 path exceptions is its own kind of noise, and each exception should say why it exists rather than merely that it does. ### Volume matters independently of precision A rule that is right 92% of the time but fires 900 times has produced 72 wrong findings, which is 72 arguments and 72 chances to edit correct code. Precision and volume multiply. When a high-precision rule is simply loud, the right move is usually to narrow what it looks at rather than to accept the flood. ### What to say about evidence Be honest about the parts that are contested. Whether the density of static-analysis findings predicts defect density in a codebase has been studied repeatedly with mixed results, and the effect depends heavily on which rules are enabled. So do not claim that a lower warning count means better software. The defensible claim is narrower and stronger: a small, high-precision, enforced set changes behaviour, and a large unread set does not. ### The end state Under twenty enforced rules, each with a named owner and a one-line reason. Everything else off. Findings on a typical change in the low single digits, so the number is small enough that a person reads it rather than skims it. New rules enter in a measured, dated trial and leave it in one direction or the other. And the ruleset gets an explicit review on a cadence, because a rule that earned its slot two years ago may be checking for a mistake the current design makes impossible. ### The anti-pattern to name The other common response to a warning heap — disabling analysis entirely, or leaving it running with the build ignoring it — is worse than the heap, because it removes the one channel that catches the class of defect tests structurally miss: the wrong behaviour on the branch nobody exercised.