A diff shows you what changed. It is silent, by construction, about what somebody decided not to handle, and that silence is where most of the expensive bugs are hiding.
The habit of reading absence
Before reading the logic of a change, we now ask what inputs it does not mention. A function that parses a date and handles three formats: what happens to a fourth. A function that processes a list: what happens to an empty one, and does the answer differ from what happens to a list of one.
A short list of places nothing is ever written
- The empty case — zero items, zero characters, zero results from a query that usually returns some.
- The concurrent case — two requests for the same resource landing at the same moment.
- The partial case — a batch job that dies after processing sixty of a hundred records.
- The second time — the same action, run again, deliberately or by retry.
None of these show up in a diff as a missing line, because there is no line to be missing. They show up only if the reviewer goes looking.
Why this is harder with generated code
A model tends to implement the case it was asked about thoroughly and competently, and simply not raise the cases it was not asked about. That is not a flaw particular to models — junior engineers do the same thing — but the volume of code arriving without that conversation having happened out loud has gone up, so the reviewer's job has shifted from "check the logic" to "check the coverage of the specification against reality" more than it used to be.
The bug is never in the code you're looking at. It's in the code that isn't there, for a case somebody didn't think of.
A small practical trick
We ask, out loud in review, "what's the shortest input that would break this?" before reading a single line. It takes thirty seconds and it reliably produces the empty case, the null case, or the duplicate case before anyone has looked at the implementation, which means the reading that follows is targeted rather than a blind scroll.
What this replaced
A checklist we used to run through line by line, which caught the same categories eventually but took three times as long and stopped being read carefully after the fourth review of the week. Asking the question first is faster because it gives the reviewer something specific to look for.