How to Kill the Code Review

What evidence would let a team merge a change without reading every line? Ankit Jain, Aviator’s co-founder, approached that question in How to Kill the Code Review, proposing five layers of trust around generated code. Building an AI code verification platform has led him to revisit that proposal: the challenge is not only establishing that code works, but preserving what teammates learn and decide through review.

The immediate pressure is growing code volume. Jain describes a bottleneck moving from writing code to reviewing it, citing an 861% increase in churn, rising incidents per pull request, and longer review times. Churn needs a precise reading here: the closely matching Faros analysis defines it as quarterly deleted lines divided by added lines. An increase in that ratio is not an equivalent increase in useful output.

Jain describes review waiting time as four times its previous level and says over 30% of changes merge without review. The matching Faros figures use different denominators: median time in review increased 441.5%, and 31.3% more PRs merged without review. Those are relative changes between organizations’ lowest and highest AI-adoption periods, not the share of all PRs lacking review; time in review is also not necessarily time waiting for a first reviewer. The findings are observational correlations.

Now consider the everyday GitHub workflow: two or three AI reviewers leave comments, a coding agent or developer receives them, and another round of changes resolves the feedback. The human arrives at the end, assumes the agents have found most problems, skims the diff, and merges. If nobody meaningfully reads the exchange, why organize it around a human-facing review interface? Adding automated reviewers has preserved the ceremony without necessarily preserving human judgment.

Today’s review interface is not an immutable requirement of software engineering. Jain points to Google’s Mondrian in 2006 and early Windows development to illustrate how practices have changed. That history should be read narrowly as a discussion of modern tool-mediated review: formal inspections go back at least to Fagan’s work in 1976, as documented in Modern Code Review: A Case Study at Google. The specific Mondrian date and Windows comparison are Jain’s historical examples.

Review performs two different jobs:

The second job was missing from Jain’s original trust model. A reviewer explaining a design choice or helping a junior engineer understand a service boundary is doing more than checking correctness.

This distinction matters most for teams collaborating on a shared system. A solo project or a fully unattended development operation has different coordination needs. For a team, alignment must survive even as correctness checks become more automated. The design question is whether shared understanding can come from something more useful than reading a diff line by line.

Spec-driven development offers an appealing sequence: write the specification, give it to an agent, generate the implementation, then verify it. Jain compares that sequence to the familiar waterfall model associated with 1970. The criticism applies specifically to a frozen, one-pass workflow; Royce’s original paper already described feedback between phases and warned about the simple sequential approach.

The missing feedback becomes visible during an ordinary Claude Code, Codex, or Cursor session. The developer interacts with the agent because the specification leaves questions unanswered. Implementation then exposes additional problems. If the specification is treated as finished, those discoveries never make it back into the document that supposedly defines the work. An LLM also makes implementation choices rather than producing a deterministic expansion of the specification. Spec-driven development remains useful, but its most valuable contribution is intent, not an assumption that all decisions can be completed up front.

Intent is distributed across several artifacts:

The conversation is especially valuable because it records the developer’s answers as ambiguities emerge. Creating a pull request and discarding that conversation throws away part of the explanation for why the code exists in its current form. Preserve those decisions with the change.

Preserving intent does not eliminate bugs. LLMs make mistakes, and AI reviewers can miss them. Jain still expects some manual review; the opportunity is to stop spending that human attention on the same findings repeatedly. His AI slop registry, also called a register, collects recurring review issues and turns them into guardrails that can be checked automatically.

Each repeated finding becomes an input to the verification system rather than another comment somebody must remember to write. As the registry grows, it incorporates the team’s review experience. Jain describes this as learning or training on top of a standard LLM, but does not specify model-weight updates. The concrete mechanism is codifying recurring feedback so the system can identify it again.

Alignment and semantic accuracy meet in a single verification loop:

1. Capture the developer’s responses from the coding session.
2. Turn those decisions into acceptance criteria.
3. Combine the criteria with the maintained AI slop register to create a test plan.
4. Start a preview environment and verify the plan end to end.
5. Review the intended capability alongside the observed behavior.

The acceptance criteria describe what this change should accomplish. The registry contributes constraints learned across changes. Together, they give verification a target beyond whether the implementation looks plausible.

