Code Review Good Practices: 10 Rules for Teams

Good code review comes down to a few habits: keep pull requests small, review them within a day, let CI catch style and test failures before a person looks, and explain the why behind every comment. The rest of this guide covers ten practices in that spirit, then what changes when an AI writes the code or reviews it.

Code 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 review process that does only the first job, slowly, turns into a queue people resent. The practices below keep all three.

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 pull request template) so it changes through pull requests like the code.

Google publishes its own reviewer guide, and it’s a good starting point for yours: 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. Drop checks nobody uses.

2. Keep pull requests small and focused

A small pull request gets a faster and better review. Each one should do one logical thing: one bug fix, one refactor, one 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 pull requests 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.
• Use stacked pull requests when a change really is large: a chain of small PRs, each reviewable on its 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 them automatically on every pull request, and make them required checks so a person only reviews code that already builds and passes.

• Start with the basics: 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.
• Keep CI fast. A slow pipeline delays every review behind it.

4. Give specific feedback and explain the why

A useful review 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.

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.

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; 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: 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 pull requests our agents wrote changed a test file (a path match on .test., .spec. and tests/; “changed”, 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. For 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: pull request size, time to first review, time from open to merge, and how many review rounds a PR needs. Track them for the team, not to rank 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: they should ask for review of their own work and take feedback in public.

• Comment on the code, not the author. “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.

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 code review tools, 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 like a reviewer would. They catch some real bugs and many style issues, they also raise false alarms, and a human still decides what merges.

How much do they catch? Our sister product IonWarp, an AI code reviewer, publishes a code-review benchmark: 50 open-source pull requests with 158 known issues, taken from the independent Martian code-review-bench. In its provisional snapshot of September 25, 2026, the top-ranked model found 79 of the 158 issues and raised 42 false alarms. IonWarp ran the evaluation, and Martian has not certified it. So the top model missed half the known issues, and about one comment in three was a false alarm.

Two numbers from our own pull requests (Winding Labs, a small team, two repositories; details):

• Size predicts findings. Across 1,232 pull requests IonWarp reviewed, 11% of PRs under 100 changed lines got a should-fix flag on the first review, against 57% of PRs 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% with a reason, and handed 1.6% to a human.

How to use an AI reviewer well:

• 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 pull requests 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.

Frequently asked questions

What is automated code review?

Automated code review is a tool that reads a pull request’s diff and comments on it without a person. Linters and static analysis apply fixed rules, while AI code review tools use a language model to comment like a human reviewer. Both run before or alongside human review; 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 pull requests, the top-ranked model found about 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 pull requests, 57% of PRs with 1,000 to 2,999 changed lines got a should-fix flag from our AI reviewer, against 11% of PRs 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.