Claude Code review workflow: two passes, never zero
An agent reviews first, a senior engineer reviews on top, within 24 business hours. How we split the work between them, and what each one catches.
A code review workflow that holds up with Claude Code runs in two passes. An agent reviews first, on mechanical criteria: conventions, tests, secrets, which sensitive surfaces the change touches. A senior engineer reviews second, on everything that needs judgment: architecture, consequences, which debt you are choosing to take on. The question is not agent or human. It is who catches what.
The common trap when you code with AI is assuming the code has already been reviewed because a model produced it. It has not. It was produced with confidence, which is a different thing. Every client PR we handle gets reviewed twice. Never zero.
Pass 1: what an agent should review
The agent runs when the PR opens, before any human looks at it. It does not give opinions. It checks things that have a binary answer.
Four categories:
Repo conventions. Naming, folder structure, component shape, error handling. An agent is excellent here because the rules are written down. We put them in the project's CLAUDE.md, the agent enforces them, and the style debate disappears from human review. That is bandwidth handed back to the things that matter.
Tests. Does the PR add one when it touches logic that deserves it? Do the existing ones still pass? The agent does not judge the quality of a test. It notices the absence of one.
Secrets and the obvious. Hardcoded API keys, tokens left in a config file, endpoints with no auth check, dependencies added for no visible reason. These are fatigue mistakes, not skill mistakes, and a machine does not get tired.
Critical surface detection. This is the most useful part, and the one most setups skip. The agent looks at which files the PR touches and compares them to the Core registry: data model, auth layer, API contracts, payment integrations, deploy paths. If the PR touches one of those, it gets tagged arch-review automatically. The tag is not decorative. It changes who reviews.
The agent posts its findings as PR comments. It does not block a merge on its own, and it does not approve anything on its own either. It sets the table.
Pass 2: what a human should review
The senior engineer comes next, with the agent's findings already visible. They are not reviewing the same thing. They review what has no binary answer.
Does this PR create a second way of doing something that already existed? Is this new database column going to be a migration problem in four months? Is this shortcut acceptable here, on a feature that will probably be rewritten, and unacceptable there, in code everything else depends on?
That is the kind of question AI does not settle, because answering it requires knowing the repo's history and the product's direction. A model sees the PR. It does not see the conversation six weeks ago where you decided not to do multi-tenancy yet.
On PRs tagged arch-review, an architect joins the reviewer. Two sets of human eyes, not because the code is harder, but because a mistake there costs more. When a structural decision comes out of it, it gets written down as an ADR in docs/adr/. Six months later, "why is it built this way" has an answer on file.
The turnaround time is part of the workflow
A review that arrives whenever it arrives does not work. A founder who waits three days to merge stops opening PRs and starts pushing to main. The workflow dies quietly.
On our side senior review lands within 24 business hours, and if we miss it, it costs us 0.25 days of credit against the next invoice. There is no volume cap either: the only known limit on what a founder can ship is their Claude credits.
That is not a commercial detail. It is what makes the rest of it enforceable. A constraint nobody honors becomes a constraint everybody routes around.
What you can set up on your own
Three things, in this order, if you code solo with Claude Code:
- Write your conventions into
CLAUDE.md. While they only live in your head, neither the agent nor a future collaborator can apply them. - List your critical surfaces. Eight to fifteen entries is enough: the files everything else depends on. Any PR touching them earns a slow read, even when you are the only one reading.
- Separate the two passes in time. Reviewing your own code right after generating it does not work. Open the PR, let the agent run, come back the next morning. The distance does half the job.
The principle fits in one line: AI catches the obvious, the human catches the rest. What matters is that both passes exist and that neither one pretends to be the other.
Want to know what a serious review would find in your repo today? We run the Bunker Test for free: you give us access to the code, we send back a written report within five business days. No commitment.
Version française : Workflow de code review avec Claude Code.
Want to see this approach running on your repo? Send us access and we'll come back with at least 5 concrete risks within 5 business days.