No, not really. "false positives are the enemy" (or at least, in my alternative model, relevancy) becomes glaringly obvious for anyone who tried this at scale.

No, not really. "false positives are the enemy" (or at least, in my alternative model, relevancy) becomes glaringly obvious for anyone who tried this at scale. The question is how to reduce false positives (or improve relevancy). The part that "real defects not shown" exist is called unsoundness and pretty much everybody now agrees you should be unsound. (Or being sound is a different market.) Of course, this is not obvious to people who haven't tried, so it is reported over and over and over. The most recently, from Google. Lessons from Building Static Analysis Tools at Google (2018). https://cacm.acm.org/magazines/2018/4/226371-lessons-from-building-static-analysis-tools-at-google/fulltext https://cacm.acm.org/magazines/2018/4/226371-lessons-from-bu... I mean, I could have told them. Select quotes: > Unlike compile-time checks, analysis results shown during code review are allowed to include up to 10% effective false positives. IMPORTANT NOTE: 10% effective false positives means much less than 10% false positives! In above quote, Google defines true bugs marked as not-a-bug by a developer as effectively false positives. If what you say is true, but users misunderstand, it doesn't count.