How I Split Code Review Across Five Claude Code Subagents

Youssef Abouwarda — Fri, 11 Sep 2026 11:16:09 +0000

Reviewing agent-written code has an awkward property. If you review in the same session, the reviewer already justified the decisions it is now judging. Open a fresh session and you avoid the bias but pay for the whole context again. I have been running into this for a while, and subagents turned out to be the way out.
Some background: since June I have been building a HealthTech booking platform with Claude Code, spec driven.
Think through architecture and design -> discuss it with Opus in the chat -> write an ADR -> write a spec -> hand the spec to Claude Code -> it opens a PR -> I review it.
A few weeks ago I started preparing for an Anthropic certification, which meant going back through the Claude Code documentation and courses properly rather than picking things up as I went. Subagents were the idea I took away. Instead of delegating a whole task to one agent, you fork the context and hand parts of it to agents that run in their own window, in parallel.
So I built five review agents for the repo. What turned out to matter was not what each one checks, but what each one treats as the truth

code-reviewer: takes the diff and checks security, code quality and consistency with the project's own patterns, each with concrete criteria. It trusts the ADRs and judges the code.
adr-consistency-checker: the opposite direction. It trusts the code and judges the ADRs, checking whether the codebase actually implements what the documents claim. I ran it against one ADR as a test and it found three things wrong, including a session timeout I had documented and never built.
spec-to-diff-reviewer: I work spec driven, so I hand over a specification and expect code that follows it. This one extracts the concrete requirements from the spec and maps each to the diff, marked implemented or missing, with evidence. No quality judgment at all. The spec is the truth.
endpoint-tester: drives real HTTP requests against changed REST endpoints, so I find out whether they behave as expected rather than assuming.
config-dependency-auditor: cross-checks application.yaml, pom.xml and docker-compose across the five services. For example, an environment variable the YAML expects has to actually be provided by the compose file. That has bitten me more than once, so it is worth automating on config changes.

To see whether they actually work, I seeded a security bug on purpose: an endpoint trusting a client-supplied patient ID instead of the JWT subject. The code reviewer, the spec-to-diff reviewer and the endpoint tester each caught it independently.

That one was staged. A later PR implementing a transactional outbox gave me a real one: the code reviewer found a prune query with no supporting index, which would have quietly turned into a full table scan as the outbox grew.
I still review the output and make sure it works and it is correct. That has not changed. But reviewing is much easier when most of the work of reviewing is delegated too.

DEV Community: Youssef Abouwarda

How I Split Code Review Across Five Claude Code Subagents