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.
Top comments (4)
The self-review bias is real and I underestimated how cheap the fix was. I work with a handful of coding agents and until recently the one that wrote a diff was also the one summarizing it for me, which produced a lot of confident, well-argued rationalizations of its own choices.
Splitting review into a separate fresh session helped, but the thing I'm still bad at is context budgeting: the reviewer needs enough of the ADR to judge the tradeoff, yet every extra paragraph makes it defend the original framing. Do you pass it the spec, the diff, or both? Curious what your token cost looks like per PR now.
I pass it both, depneding on the subagent and what it needs, actually it's the main - coordinator - agent which passes to the subagents.
The problem with the ADR is real, but at some point you need a source of truth and it should be the ADR. You can let a model like Opus review the ADR - That's what I do -, or in a team let a peer review it.
For token cost per PR now I still need time to measure, because I ran these subagents twice, once for the PR of subagent definition where I let it generate a bug, review it and roll it back. and the second was implementation of outbox pattern across 5 services, which is good amount of work, maybe after 5-6 PRs with reviews I can get back to tell how many tokens a PR costs now.
Here is the PR with the subagent definitions, you can also take a look on the repo :)
github.com/ysfwrda/healthtech-book...
Some comments may only be visible to logged-in visitors. Sign in to view all comments.