25  Bringing Code Review to Claude Code

Originally published March 9, 2026.

25.1 The Code Review Problem

Code review is universally acknowledged as essential and universally practiced inconsistently. Every engineering team says they value thorough reviews. In practice, most PRs get a quick scan — a glance at the diff, a “looks good to me,” and a merge. The deeper issues — subtle bugs, security vulnerabilities, architectural concerns, missing edge cases — go uncaught.

The numbers at Anthropic told a stark story. Before automating code review, only 16% of pull requests received what could be called a “substantive review” — one that included meaningful comments beyond formatting or approval. The rest received cursory attention or none at all.

This wasn’t because engineers didn’t care. It was because thorough code review is hard, time-consuming work, and engineers are stretched thin. The PR that lands at 4 PM when you’re already context-switching between three tasks is not going to get your best attention.

Code Review in Claude Code changes the equation by dispatching a team of agents on every PR.

25.2 How It Works

When a pull request is opened (or updated), Claude Code’s Code Review feature automatically dispatches a team of specialized agents to analyze it. Each agent focuses on a different aspect of the review:

Pull Request Opened
        │
        ▼
┌───────────────────────────────────────┐
│         Code Review Orchestrator      │
└───────────┬───────────────────────────┘
            │
   ┌────────┼────────┬────────┬────────┐
   ▼        ▼        ▼        ▼        ▼
┌──────┐┌──────┐┌──────┐┌──────┐┌──────┐
│Bug   ││Secu- ││Test  ││Arch- ││Perf  │
│Detec-││rity  ││Cov-  ││itec- ││orm-  │
│tion  ││Review││erage ││ture  ││ance  │
└──────┘└──────┘└──────┘└──────┘└──────┘
   │        │        │        │        │
   └────────┴────────┴────────┴────────┘
            │
            ▼
┌───────────────────────────────────────┐
│        Synthesized Review             │
│  Comments posted to PR                │
└───────────────────────────────────────┘

25.2.1 Specialized Agents

Agent Focus Area What It Checks
Bug Detection Logic errors Off-by-one errors, null references, race conditions, incorrect conditionals
Security Review Vulnerabilities SQL injection, XSS, authentication bypasses, secret exposure
Test Coverage Test quality Missing tests for new code, edge case coverage, test correctness
Architecture Design API consistency, separation of concerns, coupling, naming conventions
Performance Efficiency N+1 queries, unnecessary allocations, blocking I/O, memory leaks

Each agent has its own context window and tool access. The Bug Detection agent reads the diff and runs the affected tests. The Security Review agent checks against vulnerability databases. The Architecture agent understands the project’s conventions from CLAUDE.md files.

25.2.2 Multi-Agent Coordination

The agents work in parallel but coordinate through the orchestrator:

  1. Context gathering: All agents read the PR diff, affected files, and related code
  2. Parallel analysis: Each agent performs its specialized review
  3. Finding synthesis: The orchestrator collects all findings
  4. Deduplication: Overlapping findings are merged
  5. Prioritization: Findings are ranked by severity
  6. Comment posting: Results are posted as structured PR comments
# Simplified orchestration logic
async def review_pr(pr_number: int):
    diff = await get_pr_diff(pr_number)
    context = await gather_context(diff)

    # Dispatch specialized agents in parallel
    findings = await asyncio.gather(
        bug_agent.analyze(diff, context),
        security_agent.analyze(diff, context),
        test_agent.analyze(diff, context),
        architecture_agent.analyze(diff, context),
        performance_agent.analyze(diff, context),
    )

    # Synthesize and post
    review = synthesize_review(findings)
    await post_review(pr_number, review)

25.3 The Results

25.3.1 Review Coverage

The most dramatic improvement was in review coverage:

Metric Before (Human Only) After (Claude Code Review)
PRs with substantive review 16% 54%
Average comments per PR 0.8 3.2
Critical bugs caught pre-merge ~30% ~75%
Security issues caught pre-merge ~20% ~68%

The jump from 16% to 54% represents a fundamental shift. More than half of all PRs now receive meaningful, substantive review — up from one in six.

