Code Review Best Practices: 10 Rules for Teams

The code review best practices that matter most are a few habits: keep pull requests (PRs) small, review them within one business day, let CI catch style and test failures before a person looks, and explain the why behind every comment. The ten practices below are written for engineers and leads on a team that reviews PRs, including ones a coding agent wrote. After them come a step-by-step way to do a review and what changes when an AI reads the code.

We have numbers on the first habit. Across 1,232 PRs in our two main repositories, our AI reviewer flagged 11% of those under 100 changed lines and 57% of those with 1,000 to 2,999. We’re one small team, so read that as a data point. The full table is in the AI section further down.

You need at least two people merging through PRs for any of this to apply, because a solo project has no second reader. None of it replaces a security audit either, where a specialist reads the code for one thing only.

Review does three jobs at once. It catches defects before they ship, it keeps the codebase consistent, and it spreads knowledge of the code across the team. A process that does only the first job, slowly, turns into a queue people resent. Review is also just one stage of the development lifecycle, and SDLC best practices covers the others, from requirements to monitoring.

1. Write down what a review checks

A written standard turns review comments from opinions into references. Agree on what every review looks at, write it down, and keep it in the repository (for example as REVIEW_CHECKLIST.md or in the PR template) so it changes through PRs like the code.

Google publishes its own reviewer guide, and it makes a good starting point for yours. It covers design, functionality, complexity, tests, naming, comments, style and documentation (Google engineering practices).

• Start with five to seven checks covering correctness, readability, tests and security. Add a check when the same problem shows up in several reviews.
• Leave out what a tool can check. Formatting and lint rules belong in CI (practice 3), not on the checklist.
• Revisit it every few months and drop the checks nobody uses.

2. Keep pull requests small and focused

A small PR gets a faster and better review. Each one should do one logical thing, whether that’s a bug fix, a refactor or a slice of a feature. Google’s guide puts it plainly: 100 lines is usually a reasonable size, and 1,000 lines is usually too large (Google).

This matters more when an agent writes the code, because an agent can produce a 2,000-line diff in minutes. Our own review data, in the AI section below, shows how much more often large PRs get flagged.

• Split before you open the PR. Separate refactors from behavior changes, and mechanical renames from logic.
• Use feature flags to merge unfinished work in small steps without shipping it to users.
• Stack your PRs when a change really is large, as a chain of small ones that can each be reviewed on their own.

3. Let CI catch style and test failures before review

No reviewer should spend time on formatting, lint errors or a failing test. Run those checks automatically on every PR, and make them required so a person only reviews code that already builds and passes.

• Start with the basics. That means a formatter, a linter (such as ESLint for JavaScript or Ruff for Python) and your test suite. Add a security scanner next.
• Run the same checks locally with pre-commit hooks (pre-commit is a common framework), so authors catch problems before they push.
• Give coding agents the same checks. A Claude Code hook can run your formatter after every edit, so the agent’s diff arrives clean (Claude Code docs).
• Keep CI fast. A slow pipeline delays every review behind it.

4. Give specific feedback and explain the why

A useful comment says what to change and why. “This is wrong” teaches nothing. “This throws if user is null, which happens for logged-out visitors; can we return early?” gives the author the reason and a fix.

• Propose the fix. On GitHub, a suggested change lets the author apply your edit in one click (GitHub Docs).
• Label how much a comment matters. Prefixes like “nit:”, “question:” and “blocking:” tell the author what must change before merge (Conventional Comments is one such scheme).
• Ask when you’re unsure. “Why this approach over X?” invites an answer instead of a defense.

Code review comment examples

