Multi-Agent Systems for Code Review

Key facts, with sources

• Anthropic reported that a multi-agent research system using an Opus lead agent with Sonnet subagents outperformed a single-agent Opus baseline by 90.2 percent on its internal research eval. (ByteByteGo)
• Anthropic's multi-agent research system used about 15x more tokens than a normal chat interaction, and token usage alone explained roughly 80 percent of performance variance. (The AI Engineer)
• The MAST research taxonomy identified 14 distinct failure modes across 7 popular multi-agent frameworks including AutoGen, ChatDev, and CrewAI, grouped into system design flaws, inter-agent misalignment, and task verification failures. (arXiv)
• Salesforce research found organizations run an average of 12 AI agents and projects multi-agent adoption to surge 67 percent within two years as enterprises move toward orchestration. (Salesforce)
• Multi-agent orchestration with three or more agents represents about 22 percent of enterprise agent deployments in 2026, projected to reach roughly 45 to 50 percent by 2027. (OnAbout AI)

Why one reviewer prompt plateaus

A single 'review this code' prompt asks one context to hold competing objectives simultaneously: hunt injection flaws, verify logic, spot N+1 queries, judge naming. Attention is a budget, and style observations spend it — the review comes back with eight naming suggestions and misses the authorization check that a focused security pass would have caught. I see this plateau in nearly every single-prompt reviewer I audit: decent breadth, unreliable depth.

The structural problem is tuning. When the reviewer is one prompt, you cannot make it stricter about security without it also becoming noisier about style — every adjustment moves everything. Splitting into specialists turns one untunable dial into several independent ones, and independent dials are what let you drive false positives down category by category.

The specialist lineup and their rubrics

My standard fan-out is three reviewers. Security: input handling, authorization gaps, secret exposure, unsafe deserialization, injection. Correctness: logic errors, unhandled edge cases, race conditions, broken error paths. Performance: N+1 query patterns, needless allocations in hot paths, blocking calls in async code. Maintainability I usually fold into correctness with a high bar, because it is the noisiest category and the one most likely to get the bot muted.

The most valuable line in each rubric is the negative space: an explicit list of what not to report. The security reviewer is told to ignore style entirely; the performance reviewer is told to skip anything outside a hot path. Without the exclusions, every specialist slowly reverts to being a general reviewer, and you have rebuilt the mega-prompt three times over at triple the cost.

Parallel fan-out in a few lines

The specialists share no state and read the same diff, so they run concurrently — total latency is the slowest reviewer, not the sum. Each returns findings in a fixed JSON shape: file, line, quoted code, severity, and the finding text. The structured shape is what makes the next stage — synthesis, dedup, mechanical verification — possible at all.

For large diffs I chunk by file with shared PR context and fan out per chunk, but the skeleton stays this simple.

import asyncio
from anthropic import AsyncAnthropic

MODEL = "claude-sonnet-latest"  # replace with the latest Claude model id
client = AsyncAnthropic()

REVIEWERS = {
    "security": "Review this diff for security issues only: injection, "
                "authorization gaps, secret exposure, unsafe deserialization. "
                "Ignore style and performance entirely.",
    "correctness": "Review this diff for logic bugs, unhandled edge cases, "
                   "and race conditions only. Ignore style and performance.",
    "performance": "Review this diff for N+1 queries, needless allocations in "
                   "hot paths, and blocking calls in async code. Ignore all else.",
}

FORMAT = (
    'Return only JSON: [{"file": str, "line": int, "quote": str, '
    '"severity": "high"|"medium"|"low", "finding": str}]'
)

async def review_diff(diff: str) -> dict[str, str]:
    async def run(name: str, rubric: str) -> tuple[str, str]:
        resp = await client.messages.create(
            model=MODEL,
            max_tokens=2000,
            system=f"{rubric}\n{FORMAT}",
            messages=[{"role": "user", "content": diff}],
        )
        return name, resp.content[0].text

    results = await asyncio.gather(*(run(n, r) for n, r in REVIEWERS.items()))
    return dict(results)

Synthesis is where the quality actually happens

Raw specialist output is not a review — it is three overlapping lists with duplicates and noise. The synthesis agent merges findings that reference the same lines, keeping the sharper phrasing; boosts confidence when independent specialists flagged the same code, which is a genuinely strong signal; drops findings below a severity-confidence threshold; and enforces a hard cap on total findings per review.

The cap is the piece teams resist and the piece that matters most. A review with thirty comments gets skimmed; a review with six well-chosen ones gets acted on. I would rather silently discard eight true-but-trivial findings than train developers that the bot is noise. Synthesis is also where tone gets normalized — findings phrased as observations with evidence, never directives — which sounds cosmetic and measurably affects whether humans engage with the output.

Grounding, calibration, and living in CI

Every finding must quote code that actually appears in the diff, and I verify that with a plain string match before anything posts — no model involved. This one mechanical check eliminates the majority of hallucinated findings, which otherwise destroy trust faster than any other failure. Findings that cite unchanged code or nonexistent lines get logged and dropped.

Calibration is a feedback loop: track which findings humans act on versus dismiss, per category, and adjust thresholds accordingly — dismissal-heavy categories get stricter floors, and a persistent false-positive pattern earns an explicit exclusion in the responsible specialist's rubric. In CI, I post one consolidated comment rather than per-line spam, gate the expensive review behind a label or size threshold to control cost, and let it fail open: a broken reviewer should never block a merge.

When to hire senior help

Multi-agent orchestration is one of the least commoditized skills in AI engineering, and teams that succeed usually include someone who has debugged coordination failures in production. Get senior review before committing to an orchestrator-worker design, because architectural mistakes at this layer are expensive to unwind after launch. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships AI — Multi-Agent Architectures projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Defaulting to multi-agent when a single agent with good tools would do, since the roughly 15x token multiplier only pays off when subtasks are genuinely parallel and high value
• ✕Letting subagents share full conversation history instead of scoped task briefs, causing context bloat, contradictory actions, and coordination failures
• ✕Shipping without a verification layer, so errors propagate through agent chains unchecked; task verification failures are one of the three MAST failure categories
• ✕Skipping per-agent trace observability, which makes it impossible to identify which agent in the chain caused a bad final output

Frequently asked questions

Sources

• ByteByteGo
• The AI Engineer
• arXiv
• Salesforce
• OnAbout AI