Note

The 54% figure represents PRs where the review resulted in at least one actionable comment that led to a code change. It doesn’t count reviews where the agent found nothing — which is also valuable, as it provides confidence that the PR was actually examined.

25.3.2 Reviews Scale with PR Size

Human review quality degrades as PR size increases. A 50-line PR gets careful attention; a 500-line PR gets a scan; a 2000-line PR gets a shrug. Agent review quality is more consistent:

PR Size (lines changed) Human Review Quality Agent Review Quality
1-50 High High
51-200 Medium High
201-500 Low Medium-High
501-1000 Very Low Medium
1000+ Minimal Medium

Agents don’t get tired. They don’t skim. They don’t miss a buried security issue on line 847 because they stopped reading carefully at line 400.

25.3.3 Review Time and Cost

Metric Value
Average review time ~20 minutes
Reviews running in parallel Up to 5 agents
Cost per review ~$15-25
Reviews that find critical issues ~12%

The cost of $15-25 per review is significant, but it should be compared against the cost of bugs that reach production. A single production incident — pager fatigue, customer impact, engineering time for hotfix — typically costs thousands of dollars. If Code Review prevents even one such incident per 100 PRs, it pays for itself many times over.

25.4 What the Reviews Look Like

Code Review posts structured comments on the PR. Each comment includes:

  • Severity: Critical, warning, suggestion, or nitpick
  • Category: Bug, security, test, architecture, or performance
  • Location: Specific lines in the diff
  • Description: What the issue is and why it matters
  • Suggestion: Proposed fix (often with code)
## 🔴 Critical: SQL Injection Vulnerability

**File:** `src/db/queries.py:142`
**Category:** Security

The `user_input` variable is interpolated directly into
the SQL query without parameterization:

```python
# Current (vulnerable)
query = f"SELECT * FROM users WHERE name = '{user_input}'"

# Suggested fix
query = "SELECT * FROM users WHERE name = %s"
cursor.execute(query, (user_input,))

This allows SQL injection if user_input contains malicious SQL. Use parameterized queries instead.

25.4.1 Warning Example

## 🟡 Warning: Missing Error Handling

**File:** `src/api/handlers.py:87`
**Category:** Bug

The `fetch_user` call has no error handling. If the
database is unavailable, this will raise an unhandled
exception and return a 500 error to the client.

```python
# Suggested: wrap in try/except
try:
    user = await fetch_user(user_id)
except DatabaseError:
    raise HTTPException(status_code=503, detail="Service unavailable")

