A reviewer subagent returns fourteen findings on a change you have good reason to believe is sound. Reading through, most are style preferences and edge cases that cannot occur. What should you do?

The principle — a review's output is shaped by its brief, so a noisy review is usually a brief problem rather than a code problem.

Why the key is correct — Anthropic states both halves. The cause: a reviewer prompted to find gaps will usually report some, even when the work is sound, because that is what it was asked to do. The fix, in the same guidance, is to tell the reviewer to flag only gaps that affect correctness or the stated requirements, and treat the rest as optional. That is a change to the instruction, applied before the next pass — not a triage exercise afterwards.

Why the others are wrong — closing all fourteen is the failure mode the page names outright: chasing every finding leads to over-engineering, with extra abstraction layers, defensive code, and tests for cases that cannot happen. Reading fourteen findings as strictness mistakes the count for a verdict, when the count is what the brief requested. And a reviewer being unbiased is a statement about how it judges, not a guarantee that everything it raises matters; the honest reviewer asked for gaps still returns gaps.

Remember this — when a reviewer floods you, change what you asked for, and let correctness decide what counts as a gap.

Sources — Anthropic's Claude Code best practices.