AI Code Review Reimagined: Why Machines Should Verify, People Should Decide

Today's AI code review often gets things backwards. Teams deploy a model to scan a diff, ask it whether the change is acceptable, and watch a reviewer rubber-stamp the result. But machines lack what matters most: knowledge of your team's actual standards, context from past decisions, and the ability to be held accountable.

A better structure flips the model—agents verify against codified rules; humans judge based on intent, decisions, and evidence. The difference is profound: instead of line-by-line scanning, reviewers examine whether a change meets what the team decided to build.

Two Layers: Criteria and Invariants#

Effective verification rests on two foundations. Acceptance criteria describe what a specific change should accomplish—tied to its moment and context. Invariants are the standing rules that apply everywhere: always use the Money type for currency, never write directly to the users table, emit a counter on every error path.

Many teams skip invariants entirely, leaving standards locked in senior engineers' heads. They reappear as repeated review comments, with AI systems making the same mistakes again because the rule was never formally captured anywhere a verifier could check it.

Invariants become an evolving registry drawn from PR history, team documentation, and real-time feedback. They work best when ownership is clear—each invariant belongs to a specific team, goes live only after approval, and stays scoped to contexts where it actually applies.

The Seven-Part Framework#

1. Invariants (defined upfront): The team's standing rules, extracted from past reviews and codified.

2. Intent and acceptance criteria (captured live): Why the change exists and what it should do—documented during the coding session itself, not as a separate spec.

3. Core decisions (recorded with ownership): The fork-in-road moments where the implementation could have gone another way, labeled with who decided.

4. A test plan (generated at submit): Requirements translate into scenarios that merge criteria and applicable invariants.

5. Evidence (gathered in a real environment): Screenshots, database state, logs, and console output prove each verdict. For UI changes, verifier agents actually navigate the interface.

6. A review (decided by a person): The reviewer examines intent, decisions, and evidence side-by-side, then approves, requests changes, or waives a failed invariant with reasoning.