Agent-Assisted Code Review · ~7 min

The Committee Pattern

One big "find the bugs" prompt has one blind spot. Several narrow reviewers, run in parallel, have different ones — and that difference is the whole point.

A committee review routes a diff through multiple specialized reviewer agents in parallel — each evaluating a single dimension (correctness, security, test coverage) — then an orchestrator aggregates the verdicts and either accepts the output or routes feedback back to the implementer to revise.

1 Three roles, not one prompt

The pattern has exactly three roles, and the separation between the first two is what removes bias:

• Implementer — produces the initial output (code, document, plan).
• Reviewer panel — several agents, each scoped to a single review dimension.
• Orchestrator — runs reviewers in parallel, aggregates verdicts, routes feedback back to the implementer.

Each reviewer returns structured output — JSON with a verdict and an issue list — so the orchestrator can triage programmatically instead of parsing prose. The mechanism behind the gain is attentional narrowing plus role-induced perspective: research on LLM peer-review simulation (EMNLP 2024) shows distinct reviewer personas reliably shift which defects they surface, so a security-scoped reviewer activates different reasoning than a correctness one on the same diff.

2 Why diversity beats one big prompt

Run the scoped reviewers in parallel and their error populations are largely non-overlapping. That is the load-bearing claim: the committee catches defects any single reviewer would miss precisely because the reviewers fail in different places.

Each reviewer should carry a single-focus system prompt, a structured output schema, and explicit pass criteria — what counts as PASS must be unambiguous. Crucially, give each reviewer only the diff, not the other reviewers' verdicts, so opinions stay independent. Focus the prompts on bugs, security, and logic; the Anvil agent deliberately excludes style from its review prompts to reduce noise.

3 Aggregate, scale by risk, and bound the loop

The orchestrator waits for all verdicts before aggregating. If any reviewer returns FAIL, the merged issue list goes back to the implementer to revise. Two controls keep the pattern from becoming a tax:

Scale the panel to risk. Reviewer count is not fixed — it tracks how much a change can hurt. File-level risk classification drives automatic escalation: a change to auth or data-deletion code triggers the high tier regardless of task scope.

Bound the loop. Set a maximum round limit — two to three rounds covers most cases. If the implementer cannot satisfy all reviewers within the limit, escalate to human review. Unresolved loops signal an underspecified task or conflicting reviewer criteria, not a stubborn bug.

4 The cloud variant: fan-out, verify, aggregate

The committee's iteration loop has a cloud cousin that swaps the accept/revise loop for a single posted artifact. Claude Code's /ultrareview launches "a fleet of reviewer agents in a remote sandbox" (ultrareview docs); Anthropic's managed GitHub Code Review runs the same shape as a webhook service. Multiple agents fan out over defect classes, then a step that is the whole difference:

Then the orchestrator deduplicates surviving findings, ranks by severity, and posts one review with inline comments. The trade-offs are concrete: /ultrareview takes 5–10 minutes and typically costs $5–$20; managed Code Review averages ~20 minutes and $15–25, scaling with PR size and how many findings need verification. Cost scales with PR size and trigger mode, so push-triggered review on a long-running PR is the primary budget risk — use manual or once-per-PR triggers there. Tune severity, skip rules, and nit caps in REVIEW.md, which is injected into every agent in the pipeline as highest priority.