A Claude Code Review Workflow That Saved 30 Minutes Per Engineer a Day

Code review is where mobile teams quietly lose a day per engineer per week. Not writing reviews. Waiting for them. I put Claude Code agents into the actual review loop for a multinational iOS team as the first pass on every PR, and in my own measurement it saved about 30 minutes per engineer per day. Review-cycle time came down and review quality held. Human reviewers went back to arguing about what actually matters: design.

Here is the exact Claude Code code review workflow, including the parts I tried that did not work.

The problem with human-first review

Every PR review mixes two very different jobs:

1. Mechanical verification. Does it build, are edge cases handled, is the naming consistent, did anyone forget to localize a string.
2. Judgment. Is this the right abstraction, does it fit where the module is heading, will this bite us in six months.

Humans are slow at the first and irreplaceable at the second. Classic review forces senior engineers to do both, so the mechanical part crowds out the judgment part. Reviewers skim, LGTM, and the architectural drift accumulates one skimmed PR at a time.

The workflow

I run Claude Code as a first-pass reviewer on every PR, before any human looks at it.

1. Agent review on PR open

A multi-agent review fans out over the diff, one agent per dimension:

• Correctness: edge cases, nil-handling, concurrency. The classics that slip through when a human skims 400 changed lines.
• Consistency: does the code match surrounding patterns, naming, error-handling idioms, module conventions.
• Tests: do the tests actually cover the behavior change, or do they just mirror the implementation.
• i18n and accessibility (mobile-specific): hardcoded strings, missing Dynamic Type support, touch targets under 44pt.

Each finding has to cite a file and line and describe a concrete failure scenario. A finding with no failure scenario gets dropped. That single rule is what keeps the output from turning into “consider improving readability” noise.

2. Author fixes before human review

The author gets findings in minutes, not hours. Mechanical issues die before a senior engineer ever context-switches into the PR. By the time a human opens it, the diff is clean enough that the review is about design.

3. Human review, redefined

Human reviewers now have one job: judgment. Module boundaries, API shape, whether this feature belongs here at all. The stuff I wrote about in iOS Architecture Decisions AI Can’t Make is still 100% human, and now it actually gets the attention it needs instead of losing the reviewer’s last hour to a missing nil check.

What didn’t work

Auto-merge on green agent review. This is the one I regret shipping first. An agent with a prompt but no encoded intent optimizes the nearest proxy, “tests pass”, not the real goal, “this change is correct and worth merging”. It happily green-lit changes that satisfied the letter of the tests and missed the point. I pulled auto-merge and put a human back on the merge button. The agent advises, the human decides.

One mega-agent instead of dimensions. A single “review everything” pass produces shallow findings. Fan-out with narrow lenses is what surfaces the real bugs. The correctness agent is not distracted by naming, so it actually reasons about concurrency.

Deploying the agents before I had a metric of record. I measured the 30 minutes after the fact and had to reconstruct the baseline. I should have agreed the number I cared about, and how I would measure it, before the first agent ran. If I did this again, that would be step zero. I made the same mistake again at a much smaller scale shipping llms.txt on this site, and what I’d do differently there is the same fix: decide how you’ll know it worked before you ship it.

What I actually measured

I am only going to quote what I measured, because a post like this lives or dies on that. On that multinational iOS team, over months of daily use: about 30 minutes saved per engineer per day, review-cycle time down, and review quality held (the human bar did not drop when the mechanical pass moved to an agent). I did not instrument escaped-defect rate or reclaimed senior hours cleanly enough to quote them, so I won’t.

Where to start

Don’t automate your whole review culture in a week. Start with one dimension (consistency is the safest), one repo, findings as suggestions, not gates. Keep the human on the merge button. Expand only when the team starts trusting the signal on its own. The review loop is one instance of a broader pattern; I wrote up how to choose and bound the rest in AI agent workflows for engineering teams.

If you want help setting up an AI-assisted engineering workflow for your team, the architecture, the tooling, and the change management around it, that is exactly what I do in strategy sessions.

One question I am still working out: where is the line for you between an agent that advises and an agent you would actually let merge? I have not found a team comfortable moving that line yet, and I would like to know if yours is.