Ankit Jain’s team at Aviator merges four times more pull requests than it did a year ago. Almost none of that code was typed by a human. The team tried the obvious fixes: AI review tools, stricter checklists, more reviewers. None of it worked. Review stayed the slowest step in shipping.
What worked was giving up line-by-line reading entirely and building a verification layer around intent.
The framework Jain describes has five steps. Three of them are structural changes to the review process. Two are organizational decisions about who owns the rules. The combination shifts code review from a reading exercise to an evidence-based verdict.
Move Human Judgment to the Front
Conventional review puts human attention at the end. Someone reads 400 lines, tries to reverse-engineer what the change was supposed to do, and decides whether it looks right. At four times the volume, that puts the reviewer in a position where the ticket description only helps if the team maintains good tickets. Most teams do not.
Jain’s team moved human judgment to the front. Before a single line is generated, they review the intent: acceptance criteria, constraints, edge cases. A senior engineer’s attention is worth the most at that point, because a wrong idea costs almost nothing to fix before code exists.
Then they treat that intent as a contract. Each acceptance criterion gets a deterministic verdict with evidence attached. The reviewer sees five criteria verdicts with screenshots and request traces. No 500-line diff.
The principle is straightforward. If you cannot say what a change should do before it exists, reading it afterward will not tell you.
Mine Your Review Comments
Every team has standards that live in senior engineers’ heads. They get enforced one review comment at a time. Look through any team’s review history and you will see the same comments written over and over: use the Money type for anything with a currency, no direct writes to the users table, structured logger only.
At 4x PR volume, repeating those comments by hand becomes a bottleneck of its own. Jain’s team went back through their recurring review comments and turned them into invariants: reusable rules that a machine enforces on every change.
The starting point is concrete. Mine your last 1,000 review comments. The 20 you repeat most are your first invariants. You are not inventing rules. You are writing down the ones you already have.
A good invariant is boring and specific. “Use the Money type for anything with a currency” qualifies. “Write clean code” does not.
The Five Steps
The two practices above fit into a five-step framework Jain calls Argue, Capture, Codify, Debate, Own:
- Argue. Let agents challenge each other’s solutions before the pull request exists, when changing course is cheapest.
- Capture. Record the intent and acceptance criteria. Put them on the pull request.
- Codify. Turn the comments your team keeps repeating into invariants.
- Debate. Spend human review time on the decisions, not the diff.
- Own. Decide who owns the rules that verify the code.
Steps 1 through 3 are structural. They change what gets reviewed and how. Steps 4 and 5 are organizational. They change who reviews and who maintains the verification layer.
The Timeline Is Honest
Jain is direct about the transition cost. Month one will feel like double work: the team reviews code and builds invariants at the same time. Month two, the register catches enough that reviews shrink. Month three, the reviewer reads intent, not code.
That three-month ramp is worth calling out because most process changes promise immediate returns. This one promises a worse month before a better one. The investment is in building a register of rules that compounds over time.
The Question That Remains
The framework has a step most teams will skip: Own. Who maintains the invariants? Who decides when a rule is wrong? Who updates the register when the codebase changes?
If invariants are team standards written down, they need the same governance as any other standard. Someone has to own the register the way someone owns the test suite. Without that ownership, the invariants drift, the verification layer rusts, and the team falls back to reading diffs.
We have written about the intent layer as an emerging governance surface. Jain’s framework adds the practical mechanics: the five steps, the timeline, and the specific question of ownership that determines whether the layer holds.
The seed is small. Pull your last 1,000 review comments. Find the 20 that repeat. Write them down as invariants. The register starts there.
This analysis synthesizes We Stopped Reviewing Code and Started Verifying Intent (Ankit Jain, Aviator/Tessl, October 2026).
Victorino Group helps teams shift code review from reading diffs to verifying intent. Let’s talk.
All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →
If this resonates, let's talk
We help companies implement AI without losing control.
Schedule a Conversation