Spending a review budget

9 min read

Figure

You have forty minutes, and the diff has 700 lines

This is now the normal situation, and the normal response (start at the top, read until tired, approve) is the worst available allocation. Review is a scarce resource being spent, and spending it evenly across a diff means spending most of it on the parts that could not hurt you.

What follows is a triage procedure. It is not more rigorous than reading everything. It is what you do because you cannot.

Sort the files by what they can cost

Before reading a line, open the file list and put every file into one of three tiers.

Tier 1: read every line, twice. Anything touching money, authentication, authorisation, deletion, personal data, or another company’s system. Anything that writes to a database without a transaction. Anything that sends a message to a human. Migrations. Configuration that differs between environments. Concurrency of any kind.

Tier 2: read carefully once, and check the boundaries. Business logic, request handlers, anything with a conditional in it, anything that transforms data.

Tier 3: skim for shape. Tests, fixtures, formatting, generated clients, documentation, translations, lockfile churn.

A typical 700-line diff is 80 lines of tier 1, 150 of tier 2, and the rest tier 3. Spend thirty of your forty minutes on those first 80 lines, and say in the review that you skimmed the rest. Saying so is the important half: an approval that silently means “I read a third of this” is the thing that makes review meaningless as a signal.

Read in this order

The description and the linked ticket. What is this supposed to do? If you cannot state that in one sentence before reading code, ask, and stop. Reviewing without knowing the intent means you can only check the change against itself, which is exactly the check that stopped working.
The migration, if there is one. It is the only irreversible part.
The interface changes. New public functions, changed signatures, new API fields, new configuration keys. These are commitments; the implementation behind them can be fixed next week and the interface cannot.
Tier 1 files, line by line.
The tests: not to check they pass, but to ask what they do not cover.
Tier 2, then a skim of tier 3.

Three questions that find more than reading does

”What did this change that it was not asked to change?” Scan the file list against the ticket. A request to fix date formatting that also touches a dependency version, a serialiser and a config default is three changes wearing one hat, and the two you did not expect are the ones nobody has thought about.

”What is the worst input for this?” Not the wrong input: the worst one. Empty, enormous, duplicated, out of order, arriving twice, arriving from a different timezone, containing a newline. Pick the one that seems most awkward and trace it through by hand.

”Why is this line here?” Choose two lines that look load-bearing and ask the author, plainly. This costs you thirty seconds and it is the single highest-yield question in review, because it tests whether the change is understood by anybody at all.

Time-box it, and say when you ran out

Set a timer for forty minutes. When it goes, stop, and write what you actually did:

Read the migration, billing/charge.py and auth/session.py line by line. Skimmed the tests and the generated client. Did not review the frontend changes; someone who works in that area should.

This is not an admission of failure. It is the only thing that makes an approval mean something specific, and it makes the gap visible so somebody can fill it. A team where every approval carries this note is a team that can see its own review coverage.

When to refuse

Refusing to review is a legitimate and underused action. Do it when the diff is too large to review meaningfully, when it does three things at once, when the description does not say what it is for, or when you do not know the area well enough and someone else does.

The phrasing that keeps this collegial: “I can review the API and storage parts properly; I would be rubber-stamping the rest. Can we split it, or can someone from the payments side take those files?”

That sentence protects the reviewer, the author and the system, and it is a normal thing to say. Teams where it is not normal do not have fewer unreviewed changes; they have the same number, silently approved.

Every lesson here is open. Your progress is recorded once you pass the AI at Work exam.

A reviewer with limited time reads every line of a 700-line diff at a uniform pace, finishes, and approves. A colleague reads only the migration, the auth changes and the payment handler, and writes down what they skipped. Why is the second review more useful?

Pick the one you would defend. Your answer stays private.