Review depth should match risk

Not every PR deserves the same review. A copy fix, mechanical dependency bump, data migration, auth change, billing change, and deletion path do not carry the same blast radius.

The question

Start with: what can this break?

Then review to that level.

For low-risk mechanical work, the review may be mostly verification: does the change match the obvious intent, do checks pass, is anything surprising?

For high-risk work, slow down. Trace failure modes. Look at rollback. Check tests against the real risk. Ask whether the PR changes data, permissions, money, availability, or user-visible behaviour.

Advice mode vs approval mode

Draft PRs and early reviews are for shaping the approach. Final review is for deciding whether the scoped work can ship.

A lot of review pain comes from mixing those modes: the author asks for approval, the reviewer starts brainstorming a different architecture. If you are in advice mode, say so. If you are in approval mode, review the slice in front of you.

Make approvals legible

On a non-trivial PR, "Approved" is less useful than:

Approved. I checked the migration path and rollback notes; I did not review the UI copy.

That tells the team what your approval covers.

See also

• Code review checks the scoped work
• Track review health as flow
• Code review is a delivery system