The review surface becomes intent plus evidence. Did the implemented capability match what the developer meant to build? Did its behavior satisfy the acceptance criteria? Architectural disagreements still belong in the review; they now sit beside explicit requirements and observations rather than being inferred entirely from the diff.

In Aviator’s walkthrough, even a simple task involves clarification questions and user feedback. Those exchanges contain engineering decisions worth retaining: they explain the implementation to teammates and give junior engineers examples of how to reason through a change. An LLM can extract those decisions into acceptance criteria and help create the test plan, reducing the effort of translating a conversation into something verifiable.

Criteria plus invariants then drive checks in a preview environment. Jain proposes generating tests in real time for new features, with the aim of removing much of the recurring test-writing and maintenance burden. Human governance shifts toward reviewing whether the plan asks the right questions. The walkthrough slide makes that surface concrete: a checklist sits beside pass/fail results, including a red failure for Threshold typed as Money. A failed check is visible evidence to investigate, not a successful outcome to infer from plausible code.

This resembles behavior-driven development more than simply moving traditional test-driven development into an agent. An English-language test plan lets product managers and designers participate in deciding what correct behavior means. Where criteria admit deterministic checks, the verification system can then establish whether each one was met. Human agreement about the requirement and machine checking of the result play different roles.

Not every part of verification can be deterministic. Jain’s rule is “deterministic where it can be, but LLM where you must.” Use precise checks where possible and agent judgment where the task requires it, without treating the whole system as perfect.

His example is a newly introduced payment form. A test plan describes the behavioral change; an AI agent browses the application, fills out the form, and captures screenshots. Those screenshots, together with database snapshots, provide evidence for deciding whether the acceptance criteria were met. The browser view shows what the user encountered, while the stored state helps establish what the application actually did.

For a concrete implementation of that evidence check, suppose the captured requirement says a successful payment must create a paid record for order order-42, for 2,500 cents in USD. The following TypeScript checks that proposed criterion against before-and-after snapshots; screenshot evidence remains a separate part of the review:

type Payment = {
  id: string;
  orderId: string;
  amountCents: number;
  currency: string;
  status: string;
};

function verifyPayment(
  before: readonly Payment[],
  after: readonly Payment[],
): boolean {
  const previousIds = new Set(before.map(payment => payment.id));
  const added = after.filter(payment => !previousIds.has(payment.id));
  const orderPayments = added.filter(
    payment => payment.orderId === "order-42",
  );

  return orderPayments.length === 1 && orderPayments.every(payment =>
    payment.amountCents === 2500 &&
    payment.currency === "USD" &&
    payment.status === "paid"
  );
}

The agent’s navigation can be flexible while this particular check remains exact. Screenshots and snapshot checks give the reviewer inspectable evidence; agent-based screenshot assessment can still require judgment.

The session should retain what was requested, what was attempted, and what was rejected. That origin matters. If an agent writes code and then derives the test plan only from that code, it can reproduce its own mistaken assumptions in the checks. Jain connects this warning to a point he recalls Dex making the previous day: tests that merely describe the implementation can miss the gap between implementation and intent. Session-derived criteria provide a separate statement of what was wanted.

The reviewer can then discuss data models, service interactions, and architectural choices at the level where collaboration is most valuable. Those decisions remain open to challenge, and the collected verification evidence shows what happened when the proposed behavior was exercised. Moving beyond line-by-line review does not remove technical discussion; it gives that discussion a different set of artifacts.

Jain’s starting assignment is concrete: mine the last 1,000 review comments for repeatable issues. Turn the recurring best practices into entries in the AI slop register. Each merged PR can then contribute another reusable check, reducing the need to write the same feedback again while preserving the collaborative part of review.

That investment has an initial cost. Jain describes a J-curve: building the registry takes time and creates pain before the accumulated checks pay off. The adoption slide explicitly cautions against killing review on day one. His invitation to try Aviator’s approach sits within that gradual transition: improve tooling for semantic accuracy while retaining the alignment that makes review valuable to a team.

At the time of the talk, Aviator Verify was being piloted with a few companies and seeking early design partners. Its proposed combination is the same one the workflow requires: captured intent for alignment, and a growing register of reusable checks for semantic accuracy. The goal is to make a merge decision rest on shared decisions and verified behavior, with human attention still available for the questions the checks do not settle.