qualitylab

Feedback latency · Knowledge distribution

Put static analysis in the review, not in a backlog

tier III/cost to adopt: medium/active

Surfacing an analyser's finding inside the code review, against the lines it concerns, while the author still has the context, is what determines whether it gets acted on — and a false-positive rate above roughly a tenth destroys that regardless of how good the findings are.

Do this firstEvery change runs the suite before a human looks at it

The analyser is the easy part. Where its output lands is the control.

Two numbers make the case, and they point at the same thing. A tool sitting outside the review workflow went effectively unused. The same organisation, having moved analysis into the review UI with a one-click “not useful” button and a hard bar on false positives, saw sustained engagement and a measurable decline in the patterns it flagged.

The false-positive threshold is not a nicety. Above about 30% the reported dynamic is a vicious cycle: low trust causes real defects to be labelled false positives, which lowers trust further.

The decoy

A nightly analysis report with a dashboard. It finds the same defects and puts them somewhere nobody is standing, at a moment nobody is deciding anything. The measured version of this at Google was used by 35 developers in a year, 20 of them exactly once.

Evidence

Last reviewed 2026-08-19.