July 9, 2026 · 5 min read
My Code Review Checklist Has Changed More in Two Years Than the Previous Ten
AI-assisted code changed what actually needs scrutiny in review. The checklist I'm running today barely resembles the one I used before.
For a decade my code review checklist barely moved: naming, structure, obvious bugs, test coverage, maybe a style nit or two. In the last two years it's been rewritten almost entirely, and the reason is that the kind of mistakes showing up in code — including my own — changed shape.
AI-assisted code tends to be syntactically clean and locally correct. It also tends to confidently implement the wrong interpretation of an ambiguous requirement, reuse a pattern from a different part of the codebase that doesn't actually fit the current context, or quietly introduce a dependency that wasn't strictly necessary because it was the most common pattern in training data, not the right one for this specific case.
What dropped off the checklist
- Basic syntax and style issues — these are now rare enough that flagging them feels like wasted review time
- Obvious off-by-one and null-check bugs — still happen, but far less frequently than they used to
- Naming convention violations — mostly self-correcting now, since the tooling tends to match existing conventions well
What replaced it
- "Does this code assume something about the requirement that wasn't actually specified?" — the single highest-value question I ask now
- "Would this still be correct if the input data looked slightly different from the example case used to write it?" — AI-generated code tends to overfit to the example
- "Is this dependency actually necessary, or is it the path of least resistance?" — unnecessary new dependencies show up far more than they used to
- "Does this match how the rest of the codebase actually works, or does it just look plausible in isolation?"
Code review used to be about catching mistakes in execution. Now it's mostly about catching confident misinterpretations of intent.
The actual time spent reviewing hasn't dropped — if anything it's gone up, because the mistakes I'm now looking for require understanding the requirement, not just the syntax. The checklist evolving is a direct consequence of the failure modes evolving, and I expect it'll keep changing shape as the tooling does.