Have you ever watched a 4,200-line pull request land on a Friday afternoon, sit in the queue all weekend, and get rubber-stamped on Monday because nobody had the energy left to argue?
The review went through. The diff merged. Nobody read it.
That scene is what pull request review on senior teams is supposed to prevent. Not the merge, the rubber stamp. Senior teams aren't bad at reviewing because they don't know how. They're bad at it because the process they inherited is the same one a five-person startup uses, and a five-person startup gets away with everything.
This article is about the small adjustments that make review work when the codebase is older than half the people reviewing it.
The Problem Isn't Review. It's The Review Bar.
Junior teams need review to teach. Senior teams need review to catch the things only context catches.
Those are different goals, and they call for different mechanics. A junior reviewer asks "is this code well-written?" A senior reviewer asks "what's the worst thing that happens if this ships and we're wrong about something we haven't thought of yet?"
If your review process can't tell those two questions apart, you end up with PRs that get nitpicked for variable names and merged with a load-bearing migration that nobody tested against production-sized data. The cosmetic stuff gets attention because it's easy. The dangerous stuff gets a "looks good" because it's hard.
The fix isn't to review harder. It's to review differently depending on what you're looking at.
Make Small PRs A Hard Rule, Not A Vibe
Every team says they like small PRs. Then a "small refactor" lands and the diff is 1,800 lines because the refactor touched eight modules and one of them needed a follow-up that needed a fixup that needed a rename.
Small isn't a line count. It's one decision per PR.
A 60-line diff that changes the error-handling strategy in three services is not small. It's three decisions mashed together, and the reviewer can't agree with one and push back on another without blocking the whole thing. A 400-line diff that adds a single new endpoint with its tests is small. It's one decision, and the reviewer either buys it or doesn't.
The friction of splitting work into single-decision PRs is the work. If you find yourself unable to split a feature into reviewable chunks, that's usually a signal the feature isn't designed yet. The chunks would be obvious if it were.
A practical bar that holds up well: a senior reviewer should be able to read your PR, understand the change, evaluate the risk, and either approve or push back in 10 to 15 minutes. If the PR demands an hour of context, you're asking the team to subsidize your design with their afternoon.
There are exceptions. A migration is a migration. A vendor SDK upgrade is a vendor SDK upgrade. The point isn't that no PR is ever big. It's that bigness should be a deliberate choice, not the default outcome of "I forgot to split this."
Stop Reviewing Every PR The Same Way
The single biggest upgrade most senior teams can make is tiered review. Not every PR deserves the same scrutiny, and pretending they do means the dangerous ones get the same energy as the trivial ones, which is to say, not enough.
A simple three-tier model works for almost every team:
| Tier | Examples | Reviewers | Bar |
|---|---|---|---|
| Low | Docs, comments, README fixes, config tweaks with no behavior change, dependency patch bumps | 1 (any team member) | Sanity check, ack-and-merge |
| Medium | Feature work, refactors, expected behavior changes, non-critical-path bug fixes | 1 senior, normal checklist | Read fully, ask the boring questions, approve |
| High | Auth, payments, data migrations, infra/IaC, anything touching production data shape, vendor SDK upgrades that change behavior | 2 reviewers, one of them a domain owner, plus async pairing on the design before code | Read line by line, sketch failure modes, agree on rollback, then approve |
The point isn't to bureaucratize. The point is that "two reviewers required" on the payments service stops feeling like overhead once the alternative is a 3 a.m. page.
The tier is set by the author, in the PR description, before review starts. The reviewer can challenge it ("this isn't medium, you're touching the auth token flow"), and that challenge itself is useful. It forces a conversation about risk before anyone reads the diff.
Ownership Beats Approval
A senior team that doesn't have CODEOWNERS is leaving free safety on the table.
The premise is simple: every meaningful part of the codebase has a named owning team, and changes to that part require an approval from someone on that team. GitHub enforces it natively, no CI gymnastics required.
# Default reviewer when nothing more specific matches
* @acme/platform
# Domain-owned paths
/services/payments/ @acme/payments-core
/services/auth/ @acme/security
/services/billing/ @acme/payments-core @acme/finance-eng
/infra/ @acme/sre
# Docs are owned, but lightly
*.md @acme/docs
docs/ @acme/docs
# Migrations require a database-team eye no matter where they live
**/migrations/** @acme/data-platformWhat this gets you, beyond the obvious gatekeeping: an automatic answer to the question "who do I ping?" when someone opens a PR in unfamiliar territory. The reviewer assignment is no longer social negotiation. It's a file.
What CODEOWNERS does not fix is bus factor. If /services/payments/ is owned by exactly one person, you've just promoted that person from "important engineer" to "single point of failure", and now every payments PR waits on their inbox.
The actual senior-team move is owned-with-rotation: every owning team has at least three people on it, and ownership is a team property, not a person's. When somebody goes on vacation, the team still ships. When somebody leaves, the knowledge doesn't.
A team-of-one ownership entry is a hiring requisition with extra steps.
The PR Description Is The Review
The single thing that improves review quality more than anything else isn't a better reviewer. It's a better PR description.
A reviewer who knows why a change is happening can evaluate whether the change accomplishes it. A reviewer who only sees what changed has to reverse-engineer the intent from the diff, and reverse-engineering intent is exactly the work the author has already done.
Templates help here, partly because they make the right thing easy, partly because they make the missing thing visible. A PR with an empty "Risk level" section is its own warning sign.
## Why
<!-- The motivating problem. Link the ticket, but explain in one paragraph so the reviewer doesn't have to context-switch. -->
## What changed
<!-- The shape of the change, not a line-by-line replay of the diff. "Adds a new endpoint X, refactors Y to support it, leaves Z alone." -->
## Risk level
- [ ] Low: internal-only, no migration, no auth/payments touch
- [ ] Medium: user-facing behavior change, but contained
- [ ] High: touches auth, payments, data migrations, infra, or shared types
## How this was tested
<!-- Unit + integration + manual. "Tested locally" is not a test plan; explain what you actually exercised. -->
## Rollback plan
<!-- How do we undo this in production in under 10 minutes? If the answer is "redeploy the previous SHA", say so. If there's a migration involved, the answer is harder and that itself is the conversation. -->
## Anything reviewers should pay extra attention to
<!-- Self-flag the parts you're least sure about. This is not a confession; it's a signal that focuses the review where you need it most. -->The "anything reviewers should pay extra attention to" line is worth its weight on a senior team. It surfaces the parts the author already knows are weak, and it gives the reviewer permission to dig there instead of being polite. The strongest engineers I've worked alongside use it constantly. The pattern is the same every time: flag the soft spot, ask for the harder look, ship a better diff.
Reviews Have A Service Level Too
If review is a blocking activity (and it is), then review response time is part of the system, not a personality trait.
A pattern that holds up across team sizes:
- 24 hours for low/medium-tier PRs, soft target.
- 4 hours during the work day for high-tier PRs, hard target. These are the ones that block hot work and shouldn't sit.
- No review on Friday after 3 p.m. unless it's a hot fix. Friday-evening merges are how Sunday-night incidents are born.
The team that enforces this looks slow from a distance and is actually faster in aggregate, because the rework rate drops and the after-hours pages drop with it.
If your team is consistently breaking the 24-hour target, that's not a discipline problem. It's a capacity problem. Either there are too many open PRs per reviewer, or PRs are too big to review in a normal sitting, or both. Adding "review faster" as a team value doesn't fix capacity; making PRs smaller does.
Async Pairing Beats The Comment War
Every senior team eventually finds itself in the same situation: a PR with 38 comments, four threads marked resolved-then-reopened, and a tone that's drifting from "review feedback" toward "letter from the front."
This is the moment to stop typing and start a 20-minute call.
A 20-minute pairing call resolves what an entire afternoon of comment threads cannot, because most of what the comment thread is doing is reconstructing the author's mental model from text. A call lets the reviewer ask "wait, why does this even live in this service?" and get the answer in 30 seconds instead of 90 minutes of typing.
The norm worth setting: any time a review thread crosses a certain depth (different teams use different bars, three round-trips on the same line is a reasonable one), you jump to a call, decide together, and one of you summarizes the decision back into the PR thread for the rest of the reviewers and the future engineer doing archaeology in git blame two years from now.
What "Working" Looks Like
You can tell a senior PR review process is working when the boring outcomes happen reliably: small PRs, fast review cycles, clean rollbacks when something does slip, and high-risk changes that arrive at production with two owners' fingerprints on them instead of one.
You cannot tell from the inside whether you have a good process, because every team thinks their process is fine. The signal comes from the incident post-mortems. A team with a working review process has incidents that get traced back to genuinely surprising things: a third-party regression, a load pattern nobody had seen, an interaction between two changes that looked harmless. A team with a broken review process has incidents that get traced back to changes that, in hindsight, anyone could have flagged.
If your post-mortems keep producing the second kind of finding, the answer isn't to review harder. It's to review differently: small, tiered, owned, described, paired when needed.
The review isn't the gate. The review is how the team learns what it's actually shipping.
