{
  "video": {
    "id": "YgEv7IQzGdM",
    "title": "How to Kill the Code Review — Ankit Jain, Aviator",
    "duration": 986,
    "upload_date": null,
    "channel": "AI Engineer",
    "source": "AI Engineer",
    "event_format": "In person"
  },
  "analysis": {
    "video_id": "YgEv7IQzGdM",
    "title": "How to Kill the Code Review — Ankit Jain, Aviator",
    "one_liner": "Aviator's co-founder argues line-by-line code review is already dead (30%+ of changes merge unreviewed), and proposes replacing it with two things: capturing intent from your agent sessions to build acceptance criteria, and an 'AI slop registry' of recurring review comments, which together generate a test plan that a verification system runs — so humans review the test plan and evidence, not the diff.",
    "summary": "Ankit Jain revisits the five-layer trust model he posted on LinkedIn about killing code review, and says the piece he got wrong was alignment — code review was never only about catching bugs, it's knowledge sharing, mentorship, architectural feedback and onboarding, and that must survive. He splits review into two halves: alignment (intent, which today lives in prompts and is thrown away when the PR is opened) and semantic accuracy (recurring bugs, which should be codified into an 'AI slop registry' that learns from human review feedback). The two combine into a loop: agent session → captured user decisions → acceptance criteria → criteria plus invariants → test plan → deterministic verification on a spun-up preview, with an agent browsing the app and capturing screenshots and DB snapshots as evidence. The review surface then becomes the intent and the evidence rather than the diff, and Aviator is piloting a product called Verify that implements this.",
    "key_points": [
      "The stats he cites for the problem: 861% code churn, a rising incidents-to-PR ratio (reviews that happen aren't effective), rising median review time, 4x more time spent waiting for review, and over 30% of changes merged with no review at all — the bottleneck moved from coding, which is 'solved', to reviewing.",
      "AI reviewing in a GitHub UI is the wrong configuration: two or three AI coding agents leave review comments, the agent resolves them in back-and-forth, and the human just skims and merges — 'when AI reviews and nobody reads, we have configured the wrong thing.'",
      "Formal code review is only ~15-20 years old — Google launched Mondrian internally in 2006 and made it a thing; early versions of Windows were built without reviews.",
      "Spec-driven development is waterfall (requirements → spec → implement → verify, 1970) with no feedback loop: people still want interactive coding sessions in Claude Code, Codex or Cursor because things weren't clear in the spec, and nobody goes back and updates the spec as implementation reveals issues. LLMs aren't deterministic, so code doesn't fall out of a finished spec.",
      "Intent doesn't only live in the spec — it lives in the Jira ticket (the goal), the PRD (the plan), and most importantly in the prompts, where the real decisions get made. Today those prompts are thrown away when the pull request is created.",
      "The 'AI slop registry': mine the same review issues you flag over and over and codify them as guardrails, so the system learns from human review experience on top of the standard LLM. 'Every recurring comment is now a guardrail that you don't have to review again.'",
      "The loop Aviator built: session → captured user responses become acceptance criteria (use an LLM for this) → criteria plus invariants become a test plan → a verification system spins up a preview and tests against the plan, so a new feature needs no maintained tests. The test plan is in English, so product managers and designers can participate — closer to behavior-driven development than TDD.",
      "Worked example: add a payment form, and the agent browses the application, fills out the form, captures screenshots plus database snapshots as evidence, and judges whether the acceptance criteria were met.",
      "Build the test plan from the session, not from the code — if the same agent that wrote the code writes the test plan, it won't catch issues (he credits a point Dex made the previous day).",
      "Design principle: 'deterministic where it can be, but LLM where you must' — LLM as the fallback, since not every system can be 100% deterministic.",
      "Adoption follows a J curve: building the registry takes real time before it pays off."
    ],
    "takeaways": [
      "The homework he gives: go mine your last 1,000 review comments and build an AI slop registry from the repeatable ones — a vast majority of review comments are repeats, and each one captured compounds with every merged PR.",
      "Stop discarding prompts at PR time. Capture the decisions from the agent session — including what you tried and rejected — and turn them into acceptance criteria; that record is also how you teach junior engineers.",
      "Generate the test plan from session intent plus your registry invariants, and have an LLM write it — test plan creation and maintenance is the painful part and is what LLMs are good for.",
      "Move the human's job up a level: govern and review the test plan, the intent decisions and the verification evidence (screenshots, DB snapshots), and spend review on architecture — data models, service interaction — instead of the diff.",
      "Don't treat spec-driven development as the whole answer; keep its focus on intent, but assume feedback loops and non-deterministic LLM decisions rather than a frozen spec."
    ],
    "topics": [
      "code review",
      "agents",
      "verification",
      "spec-driven development",
      "developer tooling",
      "testing",
      "ai slop"
    ],
    "tools": [
      "Aviator",
      "Verify (Aviator)",
      "GitHub",
      "Mondrian (Google)",
      "Claude Code",
      "Codex",
      "Cursor",
      "Jira",
      "LinkedIn"
    ],
    "quotes": [
      {
        "text": "So, when AI reviews and nobody reads, we have configured the wrong thing.",
        "at": "02:53",
        "url": "https://www.youtube.com/watch?v=YgEv7IQzGdM&t=173s"
      },
      {
        "text": "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.",
        "at": "06:21",
        "url": "https://www.youtube.com/watch?v=YgEv7IQzGdM&t=381s"
      },
      {
        "text": "Every recurring comment is now a guardrail that you don't have to review again.",
        "at": "07:52",
        "url": "https://www.youtube.com/watch?v=YgEv7IQzGdM&t=472s"
      },
      {
        "text": "It's deterministic where it can be, but LLM where you must.",
        "at": "11:54",
        "url": "https://www.youtube.com/watch?v=YgEv7IQzGdM&t=714s"
      }
    ],
    "words": 3028
  },
  "summary_url": "/#YgEv7IQzGdM",
  "transcript": {
    "html": "/transcripts/YgEv7IQzGdM.html",
    "txt": "/transcripts/YgEv7IQzGdM.txt",
    "vtt": "/transcripts/YgEv7IQzGdM.vtt"
  }
}