Reviewing code you did not write

The economics of review just inverted

Review used to be roughly balanced. A change that took a day to write took maybe forty minutes to read, because the author had already done the thinking and the diff carried the shape of that thinking.

Now a 600-line diff can represent four minutes of author effort and forty minutes of yours. The person who submitted it may not have read all of it carefully themselves. You are the first human to think hard about those lines, and you are doing it under the social assumption that someone already did.

That asymmetry is the whole problem. It creates steady pressure toward the rubber stamp, and the rubber stamp is where the bad changes get in.

Rules that hold up under volume

Refuse the giant diff. A 2,000-line pull request is not reviewable by anyone, and it never was. The difference now is that it takes no effort to produce one, so the norm has to be explicit. Ask for it in slices that each do one thing. This is not politeness, it is the only way the review means anything.

Read the tests first, then ask what they do not cover. Generated tests tend to cover the path the code was written for. Look for the empty input, the duplicate, the second call, the failure of the thing it depends on.

Check the change against the intent, not only against itself. This is the big one. Generated code is almost always internally consistent — names match, structure is clean, the comments describe what the code does. Internal consistency used to be weak evidence of care. It is now free. So compare against the ticket, the spec, the actual requirement, and ask whether this solves the problem that was posed.

Hunt for removed safety. These are the highest-yield lines in any diff:

-    if account is None:
-        raise AccountNotFound(account_id)

-except ValidationError as e:
+except Exception:
+    pass

-@pytest.mark.parametrize("currency", CURRENCIES)
+@pytest.mark.skip("flaky")

A check disappears, an exception net gets wider, a type gets loosened, a test gets skipped, a lint rule gets an inline suppression. Each one may be fine. Each one deserves a sentence of explanation in the pull request, and if there isn't one, ask.

Watch the blast radius. Look at what the change touched that it was not asked to touch. A request to fix date formatting that also reorders a dictionary, renames a parameter, and updates an unrelated dependency version is three changes wearing one hat.

The question that does the most work

Pick two or three lines that look load-bearing and ask the author, plainly: why is this here, and what happens if it is not?

This is not a trap and it should not feel like one. It is the fastest way to find out whether the change is understood by anybody. If the answer is a shrug or a paraphrase of the code, the change is not ready — not because the code is wrong, but because nobody yet owns it.

Two norms worth arguing for

The author owns the diff. Whoever submits it is responsible for every line, whatever produced them. "The model wrote that part" is not a defence and should not be treated as one. The practical form of this rule: if you cannot explain a line in review, do not submit it. Take the ten minutes to understand it or take it out.

A reviewer can say "I don't understand this yet" at no cost. If admitting confusion is socially expensive on your team, you will get approvals instead of reviews, and you will not find out for months. Make the phrase normal by using it yourself, in public, on code you could probably work out if you tried.

Where the model helps in review

Using a model to help you review is genuinely useful, with one boundary. Asking it to summarise an unfamiliar diff, list every call site of a changed function, or explain what a dense regex does — good, fast, low risk, because you can verify the answer.

Asking it whether the change is correct — that is the judgement you were brought in to make, and it does not have the context that makes the judgement possible: what this system is for, what broke last quarter, what the on-call rotation can tolerate. Use it to reduce your reading cost, not to replace your reading.