How Google keeps automated code review worth reading

When an automated reviewer is often wrong, how do you keep its findings worth reading?

Google runs many automated checks on every code review, and anyone can mark a finding as not useful. Checks that annoy people get fixed or switched off. I’ll study how that system, Tricorder, keeps the noise down, then spend a week building a triage step for AI reviewers.

Format: Teardown
What I’ll build: A triage step that sorts each review finding by whether it quotes the code it’s about or only describes what the code might do, folds minor ones away, and marks where two reviewers found the same thing on their own.
What I’ll reuse: A finding triage that shows a person only the review comments worth their time, for any setup where AI assistants review each other’s code.
Used by: Bezl
Status: Planned · Nov 2026

What I’ll look at

How Tricorder decides a check is good enough to show, and what happens when people keep marking it not useful. How a finding is worded so someone can act on it straight away. And how findings that come with a fix are kept apart from ones that only point at a problem.

I’ll compare it with GitHub’s code scanning, where people dismiss an alert and say why.

My guess

I expect the biggest gain comes from showing less. A reviewer that’s right two times in three still wastes a lot of attention if every finding is shown the same way. Findings that quote the exact line are probably right far more often than ones that describe behaviour.

How I’ll prove it

I’ll take a set of real review findings that have already been checked by hand, run them through the triage, and compare what a person reads before and after: how many findings, and how many of those were real.

If triage can’t raise the share of real findings without hiding true ones, that’s a sign review findings shouldn’t sit in the main view at all.