Instead of	Write	What it adds
“Clean this up.”	“nit: data could be pendingInvoices, so the loop reads on its own. Not blocking.”	It says what to change and that it can wait
“Needs tests.”	“blocking: this changes how refunds round. Can you add a case for a half-cent amount?”	It names the exact case and why it stops the merge
“Why did you do it this way?”	“question: why a new cache here instead of the one in lib/cache? If it’s the eviction rules, let’s note that in the description.”	It asks for the reason without blame
“LGTM” on a 900-line PR	“The API change looks right. I didn’t read the migration, so someone who knows the schema should check that part.”	It says what was reviewed and what wasn’t

5. Review within one business day

A PR that waits a day loses its author’s context. By the time feedback arrives, they’ve moved on to something else, and the branch has started to drift from main. Google’s guide sets one business day as the maximum time to respond to a review request (Google).

The first response doesn’t have to be the full review. A quick “I’ll look this afternoon” or a first pass on the design keeps the author moving.

• Agree on a turnaround as a team and write it down.
• Send reminders. GitHub’s scheduled reminders can post pending reviews to Slack.
• Rotate a reviewer of the day so reviews don’t pile up on the same two people.
• Plan for time zones. On a distributed team, open the PR before your day ends and say in the description what you need, so a reviewer in the next time zone can start without waiting for you.

6. Use reviews to share knowledge

Every review is a chance for someone else to learn a part of the codebase. If the same senior engineer reviews everything in one area, the team has one person who understands it.

• Pair reviewers across areas. Have someone outside the area review alongside the owner from time to time.
• Record decisions in the PR. When a review settles a design trade-off, say so in a comment or the description. That’s the context the next person will search for.
• Link to the reason. Point to the doc, issue or earlier PR behind a suggestion.

7. Separate reviewing from approving

Anyone can review, and only owners approve. That lets more people give feedback while keeping merge authority with the people accountable for each area. GitHub’s CODEOWNERS file assigns required reviewers by path (GitHub Docs), and Kubernetes runs the same model with separate reviewers and approvers in its OWNERS files (Kubernetes).

• Define owners per directory with CODEOWNERS and require their approval in branch protection.
• Ask for more on high-risk code. Auth, billing and data migrations can require a second approval.
• Invite junior engineers to review without approval rights. Reading code is how they learn it.

8. Hold AI-written code to the same bar

Code from a coding agent gets the same review as code from a person, and the same rule applies: no behavior change without a test. An agent can write plausible code that calls a function that doesn’t exist or skips an edge case, and a passing test is the cheapest proof it works.

• Require tests with every change. On our team, 93% of the 221 bug-fix PRs our agents wrote changed a test file. We matched files by path, so “changed” means touched and not necessarily newly written (details).
• The person who opens the PR owns it. They should be able to explain every line, whoever typed it.
• Ask for the plan. On a large change, the agent’s plan or the prompt that produced it helps the reviewer see what was intended.

9. Measure the review process, not the people

A few process numbers show where reviews get stuck: PR size, time to first review, time from open to merge, and how many review rounds a PR needs. Track them for the team, without ranking individuals, and look at trends over months. The developer productivity metrics guide covers which ones are worth tracking.

• Measure a baseline first, for at least two weeks, before you change the process.
• Change one thing at a time so you can tell what helped.

10. Keep reviews about the code

People submit work early and accept criticism when they trust the review is about the code. Leads set the tone by asking for review of their own work and taking feedback in public.

• Comment on the code, not the author. Write “This function does three things” rather than “you wrote this badly.”
• Praise what’s good. A short “nice, this is much clearer” costs nothing.
• Take long debates offline. If a thread goes past three rounds, talk it through, then record the outcome in the PR.

How to do a code review, step by step

To do a code review, read the description, review the main change before the small ones, check the code against a short list, and end with one clear decision. The order below comes from Google’s reviewer guide, and it works just as well on a GitHub pull request.