```markdown
## 🔵 Suggestion: Extract Helper Function

**File:** `src/utils/format.py:23-45`
**Category:** Architecture

This 22-line block for date formatting is duplicated
from `src/utils/dates.py:12`. Consider importing the
existing `format_date` function instead.

25.5 How Teams Use It

25.5.1 Anthropic’s Own Usage

Code Review runs on nearly every PR at Anthropic. The typical workflow:

  1. Engineer opens PR
  2. Code Review runs automatically (takes ~20 minutes)
  3. Agent posts comments on the PR
  4. Engineer reviews comments and addresses issues
  5. If critical issues found: engineer fixes before requesting human review
  6. Human reviewer focuses on high-level design and business logic, knowing that bugs, security, and tests have already been checked

This workflow means human reviewers spend their time on what humans do best: evaluating trade-offs, understanding business requirements, and assessing architectural fit. The mechanical, tedious parts of review are handled by agents.

25.5.2 Configuration

Teams can configure Code Review through their project’s CLAUDE.md:

# .claude/code-review.yml
review:
  enabled: true
  triggers:
    - pull_request.opened
    - pull_request.updated
  
  agents:
    - bug-detection
    - security
    - test-coverage
    - architecture
    - performance
  
  # Exclude certain paths from review
  exclude:
    - "vendor/**"
    - "**/*.generated.go"
    - "docs/**"
  
  # Severity thresholds for blocking
  block_on:
    - severity: critical
    - severity: warning
      category: security
  
  notifications:
    slack_channel: "#code-reviews"

25.5.3 Tiered Review Strategy

Some teams use a tiered approach:

Tier When It Runs What It Checks
Quick On every push Bugs, security, obvious issues
Standard On PR open All agent types, full analysis
Deep On PR ready for review Standard + historical context, dependency analysis 
review:
  tiers:
    quick:
      trigger: push
      agents: [bug-detection, security]
      timeout: 300  # 5 minutes
    
    standard:
      trigger: pull_request.opened
      agents: [bug-detection, security, test-coverage, architecture, performance]
      timeout: 1800  # 30 minutes
    
    deep:
      trigger: pull_request.ready_for_review
      agents: [all]
      timeout: 3600  # 60 minutes
      include_history: true

25.6 Availability

Code Review is available for Team and Enterprise plans. The feature requires:

  • A connected GitHub (or GitLab) repository
  • Claude Code configured in the repository
  • Sufficient usage allocation for the team
Tip

If you’re on a Team or Enterprise plan and not using Code Review, you’re leaving significant quality and security improvements on the table. Enable it on a single repository first, monitor the results for a week, and then roll out across your codebase.

25.7 Limitations and Honest Assessment

Code Review is powerful, but it’s not perfect. Understanding its limitations helps set realistic expectations:

25.7.1 What It’s Great At

  • Catching common bugs: Off-by-one errors, null references, incorrect types
  • Security scanning: Known vulnerability patterns, injection risks
  • Test coverage gaps: Identifying untested code paths
  • Consistency checks: Naming, formatting, pattern adherence

25.7.2 What It Struggles With

  • Business logic correctness: Whether the code does the right thing for the business
  • Cross-repository impacts: Effects on other services that depend on this code
  • Nuanced architectural decisions: When trade-offs are genuinely ambiguous
  • Performance in context: Whether a “slow” pattern is actually a problem given the usage pattern

25.7.3 The Human + Agent Balance

The best results come from combining agent and human review:

Review Aspect Best Done By
Bug detection Agent
Security scanning Agent
Test coverage Agent
Pattern consistency Agent
Business correctness Human
Architecture decisions Human
User experience impact Human
Cross-service effects Human

25.8 Measuring ROI

Teams adopting Code Review should measure its impact to justify the cost and identify areas for improvement. Key metrics to track:

Metric Why It Matters How to Measure
Review coverage % of PRs getting substantive review Count PRs with actionable comments / total PRs
Pre-merge bug catch rate Bugs caught before vs. after merge Track bugs found in review vs. in production
Mean time to review How long reviews take Time from PR open to review complete
Review cost Cost per review Track token usage per review
Human review time saved Productivity gain Survey: hours saved per week
PR merge time Time from open to merge Track before and after adoption 
# Example: Tracking review metrics
metrics = {
    "period": "2026-Q3",
    "total_prs": 342,
    "reviewed_prs": 185,  # 54% coverage
    "avg_review_time_min": 19,
    "avg_cost_per_review": 18.50,
    "bugs_caught_pre_merge": 47,
    "bugs_in_production": 8,  # Down from 24 pre-adoption
    "estimated_cost_savings": "Bug prevention alone saved ~$180K",
}
Note

The ROI calculation should include both direct savings (bugs prevented, review time saved) and indirect benefits (faster PR merges, improved code quality culture, developer satisfaction). Most teams find that preventing even one production incident per quarter justifies the entire Code Review cost.

25.9 Key Takeaways

  • Code Review dispatches a team of specialized agents — bug detection, security, test coverage, architecture, performance — on every pull request.
  • Review coverage jumped from 16% to 54% of PRs receiving substantive review at Anthropic.
  • Reviews scale with PR size — agents don’t degrade on large PRs the way humans do.
  • Average review takes ~20 minutes and costs ~$15-25 per review.
  • Available for Team and Enterprise plans, configurable per repository.
  • Reviews include severity, category, description, and suggested fixes posted as structured PR comments.
  • Human reviewers should focus on business logic, architecture, and trade-offs — the things agents can’t assess — while agents handle bugs, security, and test coverage.
  • Code Review runs on nearly every PR at Anthropic, demonstrating production-grade reliability at scale.