Claude Code now offers pull-request review through multiple agents. Each agent searches for a different class of problem, including logic defects, vulnerabilities, edge cases, and regressions. A verification stage then checks candidates against actual code behavior to filter false positives. Findings appear as severity-tagged inline comments without approving or blocking the pull request.
The design addresses a predictable bottleneck. Coding agents increase change volume faster than a team expands review capacity. Adding automation to the review queue seems inevitable. The risk is confusing more analysis with a better decision.
Parallel reviewers create value when they observe the same contract. Without local rules, they multiply plausible interpretations.
Different perspectives need a shared baseline
Separating security, logic, and regression reduces the chance that one reviewer fixates on the first issue found. Diversity helps on large diffs where an authentication change may affect authorization, caching, and events at once.
Specialization also creates overlap. Two agents may describe the same cause at different levels or point to separate symptoms of one defect. Verification and deduplication are central parts of the product. Without them, the author receives a long list and the bottleneck moves from discovery to triage.
The repository must provide enough context for decisions. Code Review reads CLAUDE.md as general project guidance and accepts a high-priority REVIEW.md for review-specific rules. That file can define what deserves a comment, which severity applies, and which conventions belong to the project.
Cost should be compared with an accepted result
The service charges based on usage, and reviewing every push costs more than manual runs. Comparing that amount only with human reading time produces an incomplete calculation. The operational question is the cost of moving a pull request into an accepted state.
An automated review can find a defect early and save investigation, rollback, or incident work. It can also generate irrelevant comments that consume senior attention. A useful indicator combines cost, accepted findings, time to merge, and problems that escaped.
High-volume repositories can begin in manual mode. @claude review once runs one analysis without subscribing later pushes. Teams can select higher-risk pull requests, measure usefulness, and refine rules before automating the entire queue.
Review should not repeat deterministic checks
Linting, formatting, types, and deterministic tests belong in CI. Spending inference to rediscover what a local tool identifies precisely adds cost and noise. Agent review should focus on relationships that require context: a permission enforced on one route and omitted on another, a state that violates a domain rule, or a locally correct change that breaks the full workflow.
REVIEW.md can exclude areas already covered and record recurring false positives. It should also name high-risk invariants. "Every query must filter by tenant" is more testable than "review security." "Billing operations require idempotency" connects local code to a concrete consequence.
Too many rules recreate overload. A large file competes with the diff and ages quickly. A few invariants based on real defects carry more signal than a generic best-practices manual.
Human review moves to another stage
Automation does not remove responsibility for the merge. It moves some work from initial searching to evaluating findings. A person still confirms whether a scenario is possible, whether severity is accurate, and whether the proposed repair preserves other constraints.
The process needs a clear interface. AI comments should not automatically carry the same weight as a failed deterministic test. The documentation says Code Review neither approves nor blocks pull requests. Each team decides which categories become gates and which remain a second opinion.
Authorship also matters. When one agent writes code and another reviews it with similar models and context, both may share blind spots. Independent tests, observability, and domain review remain necessary where errors are expensive.
A pilot can answer the right question
Choose a small set of repositories and record four things for several weeks: cost per review, accepted comments, triage time, and defects found after merge. Separate human-written pull requests from changes produced with heavy agent assistance because their volume and error profile may differ.
Then adjust triggers. Review on every push may fit low-frequency changes or high-risk code. Manual mode may serve busy repositories better. Draft pull requests may need a single review before becoming ready, avoiding repeated spending on the same incomplete structure.
Code Review expands the capacity to search for problems. Quality appears when the team limits the search, verifies findings, and measures whether the queue ends in a better state. More agents without one shared standard produce more opinions about the same diff.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
