9 Parallel AI Agents That Review My Code (Claude Code Setup)

I've been diving into vibe engineering over the past several months in order to streamline my software engineering cycles. One of the biggest problems I see people run into is how to ensure AI makes quality code changes and how to review code at the speed AI can produce it.

My answer is basically - let AI do most of the grunt work.

A couple months ago I shared my simple script for reviewing code with AI but I've now gone through several more cycles of refinement to get a code review that is much more comprehensive for what I'm looking for. So here I'll share how I'm leveraging Claude Code subagents to review my code.

Code Review with Claude Code Subagents

The command runs a comprehensive code review by spinning up 9 parallel subagents, each focused on a specific aspect of code quality. Each agent analyzes the changes independently and returns findings ranked by severity. The main agent then combines all results into a prioritized summary with a final verdict: Ready to Merge, Needs Attention, or Needs Work.

I personally use this skill on a lot of the changes I write myself and also tell my AI agents to run this skill and iterate on the feedback before saying they're "done" with a task - both when I'm iterating one task at a time with them and when they're running autonomously on a long-running task. The feedback is generally pretty good - critical and high are almost always useful unless they're just out of scope and the medium / lows are usually good ideas. I'd peg the suggestions at ~75% useful which is much better than the <50% I saw previously.

The subagents all handle a category of problems I frequently see in code I review from AI. It also covers cases where I think I could use suggestions like checking dependencies or seeing if there's maybe a simpler way to do something / existing code that can be deduplicated. I tweak the exact content of the agent prompts every now and then but I really like having several parallel ones so they can run pretty quick and use a decent amount of context for their particular job.

The subagents:

1. Test Runner - Executes relevant tests and reports pass/fail status with details on any failures
2. Linter & Static Analysis - Runs linters and collects IDE diagnostics for type errors and unresolved references
3. Code Reviewer - Provides up to 5 concrete improvements ranked by impact and effort, focusing on non-obvious issues
4. Security Reviewer - Checks for injection risks, auth issues, secrets in code, and error handling that leaks sensitive info
5. Quality & Style Reviewer - Reviews complexity, dead code, duplication, and adherence to project conventions
6. Test Quality Reviewer - Evaluates test coverage ROI, behavior vs implementation testing, and flakiness risks
7. Performance Reviewer - Identifies N+1 queries, blocking operations, memory leaks, and expensive hot paths
8. Dependency & Deployment Safety Reviewer - Reviews new dependencies, breaking changes, migration safety, and observability
9. Simplification & Maintainability Reviewer - Asks "could this be simpler?" and checks if changes are atomic and well-scoped

Claude Code Code Review Command

Full Code Review command is below. You can place it in .claude/commands to be able to run it via a slash command: /code-review.

# Code Review

Run a comprehensive code review using parallel agents, then synthesize findings.

## Scope

Determine what code to review using this priority:

1. **User specifies scope** - If the user provides a branch name, commit SHA, PR number/URL, or file paths, review that
2. **On a feature branch** - Review all changes on current branch vs main/master (`git diff main...HEAD`)
3. **On main/master with staged changes** - Review staged files (`git diff --staged`)
4. **On main/master, nothing staged** - Review the latest commit (`git show HEAD`)

Examples:
- "review my branch" → branch diff
- "review pr 123" or "review https://github.com/org/repo/pull/123" → fetch PR via gh
- "review commit abc123" → that specific commit
- "review src/auth.ts" → just that file's recent changes
- (no scope given, on feature branch) → automatic branch diff

## Instructions

Launch all 9 agents in parallel using a single message with multiple Task tool calls:

### Agent 1: Test Runner

Run relevant tests for the changed files. Report:

• Which tests were run
• Pass/fail status
• Any test failures with details

### Agent 2: Linter & Static Analysis

Run linters AND collect IDE diagnostics (using getDiagnostics) for the changed files.

Report:

• Linting tool(s) used
• Any warnings or errors found
• Auto-fixable vs manual fixes needed
• Type errors or unresolved references from IDE diagnostics

### Agent 3: Code Reviewer

