One of the more useful lessons from working with Claude Code is that the same AI agent that helped write a feature isn't always the best reviewer of that feature. It knows the tradeoffs you already accepted. It knows the shortcuts it suggested itself. And it often tends to validate the direction rather than questioning it critically enough.
That's why for more important changes, I use a separate, fresh subagent with a clear read-only task. Not because it's magically smarter, but because it enters the codebase without the emotional and conversational baggage of the implementation session.
The problem: implementation context creates blind spots
During development, the AI assistant sees every decision: why a certain edge case was deferred, why a test wasn't added yet, why an integration was made simpler than originally planned. That context is useful while building, but can get in the way when you want an unbiased review.
If you ask the same session to "review this code," you'll often get a review that sounds reasonable but misses places where the session itself has already rationalized a compromise. This isn't only an AI tool problem. Human developers also find it easier to defend their own solution than someone else's.
The solution: a clean subagent with a narrow task
Instead of reviewing in the same session, I launch a subagent that can only read the code. I give it a specific scope, a list of risks, and an expected response format. Example prompt:
Launch a fresh subagent with read-only access and review the implementation of this flow. Do not use context from our previous discussion. Check for: - security vulnerabilities - missing edge cases - poor error handling - insufficiently tested parts - places where the solution is unnecessarily complex Return findings as a prioritized list with file:line references.
Good formulation matters. "Review the code" is too broad. "Look for security vulnerabilities, unhandled edge cases, and gaps in tests" is specific. The subagent doesn't need to know the full work history; it needs to know what exactly to challenge.
When this workflow makes sense
I use it for
- security-sensitive changes
- authorization, billing, and data migrations
- larger refactors with many touch points
- AI-generated changes before committing
I don't use it for
- small copy changes
- simple rename operations
- quick experiments that won't be committed
- reviews without a clear scope
A team standard matters more than a one-time trick
If a team wants to use AI coding tools seriously, this kind of workflow shouldn't depend on someone's memory. The rule can be written into the project's CLAUDE.md, a skill, or an internal delivery standard: for changes above a certain risk level, a separate review agent with read-only access is used.
That's part of a broader AI consulting approach: AI tools can speed up work, but only if they're introduced with clear rules for ownership, security, testing, and review. Without that, you get faster iterations but also faster spread of errors.
Conclusion
Claude Code subagents aren't a replacement for human review, but they're very useful as an additional layer of verification. They work best when you give them a narrow scope, read-only access, and criteria that match the risk of the change.
In practice, the biggest value isn't in the subagent itself but in the discipline the workflow introduces: clearly defined quality criteria, a fresh perspective, and the habit that AI-generated code doesn't go to production without independent verification.
Josip Budalić
HOTFIX team
Josip runs HOTFIX d.o.o. and works on software architecture, AI-assisted development workflows, codebase modernization, and practical software delivery.