What we look for in a code review

Code review has a failure mode where it becomes a formatting argument. Nobody learns anything, the real risks pass unexamined, and the author concludes that review is theatre.

Splitting review into two layers fixed this for us.

The machine layer

Formatting, lint, type errors, obvious null paths, missing indexes on new foreign keys, secrets in a diff, dependency advisories. Automated review runs on every change before a human opens it.

This is not a small saving. It removes almost everything that used to generate low-value comments, and it never gets tired on a Friday afternoon.

The human layer

What is left is the part that requires knowing the system and the business:

• **Is this the right change?** The code can be flawless and solve a problem that should have been solved elsewhere.
• **What happens when it fails?** Every network call, every write. What does a user see when this times out halfway?
• **What does this cost at 100x?** Fine at current volume, catastrophic at ten times it - and nothing in the diff says so.
• **Will the next person understand why?** Not what - the code says what. Why this approach over the obvious one.
• **What is now harder to change?** Every abstraction closes doors as well as opening them.

On generated code

The same review applies, with one addition: does the author understand it? Code that cannot be explained in review does not merge, regardless of where it came from. That single rule is what keeps AI assistance from turning into a maintenance problem later.