How our team does code review, the Claude Code way

Anthropic recently shared how the Claude Code team reviews code: How the Claude Code team does code review. Its goal fits in one sentence: spend as little human review time as possible without increasing reverts or incidents. Review is no longer a single gate before merging. Automated checks run throughout, and human attention goes only to the risky parts.

It resonated with us. We are an engineering team of just over ten people, and for more than a year we have been working toward the same thing: put human effort where it is truly needed, and leave the rest to AI. The tool we use to do that is HeyDeer, the AI code review service we built. Below, we walk through our approach alongside Anthropic’s article, and explain why HeyDeer is designed this way.

1. Why people can no longer review every line

Anthropic notes that Claude writes about 90% of Claude Code’s code, and that merged PRs more than doubled in a few months. Our path has been similar.

We used to hold code review to a strict standard: someone read every line carefully and considered whether there was a better way to write it, because bad code that makes it into the codebase is hard to clean out.

By the time of Opus 4.1, AI was already writing 70% to 80% of our code, and PRs waiting for review on GitHub kept piling up. We were starting to fall behind. Now, with Opus 5.5, models are capable enough that engineers mainly set goals and leave the implementation to coding agents, and AI writes close to 100% of our code. If people still reviewed every line, they would be the slowest step in the whole process.

At the same time, line-by-line review is worth less than it used to be. The code smells we once worried about most are easy for AI to clean up, so people no longer need to comb through them line by line. We’ll explain how we do that in a separate post.

So the question is no longer “how can people review faster?” but rather:

1. Which changes really need a person to look at them?
2. How do we keep quality high for the ones that don’t?

Let’s take them in turn.

2. Which changes need a person: tiering by risk

Anthropic’s answer is risk-based human approval: a classifier sets the risk level from the change itself, not from who wrote it. Low-risk changes need no human approval once automated checks pass, medium-risk changes need one person, and high-risk changes need two.

HeyDeer works the same way. Every review rates the PR’s risk level (low, medium or high) and explains why. In the PRs HeyDeer may approve setting, you choose which risk levels HeyDeer may approve.

Low and medium risk: HeyDeer approves

Our team chose Low- and medium-risk PRs: as long as a PR isn’t high risk and HeyDeer’s complete review finds no issues, HeyDeer approves it and the PR merges into main automatically.

We have worked this way for 8 months, and not once has merging buggy code taken down our production service.

High risk: people judge direction, HeyDeer handles the details

High-risk PRs still need another engineer’s approval. But that person’s role has changed: instead of hunting for mistakes line by line, they judge from a higher level whether the PR’s approach and direction are right. This matches where Anthropic’s article keeps people involved: deciding whether to build something, reviewing architecture, and reading the evidence behind a change. The fine details can be left to HeyDeer.

To help people find what matters faster, HeyDeer provides a walkthrough:

• It groups related changes, marks each group Must read, Should read or Skim, and lists changes off the main path under Other with the reason each is there. You can see at a glance what to skip and put your attention on the parts that matter most.
• It gives the PR’s risk level and the reasoning behind it, so you know what to confirm carefully.

Reviewers no longer read from the first file to the last. They go straight to the few places that most need a person’s judgment.

3. Keeping quality high where no person looks

Letting AI approve most PRs only works if its review can be trusted: it has to find what’s there without burying people in noise. HeyDeer is designed for both, and lets each team tune it to the way they review.

Accurate: several models review and cross-check each other

Anthropic’s AI review has several agents look for bugs in parallel, then has other agents vote on each finding, and posts only the ones that pass.

HeyDeer goes further: models from different vendors review each change and cross-check each other. A single model easily misses issues and easily reports false ones, and several copies of the same model tend to make the same mistakes. Different models have different blind spots, so cross-review finds noticeably more issues, and cross-checking filters out much of the noise and false positives.

Cutting noise also protects human attention. With too many false positives, people can’t keep up and eventually stop reading. Hand everything to a coding agent instead, and it may follow false positives blindly and bloat the codebase. Leaving review to AI only works when its results are accurate.

Thorough: repository checks enforce team conventions

Anthropic’s approach is that when the same review comment keeps coming up, you fix it at the source: in skills, lint rules, CLAUDE.md or REVIEW.md.

In our experience, general-purpose review tools struggle with the needs of a specific codebase: how button labels are capitalized, the tone of interface copy, the team’s conventions for using React, and so on. Written in AGENTS.md or a skill, these conventions guide coding agents as they write code, but in a full code review they are easily lost in a large context and missed.

HeyDeer’s repository checks are built for this. Write the requirements you want checked in plain language in .agents/checks, and HeyDeer gives each check its own reviewer, which reviews every PR that changes matching files against that one requirement, so nothing is missed.

Adjustable: a feedback scope that fits how your team reviews

Teams need different things from review feedback, so HeyDeer offers a feedback scope setting:

• Concise: for teams that still rely mainly on human review, in finance for example. It keeps only the important issues, so people spend their time where it matters most.
• Balanced (the default) or Detailed: for teams that hand most review and fixing to coding agents or HeyDeer. Fixing small issues costs AI almost nothing, so even minor issues get resolved.

4. After review: Autopilot fixes until the PR converges

Once review finds issues, someone still has to fix them. If an engineer has to come back every round to read the comments, ask an agent for changes and wait for the next review, their attention is still tied up.

Anthropic’s article is candid about a very real problem: AI review can fail to converge. One of their PRs went through more than fifty rounds of review and fixes overnight. About 59% of what the reviewer kept flagging was code that had been there since its first pass: each round found not new bugs but a few more old ones. They have since made a series of improvements, such as capping the number of rounds, re-reviewing only new changes after the first few passes, and not repeating findings already posted.

HeyDeer has treated convergence as a design goal of review from the start. When HeyDeer finds a batch of small issues, you can hand them to Autopilot: it fixes what’s open, pushes to the PR’s branch and reviews its own changes, repeating until the PR is ready to merge or a question needs a person. In our use, most PRs are done in two rounds and more complex ones in three. Autopilot runs at most 5 rounds, and when it stops it explains why and what still needs you.

This matters a lot to us. Context switching is very expensive for people, and we don’t want engineers holding two things in mind at once: writing a new feature while wondering whether the comments on their last PR have been addressed. Once they start Autopilot, engineers can move on to the next task with peace of mind.

Put together, this is our team’s daily routine: once engineers open a PR, they can move on to something else. HeyDeer reviews it and Autopilot fixes what it finds. Low- and medium-risk PRs are approved by HeyDeer and merge straight into main; for high-risk PRs, another engineer uses the walkthrough to check the direction.

5. Which teams can work this way

Who is this “only high-risk changes need human review” approach for? With what AI can do today, we think most startups and small to medium-sized companies can work this way, as long as their business doesn’t involve especially sensitive information. You can start by letting HeyDeer approve only low-risk PRs, then extend it to medium risk once the team has built confidence.

Closing thoughts

Here is roughly how Anthropic’s practices map to the way we use HeyDeer:

Tools and models will change, but the goal won’t: human attention is a team’s scarcest resource, so spend it where it counts most. If your team is also finding that AI writes code faster than people can review it, give HeyDeer a try.