Code Review Is Already Dead. What Comes Next?

The debate about whether AI will replace code review has been running for a couple of years now. Ankit Jain, co-founder of Aviator, walked into a recent AI Engineer talk and declared it settled—in the past tense. The debate is over, he said, because the thing it was debating has already stopped happening.

Research published on ResearchSquare tracking merge request behavior found that over 30% of changes are now merging without any review at all. Jain cited these figures at the top of his talk, and his framing was deliberately blunt: we didn't decide to stop reviewing code. We just... stopped.

What replaced review is arguably stranger than no review at all. The current state, as Jain describes it: an AI writes the code, a different AI reviews it, they exchange comments in a GitHub PR thread, and a human eventually skims the exchange and clicks merge. "When AI reviews and nobody reads," he said, "we have configured the wrong thing."

It's a clean provocation. But the more interesting part of his talk wasn't the diagnosis—it was the autopsy he performed on his own prior thinking, and what that revealed about what code review was actually for.

The Missing Half

Jain came to the talk partly to correct himself. He'd previously outlined a framework for building trust into code at multiple layers, focused on how teams could merge without requiring line-by-line review. His core admission: that model got the correctness problem right but missed the alignment problem entirely.

"Code review is not just about code reviews," he said. The obvious stuff—catching bugs, enforcing conventions, flagging security issues—is only half the function. The other half is knowledge sharing, mentorship, architectural feedback, and onboarding. Junior engineers learn by watching senior engineers leave comments. Architectural decisions get socialized through review threads. Institutional knowledge transfers in the margins of a diff.

None of that survives a fully automated review loop. An AI reviewer can catch a null pointer exception; it cannot explain to a new hire why the team decided three years ago never to use that particular pattern. That history lives in human reviewers, and when the humans skim and merge, it exits through the same door.

This is the tension Jain is trying to navigate, and it's worth sitting with before jumping to his proposed solution. The human oversight question doesn't resolve neatly even with better tooling—the knowledge-transfer function of review has always depended on humans actually engaging, not just being nominally present in the loop.

Spec-Driven Development Is Just Waterfall in a Hoodie

One proposed escape route from the review problem is spec-driven development: write a detailed spec, hand it to an agent, verify the output. Jain dispatches this quickly, and the dispatch is accurate. He traced the lineage directly: requirements, specification, implement, verify, no feedback loop. "If you look back in 1970, this is what waterfall model was."

The problem isn't that specs are bad. It's that the decisions that actually shape a piece of software don't happen in the spec. They happen in the prompts—the back-and-forth between developer and coding agent that occurs while the code is being built. The spec says "add a payment form." The prompts say "actually, let's use the existing modal pattern," "no wait, we need this to work on mobile first," "the agent suggested approach A but we rejected it because of the auth flow." Those decisions are the intent. And currently, the moment a pull request opens, teams throw them away.

"Intent doesn't only live in the spec," Jain said. "It lives in your Jira ticket. It lives in your PRDs. But most importantly, it lives in your prompts today. This is where the real decisions are being made."

This points to a genuine gap in current AI-assisted workflows. There's a verification debt problem building under the surface of AI-accelerated development—when you can't reconstruct why code was written the way it was, the cognitive load of future changes increases and the blast radius of errors expands. Jain's argument is that we're compounding that debt every time we discard a session.

Two Fixes, One Loop

Jain proposes addressing both halves of the problem—semantic accuracy and alignment—through a connected system rather than treating them separately.

For semantic accuracy, he introduces what he calls the AI slop registry: a living database of recurring review comments, built from real human review history. The observation driving it is simple: most of the comments reviewers leave, they've left before. The same anti-patterns, the same convention violations, the same architectural mistakes surface repeatedly. Capturing those comments and codifying them as guardrails means AI reviewers can be calibrated against your team's actual standards, not just generic best practices. "Every recurring comment is now a guardrail that you don't have to review again."

His homework assignment was concrete: go mine your last 1,000 review comments. Figure out which ones repeat. Those are your registry seed. He acknowledged the J-curve—there's upfront cost before the system pays off—but the compounding logic is sound. Every pattern you capture is one you never have to manually catch again.

For alignment, the fix is to stop throwing away the session. Capture the developer-agent exchange, extract the decisions, and convert them into acceptance criteria. Those criteria, combined with the slop registry, generate a test plan. A verification system then runs that test plan against a live preview—not just checking whether the code compiles, but whether the behavior actually matches what was specified in the session. An agent can navigate the application, fill out forms, capture screenshots, compare database state. The evidence becomes the review artifact.

"Reviewers are reviewing the intent, not the diff," Jain said. "You're reviewing the intent decisions—what we said to build out, what we tried and rejected."

The comparison he reaches for is behavior-driven development: test plans expressed in plain language, shareable with product managers and designers, not just engineers. The architectural conversation still happens—it just happens at the level of intent, not implementation.

What This Doesn't Resolve

Jain's framework is coherent and the problems it targets are real. But a few tensions don't fully dissolve.

The knowledge-transfer problem is the hardest one. Reviewing intent rather than diff is a meaningful shift, but it still assumes that the humans in the loop will engage seriously with the acceptance criteria and architectural discussion. If the current failure mode is humans skimming AI review threads and merging, why would they engage more deeply with intent documents? The cultural and incentive problems that produced the current situation don't disappear because the artifact being reviewed changes shape. Dex Horthy's documented experience running a fully automated "dark factory" for three months—where an AI agent corrupted a codebase before anyone noticed—suggests that the accountability gap is real and the tooling layer alone doesn't close it.

There's also the question of what counts as intent. Jain's model captures developer-agent exchanges, but the most consequential architectural decisions often happen in meetings, in Slack threads, in conversations at whiteboards. Session capture gets you more signal than you have now, but it's not comprehensive.

And worth noting: Jain is co-founder of Aviator, which is building exactly this kind of verification platform. The framework he's describing is also the product pitch. That's not disqualifying—the best founders usually have frameworks that match their products because they built the product to solve a problem they understand deeply. But it's the kind of alignment worth tracking.

The Actual Shift He's Describing

Strip away the specific tooling and what Jain is proposing is a change in where trust gets established in the development process. Right now, trust accumulates (or doesn't) at review time, after the code exists. His model pushes trust-building upstream into the session, where intent is recorded, and downstream into verification, where behavior is tested. Review becomes the place where humans confirm that the upstream and downstream artifacts are coherent—not the place where humans read every line looking for problems.

Whether that's "killing" code review or just moving it is partly a semantic question. The more substantive question is whether the alignment function—the mentorship, the knowledge sharing, the architectural socialization—can actually survive that migration, or whether it quietly disappears in the handoff between sessions and acceptance criteria.

That's not a question Jain's talk fully answers. It might be the question that determines whether this framework works or just generates a more sophisticated illusion of review.

---

Dev Kapoor covers open source software and developer communities for Buzzrag.