1. Read the description and decide if the change should happen at all. If it shouldn’t, say so now, politely, and suggest what to do instead.
2. Review the main file first. It’s usually the one with the most logic in it. Send design problems right away, because a design change can make the rest of your comments pointless.
3. Read the other files in order. Reading the tests first often shows what the change is meant to do. Take a break after about an hour, since Perforce’s guide suggests at most 60 minutes and 400 lines in one sitting (Perforce).
4. Check the code against the list below. Open the whole file when the diff doesn’t show enough.
5. End with one decision. On GitHub a review is a comment, an approval or a request for changes that must be addressed before merge (GitHub Docs). Once it’s approved, the author picks a merge method.

Code review checklist

Check	What to ask
Design	Do the pieces fit together, and does this change belong here?
Functionality	Does it do what the author intended, including edge cases and concurrency?
Complexity	Is anything harder to follow than it needs to be, or built for a need that doesn’t exist yet?
Tests	Are there tests, and would they fail if the code broke?
Naming	Does each name say what the thing is or does?
Comments	Do comments explain why, rather than what?
Style	Anything your formatter and linter can’t catch? Mark personal preferences as “nit:”.
Documentation	If this changes how the code is built, run or released, were the docs updated?
Context	Does the change leave the codebase healthier than it found it?
Security	Is input validated, and are secrets kept out of code and logs?

All but the security row follow what Google’s reviewers look for. Trim it to what your team gets wrong, as practice 1 suggests.

When an AI reviews the code

Automated code review means a tool reads the diff and comments on it before a person does. Static analysis tools apply fixed rules. AI reviewers, such as GitHub Copilot code review, Cursor Bugbot, CodeRabbit and Qodo, send the diff and the surrounding code to a language model, which leaves comments as a colleague would. They catch some real bugs and many style issues, they also raise false alarms, and a person still decides what merges.

How much do they catch? Our sister product IonWarp, an AI code reviewer, publishes a code-review benchmark of 50 open-source pull requests with 158 known issues, taken from the independent Martian code-review-bench. In its provisional snapshot of October 6, 2026, the model with the highest F1 score (Muse Spark 1.3, running in IonWarp’s own reviewer) found 79 of the 158 issues, and 65% of its comments matched one of them. The app with the highest F1 score, Qodo v2, found 62% of the issues, and 55% of its comments matched. IonWarp ran the evaluation, and Martian has not certified it. So the two leaders missed between 38% and 50% of the known issues, and at least one comment in three didn’t match any of them. Some of those comments may still be fair catches, since the benchmark only scores against its own list.

Our own PRs add two numbers. They come from Winding Labs, a small team with two repositories (details).

• Size predicts findings. Across 1,232 PRs IonWarp reviewed, 11% of those under 100 changed lines got a should-fix flag on the first review, against 57% of those with 1,000 to 2,999 lines.
• Agents act on review comments. In the 30 days to October 4, 2026, our coding agents answered 2,273 review findings. They fixed 80%, declined 18% and handed 1.6% to a human.

Here is how the flag rate moved with size across those 1,232 PRs.

Lines changed	PRs	Should-fix flag on the first review
Under 100	298	11%
100–299	277	23%
300–999	334	45%
1,000–2,999	185	57%
3,000 and more	138	51%

Above 3,000 lines the rate stops rising, partly because each reviewer lane reads a capped slice of a very large diff.

How to roll out AI code review so developers trust it

Start on a few repositories, keep the tool advisory, and show the team how many of its comments held up. A reviewer that’s often wrong gets ignored, so aim for few false alarms before you aim for coverage.

1. Start with one or two repositories whose teams volunteer. For Copilot, a branch ruleset turns automatic review on for one repository, and an organization ruleset widens it later (GitHub Docs).
2. Keep it advisory. On GitHub, Copilot’s approvals satisfy merge requirements only if you turn that on, so leave it off.
3. Give it your team’s rules. Copilot code review and Codex’s GitHub review both read AGENTS.md, so conventions you’ve already written down carry over (how each reads it).
4. Count what gets fixed and what gets declined, per repository. A decline isn’t proof a finding was wrong, but a rising decline rate means the tool needs tuning before you add more repositories.
5. Send large and high-risk changes to a person first, whatever the AI said about them. The table above shows why.

