Claude Code Review: What It Catches, What It Misses

Can Claude Code reliably review code? Yes, it can, and it is genuinely good at one specific part of the job. Anthropic ships Claude Code Review in two forms: a managed GitHub App that reviews pull requests in the cloud, and a /code-review command you can run locally in any Claude Code session. Both send several agents to work at the same time, each hunting a different class of defect, then run a verification pass that tries to disprove each finding before it reaches you. What neither one does is execute your code, scan for leaked secrets, or tell you that the feature you built solves the wrong problem.

We build Claude Code automation for clients commercially, so when Claude Code Review landed we did the obvious thing: pointed it at our own repositories and kept notes. The useful question turned out not to be whether the reviews are any good. It is which reviews you can now hand over, and which ones you still cannot. Below is what it catches, what it misses, what it costs to run, and the point where a human reviewer has to step back in.

What Is Claude Code Review?

Claude Code Review is an automated pull request reviewer built on multiple specialized agents. When a review starts, several agents examine the changed code and the surrounding codebase at the same time, each one assigned a different category of defect. A verification step then tests each candidate finding against how the code actually behaves and discards the ones it cannot substantiate.

The agents look for:

• Logic errors
• Security vulnerabilities
• Broken edge cases
• Subtle regressions

The verification step is what makes the results worth reading. Without it, AI review tends to bury you in comments that sound reasonable but turn out to be wrong, and triaging that costs more time than it saves.

The reported results support that design. After deploying it internally, Anthropic says the share of pull requests receiving substantive comments rose from 16% to 54%, with fewer than 1% of findings marked incorrect by their engineers. On pull requests of 1,000 lines or more, Anthropic reports that 84% get findings, averaging 7.5 issues each. These are vendor figures measured on a vendor codebase, so treat the exact numbers with appropriate caution, though the pattern holds up in practice.

Two Ways To Run Claude Code Review

The first option is a hosted service that Anthropic runs for you, so there is nothing to install in your pipeline. An admin on your company’s Claude account, someone with billing and settings access, connects the Claude GitHub App and picks which repositories it can review. From then on, reviews run automatically when a pull request opens, on every push, or only when a developer asks for one, depending on how each repository is set. Findings appear as comments on the specific lines of code they refer to, each labelled by how serious it is, and they never stop you from merging.

The second option is the local /code-review command, which works on any plan and needs no admin setup at all. It reviews your current branch plus any uncommitted changes, runs in the background so it does not interrupt what you are doing, and can apply its own fixes to your working copy if you ask it to. Engineers use it before they push, which is far cheaper than finding the same bug 20 minutes after opening a pull request.

You can steer either version by keeping two files in your repository: CLAUDE.md, which holds general project context, and REVIEW.md, which holds review-only rules and carries more weight. For everything else in your Claude toolchain, our roundup of the best Claude Code plugins covers what pairs well with it.

Why Codebase Access Matters More Than Model Choice

Teams evaluating AI review tend to fixate on which model sits underneath. That is the less interesting variable. What actually separates a useful review from a noisy one is how much the reviewing agent can see: your whole repository or just the lines that changed, and whether it knows your team’s conventions or is guessing from function names.

An agent reading a diff in isolation can tell you the code is internally consistent. An agent that reads the diff plus the twelve files that call into it can tell you the change breaks something two directories away. That is the difference buyers should be testing for, and it is a question about context and configuration rather than about model benchmarks.

What Claude Code Review Catches

The strongest results cluster in one place: defects that require reading more of the codebase than a human reviewer typically opens. Human reviewers look at the diff, because opening everything the diff touches is slow. An agent has no such constraint.

Cross-file contract drift. A change to a data structure that quietly breaks an assumption in a consumer several directories away. This is the highest-value category, because it is exactly the failure that a diff-focused human review is structured to miss.

Missed await and fire-and-forget async calls. Not a novel class of bug, but caught consistently, including inside error-handling blocks where a swallowed exception means the failure never shows up in logs.

Rules you have actually written down. Give it a rule like “every database query must be scoped to the calling tenant” and it enforces that rule per pull request. Static analysis tools do not know your multi-tenancy model. A review agent does, once you tell it. This is the single highest-leverage thing most teams skip.

Boundary and off-by-one errors. Pagination limits, array bounds, inclusive versus exclusive ranges, usually reported with the specific input that reproduces the problem.

Documentation that no longer matches the code. This works in both directions. When a pull request makes a documented statement outdated, it flags the documentation as needing an update rather than only reviewing the code.

Bugs that were already there. Problems in code near the change get labelled as pre-existing rather than blamed on the author, which is the correct call and genuinely useful for ranking technical debt.

