Claude Code Review in Production: How Our Review Rules Evolved Over Five Months
Description and use
Claude‑based code review evolved from a single prompt to a playbook with six specialist agents and a verifier, eliminating false positives, reviewing only changed lines, and ensuring every finding cites a rule.
Problem
Automated code review produced false positives, reviewed unchanged code, and lacked rule citations, leading to noisy feedback and blocking legitimate changes.
Outcome
The evolved workflow reduced false positives, prevented reviews of legacy code, ensured every finding cited a rule, and introduced a verifier to drop unprovable findings, improving trust and precision.
Workflow
- Listen for PR events or @claude comment
- Load only rule documents relevant to changed file paths
- Review only added or modified lines
- Assign severity based on rule type (BLOCKING, WARNING, SUGGESTION)
- Route each file to its specialist reviewer
- Collect findings in fixed format
- Verifier checks file existence, code quote proximity, diff inclusion, and rule validity
- Post findings as inline comments and GitHub review (request changes if any BLOCKING)
Evidence
Claude Code review started at my company as a single prompt in a GitHub workflow, and five months later it is a playbook, six specialist agents and a verifier that throws out any finding it cannot prove.
The next rewrite introduced three ideas that are still the backbone of the system.
The verifier is the Claude Code review agent I would copy first. For every finding it checks four things, and rejects the finding if any fails: ... false positives are far worse than false negatives
- Record date: 2026-10-09T03:40:56.824Z