choose-the-right-code-review

Choose the right code review

How much review a change needs is not a judgement made in the moment by the person who wrote it. It is decided by what the change touches, before the change is written, by a table.

The reason is simple: the author is the worst-placed person in the building to estimate the risk of their own change. Everything they thought of is already handled. The risk lives entirely in what they did not think of.

When to use this

• A change is finished and you are about to ask for review
• You are deciding whether "this is tiny, just merge it" is true
• You are assembling reviewers and need to know how many and which
• A change has grown since it started and may have crossed a line

The routing table

Level	The change touches	Reviews	One of them must
1	Cosmetic, documentation, anything that never reaches production	1	Look at the rendered result, not the source
2	Code in production, service configuration, build pipelines, dependencies	2, independent	Judge whether the evidence could have failed
3	Authentication, permissions, money, customer data, schema migrations, deletions, network and firewall rules, certificates, anything that runs everywhere at once	3, independent	Actively try to break it

Classifying without debate

If the change touches any of these, it is level 3. No discussion, no weighing:

• login, passwords, tokens, sessions, permissions, roles
• amounts, prices, refunds, balances, invoicing
• customer or personal data
• schema changes, deletions, table drops, bulk updates
• network rules, firewall, address translation, routing
• certificates and their renewal
• anything applied to every site, tenant or node in one action

Touches production but none of the above → level 2. Never reaches production → level 1.

⚠️ The size of the diff does not appear anywhere in this table. A one-line change to a permission check is level 3. A two-thousand-line documentation rewrite is level 1.