What to look at in a review

Review in priority order so you spend energy where bugs hide. Do not spend human attention on formatting a formatter owns. Configure CI so bikeshedding dies in the bot — see CI pipelines.

Walking through the order

1. Design — Does this belong here? Right abstraction? Wrong layer? See maintainable code.
2. Correctness — Edge cases, races, authz, nulls, idempotency, error paths.
3. Tests — Do they fail for the right reason? Missing regression coverage?
4. Readability & naming — Can the next reader follow it?
5. Nits — Style the linter cannot catch; keep these light.

Google's published standard is blunt: approve a change when it improves the codebase, even if it is not perfect. Blocking for perfection creates huge PRs, stale branches and demoralized authors. Rubber-stamping creates slow-motion rot.

If you only have ten minutes, spend them on design and correctness of the risky files, leave an honest "partial review — LGTM on X, need eyes on Y from @owner," and do not fake a full LGTM.

Triage the inbox:

1. Blocking teammates / release train — review now.
2. Your team's risky areas (billing, auth, data) — high priority.
3. Docs and pure refactors — can wait a bit; still do not starve them.
4. FYI CCs — skim or drop if you are not the right owner.

When reviewing AI-generated diffs, apply more scrutiny, not less: models produce plausible wrong code, miss authz, and invent APIs. You still own every line that merges (see working with AI tools). Treat AI review bots as linters: useful on pattern matches, wrong on design.

As a reviewer, if you need a walkthrough to understand the change, say so early. A 15-minute huddle beats three days of asynchronous guesswork — then summarize the conclusion on the PR for the archive.

Common mistakes

• Nits first. You burned the author's attention before you found the race.
• Fake full LGTM after a ten-minute skim of billing code.
• Fighting the formatter. That is CI's job.

Check yourself

1. You have ten minutes and a risky billing PR. What do you look at?

Design and correctness on the risky files, then an honest partial LGTM — not a fake full approval.

2. What does LGTM commit you to?

Owning the change on main with your name on the review.

Key takeaways

• Order: design → correctness → tests → readability → nits.
• Approve improvements, not perfection; never fake a full LGTM.
• AI diffs and bots get more scrutiny, not less.

Further learning

What to look for in a code review (Google)Google’s Engineering Practices documentationeng-practices

Next: review tone.