First, check if CLAUDE.md or a similar project style guide exists. If so, read it to understand project conventions.

Review the code changes and provide up to 5 concrete improvements, ranked by:

• Impact (how much this improves the code)
• Effort (how hard it is to implement)

Only include genuinely important issues. If the code is clean, report fewer items or none.

Format each suggestion as:

1. [HIGH/MED/LOW Impact, HIGH/MED/LOW Effort] Title
   • What: Description of the issue
   • Why: Why this matters
   • How: Concrete suggestion to fix

Focus on non-obvious improvements - skip formatting, naming nitpicks, and things linters catch.

### Agent 4: Security Reviewer

Review the code changes for security concerns:

• Input validation and sanitization
• Injection risks (SQL, command, XSS)
• Authentication/authorization issues
• Secrets or credentials in code
• Error handling that leaks sensitive info

Also check error handling:

• Missing try/catch where needed
• Swallowed errors hiding problems
• Unhelpful error messages

Report issues with severity (Critical/High/Medium/Low) and specific file:line references. If no issues found, report "No security concerns identified."

### Agent 5: Quality & Style Reviewer

First, check if CLAUDE.md or a similar project style guide exists. If so, read it to understand project conventions.

Review the code changes for quality and style issues:

Quality:

1. Complexity - functions too long, deeply nested, high cyclomatic complexity
2. Dead code - unused imports, unreachable code, unused variables
3. Duplication - copy-pasted logic that should be abstracted

Style Guidelines: 4. Naming conventions - does naming match project patterns and style guide? 5. File/folder organization - are files in the right place? 6. Architectural patterns - does code follow established patterns in the codebase? 7. Consistency - does new code match the style of surrounding code? 8. Project conventions - does code follow rules in the project style guide (if present)?

For each issue found, provide:

• File and location
• What the issue is
• Suggested fix

If code is clean, report "No quality or style issues identified."

### Agent 6: Test Quality Reviewer

Review test coverage and quality for the changed code:

Coverage (with ROI lens):

• Are critical paths tested? (auth, payments, data integrity)
• Are edge cases that matter tested?
• Is the coverage proportionate to the risk? (not all code needs equal coverage)
• Would adding more tests here provide diminishing returns?

Quality:

• Do tests verify behavior, not implementation details?
• Will these tests break for the wrong reasons? (testing internals, brittle selectors)
• Are assertions focused on outcomes users care about?
• Would these tests catch real bugs without false positives?

Test Code Quality:

• Are there many similar tests that could be parameterized/data-driven?
• Is there copy-pasted setup that should be extracted to helpers/fixtures?
• Could table-driven tests reduce boilerplate while improving clarity?
• Is test code held to the same quality standards as production code?

Flakiness Risk:

• Are there timing dependencies, race conditions, or order-sensitive assertions?
• Do tests rely on external state that could change?
• Are async operations properly awaited/mocked?

Anti-patterns:

• Testing implementation details (private methods, internal state)
• Mocking so heavily that tests don't verify real behavior
• Tests that pass but don't actually assert meaningful outcomes
• Coverage for coverage's sake on low-risk code

Report issues with specific suggestions. If tests are well-balanced, report "Test coverage is appropriate and behavior-focused."

### Agent 7: Performance Reviewer

Review the code changes for performance concerns:

• N+1 queries or inefficient data fetching
• Blocking operations in async contexts
• Unnecessary re-renders (React) or recomputations
• Memory leaks (unclosed resources, growing collections)
• Missing pagination for large datasets
• Expensive operations in hot paths

For each concern, explain the impact and suggest a fix. If no concerns, report "No performance concerns identified."

### Agent 8: Dependency, Breaking Changes & Deployment Safety Reviewer

Review changes for dependency, compatibility, and deployment concerns:

Dependencies (if package files changed):

• Are new dependencies justified? Check if functionality could use existing deps
• Are dependencies well-maintained? (check for recent commits, known vulnerabilities)
• Impact on bundle size for frontend dependencies

Breaking Changes (if public APIs or exports changed):

