Take the worked example the post uses: a nine-dependency ViewModel with an empty `catch` block sitting in `main` right now [10]. `LongParameterList` ships with `constructorThreshold` set to 7 [13]. Nine constructor arguments is two over a line detekt already draws [2], and `SwallowedException` is active by default as well [7]. Neither rule needs the compiler's type information; the author singles out `UnsafeCallOnNullableType` as the one default-on rule that does [8][1]. That class in `main` is evidence that a correctly configured file-scoped tool either produced a finding nobody acted on or never ran, rather than evidence that file-scoped tools are blind.
Which is why the four explanations matter more than the rule list, and only one of them is about rule coverage: a Gradle task no pipeline calls, a `detekt-baseline.xml` entry, an unread report, or a pipeline invoking `detekt` rather than `detektMain` [10]. The report is produced either way. Opening it is not a Gradle task.
The cross-file half of the argument survives that. Patterns 1, 5 and 8, in the post's numbering, share a shape: the file is internally fine and the violation is its relationship to a decision made elsewhere, so the check needs the whole source tree as its input [16]. Tightening a per-file threshold does not reach those, which is the basis for the claim that adding more local rules buys you almost nothing [4]. Tightening still buys something for the file-local ones: moving `LargeClass` from the default 600 lines to 250 removes 350 lines of allowance [12][13][3], and the shipped default was never an encoding of any team's review standard [12].
What would have to be true for the framing to transfer to your repo. The claim is that an assistant makes local mistakes far less often than a tired human and instead emits code that is defensible in the file you are looking at and wrong only against a decision made somewhere else [2], so there is no line to underline and the review passes [3]. The post argues that from a pattern list sorted by which level catches each item [16], not from measured defect counts [20]. It also assumes the defects themselves are old, and that what changed is the rate plus the level of tool required [5][6]. Both of those are plausible and neither is quantified here.
The cost asymmetry is the part I would act on. Level 1 needs no new tool and no new CI step: read the baseline, confirm you are on a task that does type resolution, and set thresholds that match what the team would actually accept [15]. Everything above it, by the post's own ordering, costs more to stand up [16]. On this evidence the cheap gate has to be shown to fire before the expensive one is worth buying, because a tightened threshold in a config no pipeline reads changes nothing but the diff.
