Pull request diffs are where most review decisions begin. A good reviewer reads the diff as a story about change: what changed, why it changed, and what that change implies for safety, correctness, and maintainability. The lines themselves matter, but the meaning behind them matters more.
Look for scope changes
A small diff can hide a big effect if it changes a shared helper, a permission check, or a data conversion layer. The first thing to ask is whether the patch is actually local or whether it changes behavior across the system.
Look for trust boundary changes
- New inputs from users, webhooks, or external APIs
- New writes to databases or caches
- New authorization logic
- New file, network, or process access
Look for failure behavior
Security risk often appears when code fails. Ask whether the diff fails open, fails closed, retries too aggressively, or hides the error in a way that makes detection difficult. If the code breaks, the reviewer should know what kind of break it causes.
Read the surrounding context
The safest way to review a diff is not to read only the changed lines. Open the surrounding functions, related files, and tests. That gives you the context needed to see whether the change is safe in the larger system.
What to flag quickly
- Changes to auth or permission checks
- New secrets or credentials handling
- Broad try/catch blocks that hide failures
- Any code that makes more data visible than before
The goal of diff review
Diff review is not about catching every possible issue. It is about finding the risk that actually matters before the merge. If you can reliably spot the risky part of the patch, you can review faster without reviewing carelessly.