How we cut PR review time by 40% with Claude Code subagents

Six months ago our engineering team had a problem: PRs sitting for days in review. Not because reviewers didn't care — but because reviewers had their own work, and the review load fell mostly on the same three senior engineers. Everyone was waiting for those three.

We started using a Claude Code pr-reviewer subagent to pre-review PRs before they hit a human. Six months in, we've measured the results. This post has the numbers, the setup, and — importantly — the parts that didn't work.

The problem in numbers

Before adopting the subagent, our baseline (March 2026):

• Average time to first human review: 18 hours
• Average time to merge: 3.2 days
• Percentage of PRs with review issues: 62% (needed at least one round of changes)
• Senior engineer time spent on review: ~8 hours/week each

The bottleneck was clear: senior engineers were the only ones doing meaningful reviews, and there weren't enough of them. Junior engineers reviewed each other but weren't catching the architectural issues that mattered. PRs went "reviewed" but then got kicked back later when a senior noticed something.

The setup

The intervention: every PR gets pre-reviewed by a pr-reviewer subagent before a human looks at it. The subagent reads the diff, considers the changes against project conventions, and produces a review comment covering:

• Architectural concerns (does this fit our patterns?)
• Test coverage (are the new code paths tested?)
• Security implications (auth, input validation, secret handling)
• Performance concerns (n+1 queries, memory, hot paths)
• Documentation gaps (public API changes without docs)
• Style/convention issues (only ones that matter — no bikeshedding on formatting)

The subagent posts its review as a comment on the PR. Human reviewers still look at every PR, but with the subagent's pre-review as context. The result: humans focus on judgment calls the AI can't make, and skip re-checking the mechanical stuff.

name: pr-reviewer
description: Reviews a PR against project conventions before human review
model: claude-opus-4-6
allowed-tools: Bash(gh:*), Read, Grep, Glob

The system prompt (the body of the .md file) is longer — about 40 lines. Key ingredients: (1) read CLAUDE.md first for team conventions, (2) look at 2-3 recent merged PRs to understand what "good" looks like here, (3) categorize concerns by severity (blocker / important / nit), (4) explicitly skip formatting and style debates.

The measurement (after 6 months)

August 2026 data, same team, same codebase:

• Average time to first human review: 4 hours (was 18h — down 78%)
• Average time to merge: 1.9 days (was 3.2d — down 41%)
• Percentage of PRs with review issues: 71% (was 62% — went up)
• Senior engineer time on review: ~3 hours/week each (was 8h — down 63%)

The counterintuitive result: more PRs needed changes, but merge time still dropped. The subagent catches things authors miss (missing tests, subtle security issues). Those things now get fixed pre-merge instead of post-deploy. That's a huge win even though it looks like "more issues found." The real metric is "issues that reached production" — which dropped significantly.

What worked

A few patterns that made this work:

1. The subagent runs on every PR, not on demand. Nobody remembers to invoke it. Making it automatic (via a GitHub Action that runs when a PR is opened) means it just happens. Set-and-forget beats "I'll remember."
2. Human reviewers stayed on every PR. The subagent didn't replace human review. Anyone who tries to skip the human review because "the AI already looked" will hit trouble fast. AI catches what humans miss and vice versa.
3. The subagent reads CLAUDE.md first. Without team conventions, the review is generic. With conventions, it's targeted. We added a "PR review priorities" section to CLAUDE.md that lists what our team specifically cares about — this made review quality jump noticeably.
4. Explicit "skip formatting" instruction. Without this, the subagent would spend paragraphs on trivial style issues. Explicitly telling it to skip formatting frees it to focus on judgment.
5. Severity labels. "Blocker / important / nit" makes the human triage the AI's output fast. Blockers are 3-5 per week; the rest is often skippable.

What didn't work

Being honest — a few things that were not wins:

1. Architectural reviews on large PRs. On a 50-file PR, the subagent's architectural feedback is generic ("consider extracting a service"). Real architectural review requires deep context the subagent doesn't have — history, roadmap, past discussions.
2. Security review beyond basics. The subagent catches obvious things (SQL injection, missing auth, exposed keys). Subtle security issues (broken invariants, race conditions in concurrent code) are still human-only territory.
3. "Why is this change needed?" questions. The subagent reviews what the code does, not whether it should exist. Business-value questions still need product/eng partnership.
4. Adoption took longer than expected. First month, reviewers ignored the subagent's comments. It took 2-3 weeks of the subagent consistently catching real issues before people started reading its comments seriously.

The methodology (what we did and didn't control for)

Honest limitations of these numbers:

Confounding factors: Over the 6 months we also (1) added an auto-format hook that eliminated most style debates, (2) hired 2 additional engineers, (3) changed how we scope PRs (smaller). Any of these might contribute to the improvements.

What we didn't measure: code quality of merged code. It's possible we're shipping slightly-worse code faster. We don't think so (bug rate is stable) but we're not measuring this rigorously.

Selection effects: Our team is comfortable with AI tools. A team more skeptical would take longer to adopt and see smaller gains.

That said, the trend is real. Even accounting for confounds, the subagent has clearly moved the needle on review turnaround. Would we go back? No.

How to set this up for your team

The specific tooling matters less than the pattern. If you want to try this:

1. Install pr-reviewer subagent. Via cctk (cctk add --agent pr-reviewer) or build your own — the config is documented here.
2. Add PR review priorities to CLAUDE.md. What does your team specifically care about in review? Security? Test coverage? Architectural fit? Write it down.
3. Set up automatic invocation. GitHub Actions on PR open. Or your CI system's equivalent. Don't leave it to memory.
4. Give it a month of adjustment. Reviewers will ignore it initially. Track when they start acting on its comments — that's the leading indicator.
5. Measure the right thing. Not "PRs merged faster" (misleading — could mean quality dropped). Measure "issues caught pre-merge" and "time-to-first-human-review."

The full pr-reviewer subagent config, including the system prompt we use, is available here. Everything mentioned in this post is in cctk's catalog. Steal what works.