The broader research explains why this matters now. Google’s 2025 DORA report found that AI adoption increases both software delivery throughput and software delivery instability, because the systems that verify code have not kept pace with how fast code now gets written. An agent that reads your whole codebase is one of the few available counterweights to the instability half of that trade.

What Claude Code Review Misses

The gaps are structural rather than a matter of the tool maturing, which makes them the deciding factor in how much human review you can safely remove. Every finding is produced by reasoning about code, not by running it. That single fact defines most of what follows.

Anything that needs the code to execute. Performance cliffs that only appear at production data volume. Query patterns that only multiply under a real database session. Race conditions that need genuine concurrency to surface. Memory behaviour under sustained load. None of these are visible to a reviewer that reads rather than runs.

Secrets, static application security testing, and infrastructure-as-code scanning. If a hardcoded credential or an over-permissive cloud policy lands in a diff, do not assume this catches it. Keep the scanners you already run.

Business-rule correctness. It will confirm that a discount calculation is internally consistent and arithmetically sound. It has no way of knowing that finance changed the rule last quarter. Code that is simultaneously correct and wrong remains a human problem.

Architectural judgment. It will not tell you that the third microservice you added this month should have been a module, or that a pattern works today but will not survive the next two features. Design questions also need back and forth, and each round of review takes about 20 minutes, so working through an architectural decision this way is impractical even when the reviewer has something useful to say.

Test quality. The default focus is correctness bugs, not coverage gaps. A pull request with three tests that all assert the happy path passes review cleanly unless you have explicitly asked for more.

There is also a limit worth reading as a feature. It does not approve pull requests and its status check never blocks a merge, so the decision stays with a person. That is deliberate, and it matches how much developers currently trust this class of output: Stack Overflow’s 2025 survey found the top AI frustration, cited by 66% of developers, is output that is almost right but not quite. An AI reviewer inherits that same characteristic. It performs well on the mechanical layer and stays quiet about intent. For how this plays out across tools generally, see our piece on AI-powered code reviews.

How Much Should You Run, And How Often?

Cost scales with how often reviews fire, and the trigger setting matters more than the per-review price. Gartner projects that 75% of enterprise software engineers will use AI code assistants by 2028, up from under 14% in early 2024, so review capacity is the constraint that breaks first as code generation gets cheaper. Paying for it indiscriminately is still a mistake.

The setup that holds up in practice is simple. Review once when a pull request opens, for most repositories, because that catches the majority of issues for a single charge. Switch to on-request only for your busiest repositories, where reviewing every push would multiply the bill without adding much. And have engineers run the local command before they push, since that costs nothing extra and catches problems before a paid review ever starts.

Set a monthly spend cap before you roll this out widely, then check the per-repository average cost after the first week and adjust from there. If you are standardizing review practice across timezones, our comparison of code review tools for distributed teams is a useful companion read.

When You Still Need An Independent Code Review

Some questions are outside what an automated reviewer is built to answer, and they tend to be the expensive ones. They share a common shape: the finding that matters is a pattern across the whole codebase rather than a defect inside one change.

Technical due diligence before an acquisition is the clearest case, where the question is whether the asset is maintainable rather than whether line 142 has a bug. Security and compliance audits need executable proof rather than inference. Inheriting a codebase from a previous vendor calls for someone tracing a pattern across 40 files, which no per-pull-request review will ever see. And any repository where AI wrote most of the code and nobody has since asked whether it holds together is a job for vibe code cleanup rather than another automated pass.

Here is the honest summary. Claude Code Review flags the subtle bugs and mistakes that easily slip past an exhausted code reviewer rushing to finish up. It does not catch the problems a reviewer finds because they remember why that module was written the way it was in 2019.

Why Teams Bring Redwerk In

We have spent more than two decades building custom software for companies across North America and Europe, including Siemens, J.B. Hunt, and Universal Music Group. The engineering fundamentals and security practices behind a good review are not something we picked up from a product release. They are what we were already doing.

That turns into three kinds of help. We configure Claude Code as a review agent properly, with severity calibrated to your codebase, spend controls in place, and triggers tuned per repository instead of switched on everywhere. We build the wider Claude Code automation around it, because review is one workflow and most teams have several others worth automating. And when the right answer is a person reading your code carefully, our code review services deliver that with a written report you can hand to a board or a buyer.

Want to know what an automated reviewer would and would not catch in your codebase? Get in touch with our team and we will walk through it with you.

FAQ

See how Redwerk audited Complete Network's Project Science software and boosted code maintainability by 80% before scaling nationwide

Please enter your business email isn′t a business email

Get Case Study