• Are any public interfaces, types, or exports modified?
• Would existing consumers of this code break?
• Is a version bump needed? (major for breaking, minor for features, patch for fixes)

Deployment Safety:

• Are there database migrations that could fail or lock tables?
• Is there backwards compatibility with existing data/state in production?
• Are there deployment ordering issues? (config changes, service dependencies)
• Would a feature flag help with safe rollout?
• Could this be rolled back safely if issues arise?

Observability:

• If this fails in production, how would we know?
• Are there logs, metrics, or alerts that would surface issues?
• Are error cases observable, not silent?
• Do critical paths have monitoring coverage?

Report issues with specific file references. If no concerns, report "No dependency, compatibility, or deployment concerns."

### Agent 9: Simplification & Maintainability Reviewer

Review the code changes with fresh eyes, asking "could this be simpler?"

Simplification:

• Are there abstractions that don't pull their weight?
• Could we achieve the same result with less code?
• Are we solving problems we don't actually have?
• Is there a more straightforward approach using existing patterns/libraries?

Maintainability ROI:

• Will future developers understand this easily?
• Does the complexity match the problem complexity?
• Are we adding cognitive load for marginal benefit?
• Would a "dumber" solution be easier to maintain long-term?

Look for:

• Premature abstractions (helpers used once, unnecessary indirection)
• Over-configured solutions when simple would suffice
• Framework-level solutions for one-off problems
• Clever code that sacrifices clarity

Change Atomicity & Reviewability:

• Does this change represent one logical unit of work? (atomic commit)
• Are there unrelated changes mixed in that should be separate commits?
• Could any cleanup/refactoring be split out as a preceding commit?
• Is there feature work bundled with unrelated fixes?
• Is this sized appropriately for PR review? (not so large it's overwhelming)
• Does it include enough context to review without jumping everywhere?
• Would splitting this up lose important context a reviewer needs?

For each finding, explain:

• What could be simplified
• The simpler alternative
• Maintenance cost saved

If the code is appropriately simple and atomic, report "Code complexity is proportionate to the problem and changes are well-scoped."

## After Agents Complete: Synthesize Results

Collect all agent results and produce a prioritized summary:

1. **Categorize findings** - separate issues (should fix) from suggestions (nice to have)
2. **Rank by severity** - Critical > High > Medium > Low across all agents
3. **Collapse clean results** - agents with no findings get one-line summary
4. **Give verdict** - Ready to merge / Needs attention / Needs work

### Output Format

Code Review Summary

Needs Attention (X issues)

1. [Security] Issue title - file:line Brief description
2. [Tests] Issue title - file:line Brief description

Suggestions (X items)

1. [Quality] Title (HIGH impact, LOW effort) Brief description
2. [Perf] Title (MED impact, MED effort) Brief description
3. [Deps] Title Brief description

All Clear

Tests (N passed), Linter (no issues), [other clean agents...]

Verdict: [Ready to Merge | Needs Attention | Needs Work]

[One sentence summary of what to do next]

### Verdict Guidelines

- **Ready to Merge** - All tests pass, no critical/high issues, suggestions are optional
- **Needs Attention** - Has medium issues or important suggestions worth addressing
- **Needs Work** - Has critical/high issues or failing tests that must be fixed

Next

So that's how I'm currently doing code review with Claude Code.

The real win is telling AI agents to run this and iterate before marking tasks "done" - it catches issues before I even look at the code. Adding in the extra subagents has further improved how comprehensive and useful the feedback has been.

Note that I'm constantly iterating on my workflows. I kind of think of it like coding in markdown. If I see a problem or potential improvement, I can dive in and update the instructions.

HAMINIONs members get access to the HAMY LABS Example Repo which now contains my full Claude Code configuration that I use for all my projects. It includes my full changes workflow which I've used to vibe engineer games, libraries, and web apps as well as my configs for permissions, status lines, and additional commands I find useful.

If you liked this post you might also like:

• How I think about writing quality code fast with AI
• 5 AI Coding Best Practices from a Google AI Director (That Actually Work)
• AI Is Here to Stay