The rule of trust
what is always checked and what depends on the case
What it is
Checking every line is impossible — the work would stop. Checking nothing is not allowed — the project stops being yours. You need a level in between, and it is set by a rule.
The same things are always checked, whatever the task. Everything else goes by the cost of a mistake (article 1.5).
The four checks that are always done
They take a couple of minutes and catch most of the trouble.
1. Run it
Obvious, and skipped anyway. Code that has not been run does not work — that is not pessimism, it is statistics. And you run the case the whole thing was for, not just any case.
2. The diff
Look at what changed, not at what came out (article 2.13). Start with
--stat: how many files, how many lines. A mismatch with your expectation is
a reason to stop.
git diff --stat3. An unhappy case
At least one: empty data, an unreachable network, garbage input. That is where the errors live that a run does not find, because what gets run is usually the happy path.
4. The question "what does this do"
If you cannot explain the accepted code in two sentences, it is not yours yet (article 1.2). You can explain it to yourself, out loud, or in the commit message.
What to tell the AI
Three of the four checks the AI can prepare itself:
Name three cases worth checking by hand to be sure
this change works. At least one of them failing.Explain in two sentences what the code you just added does.The fourth — the diff — is yours alone: that is the reviewer's job.
What gets checked on top
Beyond the four mandatory ones, the level of checking is set by the task.
| What the task looks like | What to add |
|---|---|
| Touches user data | a rehearsal on a copy, a way back |
| Irreversible | a plan in advance (3.10), a mini-spec (3.15) |
| The error would be invisible | tests (4.6), logs at the key points |
| A rare library | a check against the documentation (4.8) |
| More than one file | reading the diff line by line |
| Editing code that has worked for a long time | a test before the change, to pin the behaviour down |
That last line is the most underrated technique. A test written before a change records what used to work and tells you at once if that broke.
What to look for
Checking came down to running it. The most common form of self-deception: ran it, answer looked right, accepted. One scenario out of ten has been checked (article 1.6).
Nobody looked at the diff. If a change is accepted on the strength of the AI's reply rather than the diff, the reviewer's chair is empty.
The level of checking chosen by feel. "This one looks simple" is not a criterion. The criteria are reversibility and visibility.
Checking postponed to the end. Five changes in a row, then a check of everything at once — and now it is unclear which of the five broke it. Check after each one.
Cheat sheet
Always: run it · the diff · an unhappy case · "what does this do".
The four checks take two minutes and don't depend on the size of the change.
Beyond that — by the cost of a mistake: reversibility and visibility.
Editing long-working code — first a test for how it worked.
Check after every change, not after five.