Once it runs on every PR, three habits keep it useful.

• Run it first, so the human reviewer sees a diff with the obvious problems already fixed.
• Treat its comments as suggestions. Decline the wrong ones with a reason, and keep a human approval required. GitHub’s own docs say Copilot “is not guaranteed to spot all problems” and should be supplemented with a human review (GitHub Docs).
• Keep PRs small. The reviewer, human or AI, does better work on a smaller diff.

Zest records each engineer’s coding-agent sessions (Claude Code, Codex, Cursor, Copilot Chat) and links them to the pull requests they led to.

Numbers to quote

Each answer below has its source, so you can check it. The size row is ours.

Question	Answer	Source
How big should a PR be?	About 100 lines is usually reasonable, and 1,000 usually too large	Google
How fast should a reviewer respond?	Within one business day	Google
How long should one sitting last?	At most 60 minutes and 400 lines	Perforce
What should a review look at?	Design, functionality, complexity, tests, naming, comments, style and documentation	Google
Does PR size predict findings?	Across 1,232 PRs, our reviewer flagged 11% of those under 100 changed lines and 57% of those with 1,000 to 2,999	Our data
How much do AI reviewers catch?	The two leaders found 50% and 62% of 158 known issues, on 50 PRs	IonWarp benchmark, Oct 6, 2026

Frequently asked questions

What is code review?

Code review is when someone other than the author reads a change before it merges. It catches defects, keeps the codebase consistent and spreads knowledge of the code across the team.

What should you check in a code review?

Check the design, that the code does what the author intended, that it’s no more complex than it needs to be, and that its tests would fail if the code broke. Then check naming, comments, style and documentation, which together are the list in Google’s reviewer guide, and add security. The checklist above puts these in one table.

How do you write a good review comment?

Say what to change, why, and how much it matters. For example, “blocking: this changes how refunds round. Can you add a case for a half-cent amount?” gives the author the exact case and tells them it stops the merge. The table under practice 4 has more examples.

How long should a review take?

Keep one sitting to about an hour and 400 lines, which is Perforce’s guidance, and send the first response within one business day. If a change needs longer than that, ask the author to split it.

How do you run reviews on a remote team?

Write the description so a reviewer in another time zone can start without you, say what you need from them, and open the PR before your day ends. Agree on a turnaround in writing, and use GitHub’s scheduled reminders to post waiting reviews to Slack.

What should an AI code review checklist include?

The same checks as any other, plus four about the agent. Does a test prove the change works? Does every function it calls exist? Is the diff the size the task needed? Has a person read it and can they explain it?

What is a good prompt for code review?

Ask for bugs instead of style, and say what you want back. For example, “Review this diff for bugs that change behavior. Quote the line, say when it breaks, and propose a fix. If you aren’t sure, say so.” Keep your team’s rules in AGENTS.md instead of the prompt, so every tool that reads that file gets them.

What is automated code review?

It’s a tool that reads a PR’s diff and comments on it without a person. Linters and static analysis apply fixed rules, while AI reviewers use a language model to comment as a colleague would. Both run before or alongside human review, and neither should be the only check before merge.

Can AI replace human code review?

No. AI reviewers catch some real bugs and many style issues, but they also miss issues and raise false alarms. On IonWarp’s benchmark of 50 open-source PRs, the model with the highest F1 score found half of the 158 known issues. Use AI review as a first pass and keep a human approval required.

How big should a pull request be?

Small enough to review in one sitting. Google’s engineering guide calls 100 lines usually reasonable and 1,000 lines usually too large. In our own PRs, 57% of those with 1,000 to 2,999 changed lines got a should-fix flag from our AI reviewer, against 11% of those under 100 lines.

How fast should a code review happen?

Within one business day of the request, which is the maximum Google’s reviewer guide sets. The first response can be short, as long as the author knows when the full review will come.