Code Review Best Practices for Small Teams

The code review best practices that matter most for a small team are about flow, not rigor: keep each change small enough to review in one sitting, answer review requests within one business day, label every comment as blocking or optional, comment on the code rather than the person, and rotate who reviews so nobody becomes the only one who understands a part of the system. Let tools handle formatting and lint, let an AI reviewer take the first pass for obvious mistakes, and keep a person as the approval. Write the few rules down once so nobody argues them again on each pull request.

This piece is about how a team runs reviews. What the reviewer should look for in a given change is in the code review checklist, and what the author should put in the description is in the pull request template.

Know what review is for on a small team

Most people say review exists to find bugs. A Microsoft Research study of review at Microsoft, “Expectations, Outcomes, and Challenges of Modern Code Review”↗ (opens in a new tab), found that while finding defects was the main motivation, reviews were “less about defects than expected” and brought other benefits, including “knowledge transfer, increased team awareness, and creation of alternative solutions to problems.”

On a team of four, that second list is the bigger prize. If only one person has ever read the billing code, the team has a single point of failure, and it goes on vacation. Every best practice below serves one of two aims: find the problems a test would not, and make sure at least two people understand every part of the codebase.

Keep changes small

Size is the single biggest lever on review quality. Google’s engineering practices guide on small changes↗ (opens in a new tab) says small changes are reviewed more quickly and more thoroughly and are less likely to introduce bugs, and gives a rule of thumb: “100 lines is usually a reasonable size for a CL, and 1000 lines is usually too large.” It also notes that a change spread across many files is bigger than its line count suggests.

• One change, one purpose. A refactor, a feature and a dependency upgrade are three pull requests.
• Move and rename in a separate change from edits, so the reviewer can approve the mechanical part quickly and focus on the logic.
• Split big features behind a flag or into layers: data first, then the API, then the UI, each reviewable on its own.
• Treat “please split this” as a normal review comment, not a rejection.

Respond fast, even if you cannot review yet

A pull request waiting three days blocks its author, goes stale against the main branch, and tempts people to batch more into the next one, which makes review harder still. Google’s guide on review speed↗ (opens in a new tab) sets the bar plainly: “One business day is the maximum time it should take to respond to a code review request.” Responding is not the same as finishing; saying when you will get to it counts.

• Agree a response time as a team and write it into your team working agreement.
• Review at natural breaks, such as after standup or after lunch, rather than interrupting deep work for every notification.
• Approve with comments when the remaining points are small and you trust the author to handle them. It saves a round trip across time zones.
• If a review is going to take more than a day, say so and suggest someone else.

Get the tone right

On a small team, review tone is team culture. Google’s guide on writing review comments asks reviewers to be “courteous and respectful while also being very clear and helpful”, and to comment on the code rather than the developer. In practice:

• Say why. “This query runs once per row; with 10,000 orders that is 10,000 round trips” gets fixed. “This is slow” gets argued with.
• Ask when you are unsure. “What happens here if the list is empty?” is better than asserting a bug you have not confirmed.
• Label every comment so the author knows what must change. Google uses Nit, Optional and FYI. The Conventional Comments↗ (opens in a new tab) format goes further, with labels such as issue, suggestion, question and praise, and blocking or non-blocking decorations.
• Praise what is good. It tells the author what to keep doing, and it makes the critical comments easier to hear.
• Move long disagreements to a call. Two rounds of back-and-forth in comments is the limit; after that, talk, then write down what you decided.

issue (blocking): This returns every customer's orders when
customerId is missing. Filter on the signed-in user instead.

suggestion (non-blocking): formatPrice() in utils/money.ts
already handles currency; could reuse it here.

nit: "usr" -> "user"

praise: The retry test with the fake clock is very clear.

Decide who reviews

Big organizations have review rules per directory. A small team needs three decisions, made once:

1. How many approvals? One is right for most small teams. Two approvals on every change halves throughput for little gain; save the second for sign-in, payments, permissions and migrations.
2. Who picks the reviewer? Rotate by default so knowledge spreads, and let the author ask for a specific person when a change needs particular expertise.
3. Who must review certain paths? If one area really needs a named expert, GitHub’s CODEOWNERS↗ (opens in a new tab) file requests them automatically when a pull request touches their files, and branch protection can require their approval. Use it sparingly; every owner is a potential bottleneck.

A solo developer has nobody to rotate with. Review your own pull request the next morning, in the code host’s diff view rather than your editor, and let an AI reviewer take a pass first. Solo developers with AI coding agents covers that setup.

Make the author do the first review

• Read your own diff before requesting review. Most debug lines, commented-out code and stray files are caught here.
• Write the description for someone who has not seen the task: what, why, how it was tested, what is risky.
• Leave comments on your own pull request pointing reviewers at the tricky part.
• Make CI pass first. Formatting, lint, types and tests are not a reviewer’s job.

Use AI reviewers as the first pass, not the approval

An AI reviewer that comments on every pull request within minutes suits a small team well: it catches the null check and the unescaped query before a person spends time on them. Two practices keep it useful. First, tune it to what matters. Anthropic’s Claude Code best practices↗ (opens in a new tab) warn that a reviewer prompted to find gaps “will usually report some, even when the work is sound,” and recommend telling it to flag only what affects correctness or the stated requirements. Second, keep a person as the required approval, and make resolving the AI comments part of the author’s job before a human is asked. Which tools do this and how they differ is in AI code review tools compared; reviewing code an agent wrote is its own routine, in how to review AI-generated code.

Write the rules down once

Review norms that live in people’s heads get relitigated on every pull request, and AI assistants cannot follow norms they have never been shown. On a fenbs board, each norm is recorded as a rule on the Decisions and rules page: “one approval, two for payments and migrations”, “respond within one business day”, “no refactors mixed with fixes”. A rule is a decision that holds from now on, the decider is always a person, and every connected AI assistant reads the rules first, so an assistant opening or reviewing a pull request works to the same norms as the team. Findings from review that are real but out of scope become bugs in To Do, so they are fixed later rather than blocking the merge or being forgotten. fenbs does not connect to your code host or run reviews; it holds the rules and the follow-up work.