Ankit Jain (Aviator) argues that code review as traditionally practiced has effectively ended: over 30% of changes merge without review, and reviewed changes wait four times longer than before. He describes an emerging workflow where AI writes and reviews code in a web UI while a human skims and merges, contending that AI reviewing with no one reading is a misconfiguration. He revises his earlier five-layer trust model, noting that review was never only about correctness — it also carries knowledge sharing, mentorship, architectural feedback, and onboarding. He critiques spec driven development as a return to 1970s waterfall when specs lack feedback loops, and observes that key decisions end up in discarded prompts. His proposal: capture AI coding sessions, convert decisions into acceptance criteria, build a registry from a team's own recurring review comments, and generate a test plan run by a verification system against a live preview — making the review surface intent and evidence rather than the diff. # Observation Document: "How to Kill the Code Review — Ankit Jain, Aviator" ## Explicit Self-Description by Creator - **Role and company**: Speaker introduces himself: *"I'm Ankit, co-founder of Aviator."* - **Company product claim**: *"At Aviator, we are building AI code verification platform."* He positions the talk as drawing on concepts built into that product: *"we'll bring in some of the ideas and concepts… that we build in our product."* - **Prior public writing**: References an earlier authored piece: *"a few months ago, I wrote a post on LinkedIn… about how to kill code review, creating a framework, a five-layer trust model."* He explicitly critiques his own past model: *"I got some things right, and I got some things wrong."* - **Product pitch**: Ends with an explicit invitation: *"we are piloting our new product called Verify. Please join and be our early design partners."* ## Intended Audience - **Engineering practitioners working in teams**, explicitly stated: *"if you're doing white coding, you're working as a solo project, this is not a talk for you. If you are working in teams, which I believe most of you folks are…"* - **Engineers already using AI coding/review tools**: *"everyone is probably using some form of AI reviews today"*; references *"cloud code, codex, cursor"* (evidently Claude Code, Codex, Cursor). - **Audience with code review history to mine**: homework assignment — *"Go home and mine your last 1,000 review comments and build out a AI slop registry."* ## Claimed Scope of the Talk - **Topic**: How to move beyond line-by-line code review, decomposed into **alignment** (collaboration, knowledge sharing, mentorship) and **semantic accuracy** (correctness, bug detection). - **Framework content**: Covers spec-driven development critique (comparing it to the 1970s waterfall model), where intent lives (Jira tickets, PRDs, prompts), and a proposed loop of **session-captured acceptance criteria + AI slop registry → test plan → verification**. - **Historical framing**: Cites *"In 2006 was when Google launched Mondrian internally and they made formal code review as a thing,"* and that early Windows versions *"were actually built without reviews."* ## Observable Presentation Patterns (Demonstrated, Not Claimed) - **Conference-style talk format**: Opening ("Hey everyone. Thanks for joining in"), closing applause (*"[applause]"*), and a reference to another speaker: *"the situation… I think Dex was talking about yesterday."* - **Vendor-adjacent thought leadership**: Substantive conceptual argument (trust layering, alignment vs. accuracy) that funnels toward a product recommendation: *"this is where I would recommend you folks can come and try out our product."* - **Stated statistics without cited sources**: *"There is 861% code churn," "over 30% of changes are actually getting merged without a review at all," *"four x the time… waiting for the reviews"* — presented as evidence, sources not named in transcript. - **Practice-oriented takeaway structure**: Ends with a memorable summary line: *"code review is not just about code review, it is about getting the alignment."* ## Channel Identity Signals (Evidence-Based Only) - The video demonstrates a channel publishing **conference talks by industry practitioners/founders** on **AI-era software engineering practices**, in this case a founder presenting analysis plus product piloting. No channel name or broader channel description appears in the supplied material; identity evidence here is limited to this single video's speaker, framing, and audience address. # Delivery Observations — "How to Kill the Code Review" (Ankit Jain, Aviator) ## Tone - **Conversational and informal**: The talk opens casually — > "Okay. Ooh, hello. Hey everyone. Thanks for joining in." — and stays that way throughout. - **Light humor / audience rapport**: > "Today, uh we will be talking about how to kill the code reviews. Everyone's favorite topic." - **Self-critical candor**: He openly corrects his earlier work: > "I got some things right, and I got some things wrong." ## Fillers and Hedging - **Frequent filler words**: "uh," "you know," "kind of like," "like" appear pervasively, e.g., > "there's kind of like, you know, maybe two or three AI coding agents." - **Hedges soften claims**: > "It's kind of like where you express what we want to do." ## Recurring Phrases and Rhetorical Habits - **"So, let's..." as a transition device** (repeated pivot): > "So, let's just talk about the problem." / "So, let's just kind of like dive into alignment." / "So, let's just take a step back." - **Rhetorical questions to the audience**: > "Where is human here in the loop?" / "Who's going to look at that?" - **Imagined audience dialogue**: > "you're saying, 'Hey, Ankit, okay, I understand the alignment part...'" - **Repeated framing sentence**: > "Code review is not just about code review" — appears mid-talk and as the closing takeaway: > "if you remember one thing from today, remember code review is not just about code review, it is about getting the alignment." ## Teaching Habits - **Historical anchoring**: Cites 2006 Google Mondrian, early Windows, and the 1970 waterfall model to contextualize points. - **Audience-scoping / direct address**: > "If you're doing uh white coding, you're working as a solo project, this is not a talk for you." - **Actionable homework assignment**: > "So, here's a homework for everyone. Go home and mine your last 1,000 review comments." - **Concrete examples to ground abstractions**: The payment-form verification walkthrough (screenshot capture, database snapshots). - **Memorable aphorisms / soundbites**: > "when AI reviews and nobody reads, we have configured the wrong thing." / "It's deterministic where it can be, but LLM where you must." / "Every recurring comment is now a guardrail that you don't have to review again." / "reviewers are reviewing the intent, not the diff." ## Structure and Communication Patterns - **Problem → framework → walkthrough → pitch**: Problem stats (861% churn, 30% unreviewed merges), conceptual framework (alignment vs. semantic accuracy), product walkthrough, then product pitch. - **Two-part taxonomy** used as an organizing spine: alignment and semantic accuracy, later merged: > "It is two halves of the same problem." - **Explicit closing summary technique**: > "if you remember one thing from today, remember..." - **Product promotion integrated late**: > "this is where I would recommend you folks can come and try out our product" and the Verify pilot mention — disclosed openly as the speaker's own company from the start ("I'm Ankit, co-founder of Aviator"). ## Uncertainty Notes - Timestamps are absent; exact repetition counts of phrases like "kind of like" cannot be verified, only that they recur throughout. - Audience reactions (laughter, engagement) are not observable in the transcript, so claims about rapport rest on wording alone, not audience response. # Observation Document: "How to Kill the Code Review — Ankit Jain, Aviator" ## Speaker - **Ankit Jain**, co-founder of Aviator (an AI code verification platform), is the sole speaker. ## Context of the Talk - Builds on a previous LinkedIn post by Jain proposing a **five-layer trust model** for merging code without line-by-line review. - Jain states: "I got some things right, and I got some things wrong" — notably, the earlier model missed the **alignment** function of code review. ## The Problem as Framed - Code volume is increasing; teams struggle to keep up. - Claims cited (attributed to Jain, no external sourcing given in talk): - **861% code churn** increase. - **Incidents-to-PR ratio is increasing**, implying reviews are ineffective. - Review median time increasing; **4x more time** spent waiting for reviews. - **Over 30% of changes merged without any review**. - Provocation: "The reality is we've already stopped reviewing it." ## Critique of AI Review Workflows - When AI writes and AI reviews code, humans end up skimming and merging: "Where is human here in the loop?" - Stated conclusion: "When AI reviews and nobody reads, we have configured the wrong thing." ## Historical Framing - Code review is only ~15–20 years old; **Google launched Mondrian internally in 2006**, formalizing code review. - Early Windows versions were built without reviews. ## Central Thesis: Alignment vs. Semantic Accuracy - Code review serves two functions: - **Semantic accuracy**: catching bugs, conventions, security issues — improvable with tooling. - **Alignment**: knowledge sharing, mentorship, architectural feedback, onboarding, collaboration — "the most important aspect" that **must survive**. - Explicit caveat: the talk does not apply to solo/vibe-coding projects. ## Critique of Spec-Driven Development - Compares spec development to the **1970 waterfall model**: requirements → spec → implement → verify, with **no feedback loop**. - Two flaws stated: - The spec is written before everything is known; interactions with agents capture what the spec missed. - "LLM is not deterministic. It's going to make decisions itself." - Verdict: great methodology, but "falls short in day-to-day software development." - Carry-forward insight: **intent** lives in Jira tickets, PRDs, and — most importantly — **prompts**, where real decisions are made. Current practice throws prompts away at PR creation, which "is one of the things that we need to change." ## AI Slop Registry (Semantic Accuracy Mechanism) - Manual reviews repeatedly identify the same issues; these should be **codified into a registry**. - The registry "learns over time" from human review feedback. - "Every recurring comment is now a guardrail that you don't have to review again." - Acknowledged cost: "It does follow a J curve. Pain is real" — registry creation takes upfront time. ## Combined System (Alignment + Accuracy) - Flow: captured **session decisions → acceptance criteria → test plan (criteria + invariants) → verification**. - Verification spins up a preview and tests end-to-end: "Even if the code looks right, does it actually work?" - **Test plan creation via LLM** recommended since manual test maintenance is "painful." - Framed as closer to **behavior-driven development**; test plans in English are shareable with PMs and designers. - Design principle: "deterministic where it can be, but LLM where you must" — LLM as fallback. - Example: new payment form verified by an AI agent browsing, filling the form, capturing **screenshots and database snapshots** as evidence. ## Key Claim: The New Review Surface - "Reviewers are reviewing the intent, not the diff." - Critical qualification: the test plan must be built from **sessions, not code** — referencing a point "Dex was talking about yesterday": an agent building its own test plan from its own code won't catch issues. - Architectural discussions still happen — "you've moved one level above." ## Prescribed Homework & Close - Homework: "Mine your last 1,000 review comments and build out an AI slop registry for the things which are repeatable." - Closing takeaway: "Code review is not just about code review, it is about getting the alignment." - Product pitch: piloting **Verify**, seeking early design partners, combining alignment tooling and AI slop registry for semantic accuracy. # Speaker Attribution & Provenance Record ## Video - **Title:** How to Kill the Code Review — Ankit Jain, Aviator - **ID:** `01a15ca7-d465-78ca-a5f8-31e3f487e8ac` ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | **Ankit Jain** | **Creator / Presenter** — sole speaker | Self-introduction: *"I'm Ankit, co-founder of Aviator."* Delivers the entire talk; no other speakers in transcript. | | Audience | Non-speaking (applause noted at end) | `[applause]` | ## Referenced Sources & Third-Party Claims - **Speaker's prior LinkedIn post:** a "five-layer trust model" on killing code review, described as "a few months ago" — author states he "got some things right, and I got some things wrong." - **Google Mondrian (2006):** cited as origin of formal code review at Google. - **Waterfall model (1970):** compared to spec-driven development. - **Statistics (unsourced, presenter-asserted):** 861% code churn; rising incidents-to-PR ratio; 4x time waiting for reviews; over 30% of changes merged without review. - **Third-party talk reference:** an unspecified speaker "Dex" mentioned as discussing yesterday that an agent building both code and test plans won't catch issues. - **Named tools (mention only):** Claude Code ("cloud code"), Codex, Cursor. ## Promotional Segments — Flagged - **Product promotion:** throughout, the talk references Aviator's *"AI code verification platform"* and the system "we are building." - **Explicit call-to-action (promotional):** - *"you folks can come and try out our product"* (re: building an AI slop registry) - *"we are piloting our new product called Verify. Please join and be our early design partners."* ## Availability Limits - **Comments availability:** not stated in transcript; no curated metadata supplied. - **Timestamps:** none present in transcript. \>\> Okay. Ooh, hello. Hey everyone. Thanks for joining in. Today, uh we will be talking about how to kill the code reviews. Everyone's favorite topic. I'm Ankit, co-founder of Aviator. At Aviator, we are building AI code verification platform. So, we'll bring in some of the ideas and concepts that we talked about in the uh that we build in our product. Uh but first, let's dive into a little bit. So, a few months ago, I wrote a post on LinkedIn space about uh how to kill code review, creating a framework, a five-layer trust model. So, this model was focused around how do we actually layer by layer build trust into the code that can then be merged without needing line-by-line review. And I got some things right, and I got some things wrong. So, this talk will be about just really diving a bit more more into it. I'm not going to talk about specific layers, but we will talk about some of the concepts that emerged from this session. So, let's just talk about the problem. We are looking today at the volume of code is increasing every day, and we are struggling to keep up. So, when we think about like how long will it take us to actually stop reading code line by line? And the reality is we've already stopped reviewing it. There is 861% code churn. That means we are like producing more code. The incidents to PR ratio is increasing. That means even if you're doing reviews today, they're not effective. So, the medium time of review is increasing. We have just increased the bottleneck to from the coding now kind of like coding is solved to now reviewing, where everything just gets stuck there. You're spending four x the time that you were spending before just waiting for the reviews. And today, over 30% of changes are actually getting merged without a review at all. So, let's just think about it a little bit. Think about AI reviews. So, everyone is probably using some form of AI reviews today. When AI write the code and AI review the code, why are we doing it in a UI? Right? Like we open a GitHub, there's kind of like, you know, maybe two or three AI coding agents who are like doing the reviews. You know, you the review goes back passed to the user and or the agent and it gets resolved and they kind of like you're doing back and forth with the agent. Where is human here in the loop? Like you're eventually just looking at, okay, you know, if AI has reviewed it, most of the things probably found, let's just kind of like, you know, do a skimming of it and merge it. So, when AI reviews and nobody reads, we have configured the wrong thing. So, let's just take a step back. Code reviews are not very old. They are maybe 15 to 20 years ago. In 2006 was when Google launched Mondrian internally and they made formal code review as a thing. If you think about it, Windows back in the days, the first versions were actually built without reviews. But if we look carefully, code review is not just about code reviews. You know, obviously we are looking at it like catching bugs, understanding kind of conventions, identifying security issues. But, code review is also about alignment. And this was one piece which was missing from my five layers model that I talked about a few months ago. So, a big part of code reviews is knowledge sharing, mentorship, architectural feedback, onboarding, being able to collaborate. This is Again, if you're doing uh white coding, you're working as a solo project, this is not a talk for you. If you are working in teams, which I believe most of you folks are, collaborating in teams, you're not likely using completely dark factories, orchestrators, where nobody looks at the code. You're actually collaborating in teams, you need to do knowledge sharing. Which is the alignment part. And that is the part which is the most important aspect of release. So, for semantic accuracy, we can build better tooling, but alignment must survive. So, let's just kind of like dive into alignment. What does it mean? Like, in today's world, can we actually think of better model than aligning just based on reading line by line code? So, most folks have probably heard about spectrum development by now. So, spectrum development is like, okay, we write a spec, you know, it covers all the details, we pass it to an agent, it generates a code, and then we verify. So, what's wrong here? If you look back in 1970, this is what waterfall model was. You know, you have requirements, you have specification, you implement, and then you verify. But, there's no feedback loop. You know, the spec is written before we identified everything else. Right? That's why today everyone still wants to use your coding sessions, whether it's cloud code, codex, cursor, whatever you're using, you want to interact with the agents. And the reason you're interacting with agents is because there were certain things which were not clear in the spec, and we still need to capture that. And second is, as you implement, you identify more issues, and you never go back and update the spec, because like, if you're doing the spectrum development, it's already done. Once the spec is done, you expect, like, you know, the code will come deterministically. But guess what? LLM is not deterministic. It's going to make decisions itself. So, that's why spectrum development is a great uh methodology, but it falls short in day-to-day software development. But there are some interesting aspects of this, which we should carry forward. The most important part is the intent. An intent doesn't only live in the spec. Intent live in your Jira ticket. That's the goal, right? Like it's kind of like where you express what we want to do. It lives in your PRDs. It's kind of like details, like it's a plan. But most importantly, it lives in your prompts today. This is where the real decisions are being made. You start with like, okay, this is a Jira ticket I'm going to look at, but you're going back and forth with the agent, and this is where all the user decisions are being made. But what we do today is we create a change, we create a pull request, and then we throw away the prompts. And this is one of the things that we need to change. Let us first talk also about semantic accuracy because like, you know, you're saying, "Hey, Ankit, okay, I understand the alignment part, but like there are still bugs in the code. Who's going to look at that?" LLMs are also not great at this, and we already talked about how AI agents may reviewers may not always be perfect. So, this is where I introduce you to the concept of AI slop registry. So, think about this. We are reviewing If you're reviewing code today manually, and I expect everyone should be doing some degree of this. We are essentially possibly identifying the same issues over and over again. Can we actually capture these concepts and codify them so that we don't have to always create those review feedback one by one. You actually also have all of those things automatically identified. The beauty of this is if you do it a few times, you now build sort of like a system which actually learns over time. So, think of this as sort of like you know, you know, you're doing more training on top of the standard LLM that you have actually extracted like built on top of. So, AI slop registers now can create better results because it's trained it's learning from the review experience that you as humans are providing. Every recurring comment is now a guardrail that you don't have to review again. Okay, so let's kind of like try to put both of these alignment and the semantic accuracy together. It is two halves of the same problem. We are trying to understand what are the core mechanics of review. How do we actually break it down into two parts which is the alignment and the semantic accuracy and bring them together into a single loop. So, first thing is you could take your session and you capture the user responses and that essentially forms your acceptance criteria. The acceptance criteria then tied with your AI slot register that you are now constantly maintaining finally creates a test plan. And this is the test plan which then gets verified. This is part of the system that we are building is the verification system where it spins up a preview, takes your test plan and make sure it actually works end-to-end. Even if the code looks right, does it actually work? So, this verification part has become interesting. And now the kicker is this is now your review surface. You're not reviewing code line by line, but rather you're looking at the evidence of what was the intent, did the user actually implement the capability that was defined in the intent, and did the behavior actually meet the requirements that we had in the as acceptance criteria. So, you're still having the architectural decisions, you're still having these arguments, but the review surface changes. So, just giving a walk through of like how we have built our system. The session becomes a criteria, so all these decisions that you are doing here with the agent, you're asking uh you know, you're providing this feedback. Like even if there is a simple task, many times you're going back and forth. Agent will stop to ask questions. These are the decisions that we need to capture. This is the intent. This is what makes your review, makes your collaboration more valuable. This is how you teach your junior engineers on how to improve over time. These are the decisions which make a software engineer valuable today. We convert those into an acceptance criteria. This is where you can also leverage LLM to do so. So, you capture these user uh decisions and make sure you can actually create a test plan based on this. I know test plan creation is always painful, which is where I would always recommend people to use LLM for this purpose. And finally, the criteria plus invariant is what makes the test plan. Uh and we build the verification systems to actually capture the test plan, run your previews, and be able to test based on this test plan. So, even imagine if you're building a new feature, you don't have to maintain tests at all. This is creating tests in real time, and this is where you can leverage the power of LLM because the test plan maintenance and creation can be really painful, but the value of human in the loop here is the governance and the review part, and the part where you're reviewing the test plan and not the code. Right? I know it's been like over 20 years we came up with test-driven development. This in some ways is closer to behavior-driven development, where the test plan is now something which even you can share with your product managers, your designers. Everyone can participate because these things are now in English. At the same time, we have now deterministic verification, which actually verifies whether the particular test criteria has been met or not. Let's move on. So, this is where I would say the system is not supposed to be perfect. It's deterministic where it can be, but LLM where you must. Not everything can be deterministic. Not every system can be built in a way which is 100% built on deterministic systems. This is where you use LLM as a fallback. Let me give an example. Like if you're making a change in your web application, what you can do is it creates a test plan of what the behavior changes. Let's say you introduce a new payment form. So, it creates a new payment form. The verification here is does the payment system changes? Uh an AI agent can go and browse through your application to fill out a form and capture screenshots as evidence. And then take those screenshots as well as your database snapshots to identify whether the criteria was met. So, the screenshot testing or like sand flying can then still be done by agents. But at the same time, you're creating more solid evidence, which now a reviewer can look at and build more confidence that this actually works. So, now reviewers are reviewing the intent, not the diff. You're reviewing the intent decisions. Uh what we said to build out. What we tried and rejected, and capture all of these things from the sessions. Remember, capturing it from the sessions is is key. If we try to build it from the code, you'll end up in the same situation that we were talking about I think Dex was talking about yesterday, which is if your code is built by the same agent which is actually building a test plan, it's not going to build a test plan which will actually catch issues. So, that's why it's important to actually use the session information to build out a test plan. You can discuss architectural decisions. So, how you're creating the data models, how these services interact with each other. So, you've moved one level above. So, you're essentially instead of like reviewing line by line, you're actually having discussions on architecture, which are very critical for any kind of collaboration. And then you look at the evidence, everything that was collected from the verification. So, here's a homework for everyone. Go home and mine your last 1,000 review comments and build out a AI slot register for the things which are repeatable. So, a vast majority of the comments that you're providing in your code review are something that we repeat over and over again. This compounds with every merge PR. Every time you capture something as a register, you don't have to capture that comment again. And this is where you can actually codify some of the best practices of doing code, maintain semantic accuracy, at the same time, do not lose the collaboration part of the review. It does follow a J curve. So, pain is real. Uh you will have to spend some time to actually make it pay off because initially creating a registry can take some time. And this is where I would recommend you folks can come and try out our product. So, code review is not just about code review. It is about uh really getting the alignment. And where we can build better tools is creating the semantic accuracy and defining your AI slot register. So, if you remember one thing from today, remember code review is not just about code review, it is about getting the alignment. And yes, we are piloting our new product called Verify. Please join and be our early design partners. We are working with a few companies to uh pilot out a new verification system. This combines both the alignment side of things as well as building tools and capabilities for detecting semantic accuracy using the AI slot register. Thank you, everyone. Thanks for joining. \>\> \[applause\]