# How to Kill the Code Review Ankit Jain, Aviator | AI Engineer World's Fair 2026 | 16:26 Source: https://www.youtube.com/watch?v=YgEv7IQzGdM Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/how-to-kill-the-code-review Published: 2026-08-17 Tags: agents, human-in-the-loop, testing, workflows ## TL;DR - Teams have already reduced line-by-line review, while AI-generated code is increasingly reviewed by AI and skimmed by humans. - Code review also carries alignment work, including knowledge sharing, mentorship, architectural feedback, and onboarding, so that work needs a new review surface. - Ankit proposes capturing agent sessions, turning decisions into acceptance criteria, combining them with a registry of recurring review comments, and verifying the result against a live preview. ## Summary Ankit Jain argues that the old code review process is already breaking down. Code volume has risen, review waits have grown, and more than 30% of changes merge without review. When an AI writes code and another AI reviews it, a human often skims the exchange and merges. Jain says this setup misses what teams actually need from review. Review is also where people share knowledge, teach one another, discuss architecture, and align on what the software should do. His replacement keeps that alignment work in the agent session. The session becomes acceptance criteria, recurring human review comments become an AI slop registry, and both feed a test plan. Aviator's verification system runs that plan against a live preview and collects evidence such as screenshots and database snapshots. Reviewers then inspect intent, architectural decisions, and observed behavior instead of reading every diff line by line. ## Key ideas ### The old review bottleneck has already been bypassed [01:19](https://www.youtube.com/watch?v=YgEv7IQzGdM&t=79s) Jain says teams have already stopped reviewing every line of code. He cites 861% code churn, a rising incidents-to-PR ratio, review times that are four times longer than before, and more than 30% of changes merging without any review. The result is a new bottleneck: coding has become faster while review work remains stuck. AI adds another complication. An AI agent writes the code, an AI reviewer comments on it, and the human mostly skims the exchange before merging. Jain's conclusion is direct: when AI reviews and nobody reads, the workflow has been configured incorrectly. ### Code review carries alignment work that correctness tools cannot replace [03:02](https://www.youtube.com/watch?v=YgEv7IQzGdM&t=182s) Jain separates semantic accuracy from alignment. Reviews can catch bugs, security issues, and convention violations, but they also let teams share knowledge, mentor engineers, discuss architecture, onboard people, and collaborate. He says this alignment work was missing from his earlier five-layer trust model. A solo developer working in a white-coding setup may not need this talk, but teams still need a way to exchange decisions and context. Better tooling can handle more of the correctness work. The collaboration and alignment part still has to survive when line-by-line reading declines. ### A specification written once recreates the waterfall model [04:21](https://www.youtube.com/watch?v=YgEv7IQzGdM&t=261s) Jain says spec-driven development often follows the old waterfall sequence: requirements, specification, implementation, and verification. The problem is the lack of a feedback loop. People still interact with coding agents because the original specification leaves decisions unresolved, and implementation reveals more issues. Yet teams rarely update the specification after the work begins. Jain also points out that language models are not deterministic, so a completed spec does not guarantee one predictable implementation. He thinks spec-driven methods contain useful ideas, especially around intent, but they do not cover the back-and-forth of everyday software development. ### The most important implementation decisions are in prompts that teams discard [05:36](https://www.youtube.com/watch?v=YgEv7IQzGdM&t=336s) Intent can appear in a Jira ticket or product requirements document, but Jain says the most important decisions now happen in the prompts exchanged with an agent. A developer starts from a ticket, then clarifies requirements, rejects approaches, and makes tradeoffs during the session. Those choices shape the implementation. The current workflow opens a pull request and throws the prompts away. Jain wants the session retained because it contains the reasoning that a diff cannot fully recover. That retained context can explain what the team meant to build and which alternatives were considered. ### A registry of recurring review comments can turn human feedback into guardrails [06:53](https://www.youtube.com/watch?v=YgEv7IQzGdM&t=413s) Jain introduces the AI slop registry for semantic accuracy. Manual reviewers often identify the same classes of problems repeatedly. Those comments can be captured and codified so the system can detect them automatically in later changes. The registry improves as people add more review experience, functioning as a layer built on top of a standard language model. Each recurring comment becomes a guardrail that reviewers do not have to repeat. Jain is clear that this requires initial effort. He describes the payoff as a J curve, with the registry taking time to build before it reduces repeated review work. ### Agent sessions can become acceptance criteria and executable test plans [08:00](https://www.youtube.com/watch?v=YgEv7IQzGdM&t=480s) Jain combines the alignment and semantic accuracy halves into one loop. The system captures decisions from the user's session and turns them into acceptance criteria. Those criteria are combined with the maintained AI slop registry to create a test plan. A verification system then starts a preview and checks whether the requested behavior works end to end. Jain suggests using a language model to create and maintain the test plan because that work is tedious. The human still governs the process by reviewing the criteria and plan. The resulting tests can be written in English and shared with product managers and designers. ### Verification should be deterministic where possible and use agents when necessary [11:51](https://www.youtube.com/watch?v=YgEv7IQzGdM&t=711s) Jain does not claim that every check can be deterministic. His approach uses deterministic verification where the system allows it, with a language model as a fallback. For a new payment form, an agent can browse the application, fill out the form, and capture screenshots. The system can compare that evidence with database snapshots to assess whether the acceptance criteria were met. This produces material that a reviewer can inspect instead of relying on the code diff alone. The review then covers the intended behavior, the decisions made during the session, rejected approaches, architectural choices, and evidence from verification. ### Teams should mine past review comments for repeatable rules [14:12](https://www.youtube.com/watch?v=YgEv7IQzGdM&t=852s) Jain's practical exercise is to mine the last 1,000 review comments and extract the repeatable ones into an AI slop registry. He says a large share of review comments are repeated from one change to another. Each captured rule compounds across later pull requests because the same comment no longer needs to be written manually. This can preserve semantic accuracy while leaving human reviewers more time for collaboration and architecture. Jain also warns that the registry takes work at the start. His proposed replacement for code review is therefore a changed surface: review intent, acceptance criteria, architectural decisions, and verification evidence. ## Notable quotes - "So, when AI reviews and nobody reads, we have configured the wrong thing." (02:42) - "But, code review is also about alignment." (03:23) - "But what we do today is we create a change, we create a pull request, and then we throw away the prompts." (06:15) - "So, now reviewers are reviewing the intent, not the diff." (12:57) - "Go home and mine your last 1,000 review comments and build out a AI slot register for the things which are repeatable." (14:18) ## Tools & references mentioned - Aviator - Verify - GitHub - Jira - PRDs - Cloud Code - Codex - Cursor - Mondrian - Google - Windows - test-driven development - behavior-driven development ## Who should watch - You work on a team where AI-generated changes are increasing faster than people can review them. - Your review comments repeat the same conventions, defects, or maintainability concerns across many pull requests. - You want to preserve architecture discussions and mentoring while moving routine correctness checks into automated verification.