Why does detekt's autoCorrect option leave most findings unfixed in a Gradle build?

## What autoCorrect actually is detekt's Gradle extension exposes `autoCorrect` as a boolean (`--auto-correct` on the command line). It is a *permission*, not a capability: it tells the run that rules which know how to rewrite code are allowed to do so. Each rule carries an auto-correct flag internally; a rule that has no correction logic simply ignores the permission and reports as usual. That is why teams are surprised. Setting the flag and re-running produces a build that is still red, with `MagicNumber`, `LongMethod` and friends untouched, and the natural conclusion — "autoCorrect is broken" — is wrong. ## Why most detekt rules cannot correct Think about what a correction would mean for each rule. `LongMethod` fires because a function is doing too much; the fix is a decomposition that requires knowing which parts belong together. `MagicNumber` fires because a literal has no name; the fix requires choosing that name. `SwallowedException` fires because an error was discarded; the fix requires deciding what should happen instead. `CyclomaticComplexMethod` fires because control flow is dense; the fix is a redesign. Every one of those is a judgment. A tool that guessed would produce a diff nobody could review and would sometimes be wrong in ways that compile. detekt deliberately does not guess: rules whose findings need a human decision only report. ## Which rules can correct The correctable population is dominated by formatting rules, which arrive through the optional `detekt-formatting` artifact added to the `detektPlugins` Gradle configuration. Those rules wrap ktlint's implementations, and whitespace, indentation, trailing commas and import ordering are exactly the class of problem where the correct output is uniquely determined — there is nothing to decide, so rewriting is safe. A small number of built-in rules also support correction, but the practical answer in an interview is: formatting corrects, analysis reports. ## Wiring it up The plugin and the extra rules must be on the same version, and the extra rule set has to be declared as a `detektPlugins` dependency rather than a normal `implementation` one, since it is loaded into the detekt run, not into your application. Version note: detekt 1.x publishes the Gradle plugin as `io.gitlab.arturbosch.detekt`, while detekt 2.0 moves it to `dev.detekt` — the extension property itself is spelled `autoCorrect` in both. ## The CI hazard A correcting run **writes to your source tree**. That has two consequences worth stating unprompted. First, never enable it on the task CI uses to verify the build. If the checked-out sources are modified during verification, the pipeline is no longer testing the commit under review, and the fixes evaporate when the agent's workspace is discarded — the same violation returns on the next run. Verification tasks must be read-only. Second, put correction where a human sees the diff: a local Gradle invocation, a pre-commit hook, or an explicit "format" task developers run on purpose. The reviewable artefact is then a committed change, not an invisible mutation. ## What to expect after a correcting run The run still reports. Findings it fixed are addressed on disk; findings it could not fix remain, and the task fails on them exactly as before. So the healthy interpretation of "I enabled autoCorrect and the build is still red" is simply that the remaining findings were never in the automatable class — which is the majority of what detekt exists to tell you.