How Specialist AI Agents Split a Pull Request for Code Review

A specialist AI code review system should not send every file to every agent. It should route each changed file to the checks that match its risk, then merge only findings with clear evidence. This cuts repeat work and gives the human reviewer one useful result.

The pattern has four parts: classify the change, assign small review jobs, remove duplicate findings, and send the final list through a human gate. The goal is better focus. It is not more comments.

Why one large review prompt breaks down

A pull request can change an API handler, a database query, a test file, and a deployment rule at once. One agent must hold all those rules in context. It may spend time on low-risk files while missing the path that moves money or user data.

A broad review can also repeat itself. A security note may appear again as an architecture note. A test agent may report a missing check that another agent already proved. The human then sorts the comments instead of reviewing the code.

The cost is larger than model tokens. It includes repeated tool calls, test time, comment cleanup, and the reviewer’s time. Measure the whole review, not the first model response.

The four specialist jobs

1. Correctness reviewer

This agent asks whether the code does what the ticket says. It follows changed inputs through outputs, checks error paths, and looks for behavior that changed by accident.

Useful proof includes a failing example, a code path, a test result, or a clear mismatch with an acceptance rule.

2. Security reviewer

This agent looks for unsafe data flow, missing access checks, secret leaks, injection paths, and risky dependency changes. It should focus on files that touch identity, money, protected data, network calls, or command execution.

A security agent should state the trigger, impact, evidence, and a way to verify the finding. A label without proof creates noise.

3. Test reviewer

This agent compares the changed behavior with the tests. It checks whether the happy path, edge cases, and failure paths are covered. It also looks for weak assertions that pass without proving the result.

The agent should not ask for more tests by default. It should name the missing behavior and the smallest test that would prove it.

4. Architecture reviewer

This agent checks boundaries. It looks for a new dependency, a public API change, work in the wrong layer, or a local fix that breaks a shared pattern.

Architecture findings need a clear rule or repository pattern. Personal style should stay out of the final review.

How the router assigns work

Start with facts from the pull request: changed paths, file types, diff size, labels, linked ticket, and the services touched. Add known risk tags from the repository.

A simple rule set can look like this:

• Authentication, payment, secrets, or network code → correctness + security + tests.
• Public API or shared library change → correctness + architecture + tests.
• Test-only change → test reviewer, plus correctness when expected behavior changed.
• Documentation-only change → no code agent unless the docs define a public contract.
• Large or cross-service change → architecture first, then focused checks by file.

Do not treat this list as a universal policy. Build rules from your own incidents, code owners, and protected paths.

A worked example: one payment pull request

Assume a pull request changes three files:

• payments/retry.go adds one retry after a network timeout.
• orders/store.go reuses an idempotency key.
• payments/retry_test.go adds two tests.

The router sends retry.go to correctness, security, and test reviewers. It sends store.go to correctness, security, and architecture reviewers. It sends the test file to the test reviewer.

The correctness agent checks that bank declines do not retry. The security agent checks that the key cannot cross users. The test agent checks timeout, decline, and duplicate-click paths. The architecture agent checks whether idempotency still belongs in the order store.

Each agent returns a finding with location, trigger, impact, evidence, and verification. If two agents report the same missing idempotency rule, the merger keeps the stronger proof and lists both review sources.

How to merge findings without hiding risk

The merge step is a review job of its own. It should group findings by root cause, keep the strongest evidence, and preserve the highest supported severity.

Use these rules:

1. Match findings by file, line, symbol, and root cause.
2. Merge repeats only when they describe the same failure.
3. Keep different impacts separate, even when they point to one line.
4. Drop style notes that have no team rule.
5. Mark uncertain findings for a person instead of presenting them as facts.
6. Keep the exact reviewed revision with every result.

The final summary should show blockers first, then useful advice. It should also show which checks ran and which checks could not run.

How VibeFlow handles review today

VibeFlow documents a clear review loop with Vera, its Code Reviewer. Vera reviews an exact pull request revision, records evidence-backed findings, and reports them on the pull request. Unresolved blockers become repair tickets. When fixes are allowed, a coding agent repairs the same pull request and a fresh Vera session checks the new revision.

VibeFlow also documents separate security and QA gates for work items. QA checks the implementation against requirements after security review passes. The platform uses branch locks for code-changing personas, while review personas can inspect work without taking that lock.

This article’s four-way file router is a proposed design pattern. The public docs do not claim that Vera runs four parallel specialist subreviews for each pull request. Keep that line clear when you test or describe the system.

Read Code Review with Vera, Agent Sessions, and QA Verification for the current documented behavior. GitHub pull request reviews explain the human review and approval model that this agent flow must support.

Cost: track the accepted finding

A specialist system can cost more when every agent sees the full repository. Routing only helps when each agent gets the small context it needs.

Track these fields per review:

• Input, cached input, and output tokens by specialist.
• Tool calls, test minutes, and sandbox time.
• Findings created, merged, dismissed, and accepted.
• Human minutes spent reading and checking findings.
• Fixes verified on a later revision.

Use this decision rule: total review cost divided by accepted findings. Also watch blocker recall on a labeled test set. A cheap review that misses a serious defect is not a win.

A safe test plan

1. Pick 10 past pull requests with known outcomes.
2. Label real defects and harmless changes before the test.
3. Run one broad reviewer and one routed specialist setup.
4. Keep the model, tools, time limit, and repository revision the same.
5. Compare useful findings, missed defects, duplicate comments, tokens, test time, and human review time.
6. Review every result with a person who knows the code.
7. Change routing rules only after you can explain the miss or the noise.

This is a proposed test. It is not a claim that specialist agents beat one reviewer in every repository.

Frequently asked questions

Why split a pull request across specialist AI review agents?

Routing changed files to focused correctness, security, test, and architecture jobs can reduce repeated context and help each reviewer produce evidence for the risk it is checking.

How should a review router assign specialist agents?

Start with changed paths, file types, diff size, labels, linked tickets, touched services, protected paths, and known risk tags from the repository.

How do you merge duplicate AI code review findings?

Match findings by file, line, symbol, and root cause; merge only the same failure; preserve different impacts; keep the strongest evidence and exact revision.

Does VibeFlow currently run four parallel specialist subreviews?

No. The four-way router in this article is a proposed test design. VibeFlow documents Vera review, repair tickets, security and QA gates, and exact revision checks.

Start with one four-agent test on a safe pull request. Keep the jobs small, preserve the evidence, and give the human one result they can verify.

Frequently Asked Questions

Why split a pull request across specialist AI review agents?

Routing changed files to focused correctness, security, test, and architecture jobs can reduce repeated context and help each reviewer produce evidence for the risk it is checking.

How should a review router assign specialist agents?

Start with changed paths, file types, diff size, labels, linked tickets, touched services, protected paths, and known risk tags from the repository.

How do you merge duplicate AI code review findings?

Match findings by file, line, symbol, and root cause; merge only the same failure; preserve different impacts; keep the strongest evidence and exact revision.

Does VibeFlow currently run four parallel specialist subreviews?

No. The four-way router in this article is a proposed test design. VibeFlow documents Vera review, repair tickets, security and QA gates, and exact revision checks.