Code review

Code review is the most leveraged engineering activity nobody actively manages. A team that ships 200 PRs per month invests roughly 400 engineer-hours in review — but most teams have no SLO, no checklist, no measure of effectiveness, and no honest answer to "is our review process actually catching the bugs we think it is?"

This hub is the answer to that gap. Five articles, each addressing one decision the team has to make explicitly:

1. Checklists — what to actually look for, beyond style nits
2. Async review — keeping latency under 4 hours without forcing synchronous meetings
3. Mob review — when one reviewer isn't enough
4. SLOs — measuring what good actually looks like
5. AI-assisted review — the rigor you keep, the toil you delegate

Why this matters now

Code review is in transition. Three changes in the last three years have invalidated most of the "industry best practice" advice from 2015-2020:

• AI-generated code volume has exploded. The average PR now contains more code than the average PR in 2022, and a meaningful share is AI-drafted. Review patterns built for "engineer wrote, engineer reviews" don't account for "model wrote, engineer reviews" — which has different failure modes (subtle hallucinations, plausible-but-wrong patterns, over-confident structure).
• Distributed teams have made async review the default. The 2015-era advice ("pair on the change, then merge") assumed colocated teams. Modern teams span 6+ timezones; the synchronous-review default produces 24-48 hour latency that becomes the binding constraint on cycle time.
• AI assistance for reviewers has gone from novelty to table-stakes. GitHub Copilot, Stride's review assistant, and similar tools now catch class of defects (security patterns, performance regressions, accessibility errors) faster than a human can. The reviewer's role is shifting from "find defects" to "validate intent and tradeoffs."

The teams getting this right have specific practices. The teams not getting it right have inherited rituals.

What this hub assumes

You're working in a team of 4-30 engineers, shipping at least daily, with a pull-request based workflow (GitHub, GitLab, Bitbucket, or equivalent). You have at least one reviewer per change as a hard requirement; you may or may not have multiple reviewers, code-owner enforcement, or required approvers — the articles cover the variants.

If you're working in a paired/mob/trunk-based shop that doesn't use PRs at all, the mob review article is the relevant one; the rest assumes the PR model.

The five practices in one paragraph

A healthy code-review process catches bugs and design issues a CI pipeline misses, completes within 2-8 hours median (24 hours p95), uses checklists that focus on the high-value questions, escalates high-stakes changes to mob review or staged rollout, and delegates the mechanical work (style, missing tests, obvious anti-patterns) to AI assistants so the human review can focus on intent and architecture. Each of the five articles unpacks one of these dimensions.

How to use this hub

If you're optimising an existing process, start with SLOs to measure your current state, then read the article that addresses your weakest dimension. If you're building a process from scratch, read them in order — checklists set the baseline, async sets the cadence, SLOs set the measurement, mob review handles the exceptions, and AI assistance ties them together.

Each article includes practical templates (checklist examples, SLO definitions, mob-review formats) you can adapt directly. The Stride research linked from each article digs deeper into the underlying patterns.