Agents verify; people decide. Most teams running AI code review today have it the other way around. They point a model at the diff, ask it whether the change is good, and leave a human to skim the result and click approve.

The model reads every line, never gets tired, and holds the same standard on every PR. What it doesn’t have is your codebase’s standards. It doesn’t know them, and no matter how well you instruct it, it doesn’t always follow the ones you write down.

It never saw what was decided, has no context for previous decisions, can’t tell you not to build the thing, and can’t be held accountable. A diff can’t give it any of that. Judgment needs intent, and accountability needs a person.

So what does a code review look like when verification goes to agents and judgment stays with people? At Aviator, we’ve been building that review into Aviator Verify. Below are its seven parts, in order.

Every change gets checked against two layers. Acceptance criteria describe what this change should do. Invariants are the codified rules of your engineering org or team: the standards that are always true, whatever the change. 

Criteria without invariants leave your standards to memory. Every engineer has to remember every standard, or someone has to catch the obvious agent mistakes in code review. Invariants without criteria give you code that follows the rules but doesn’t consider what the result should be, so the agent strays, overengineers, or solves the wrong problem.

Source link