Beyond Code Review: Why AI-Powered Development Demands a New Quality Framework

Traditional code review—reading pull requests to catch bugs, share knowledge, and enforce standards—was already straining before AI arrived. Now that generative agents can write thousands of lines in seconds, the bottleneck has become unbearable. A recent analysis by Faros of 22,000 developers found code churn jumped 861%, incidents per PR climbed 243%, and review time ballooned 441%. Perhaps most telling: 31% of pull requests now merge without any review at all.

The gap isn't closing because reviewers got lazy—they simply cannot keep pace. The real question is not whether to preserve traditional review, but what replaces it.

The Two Jobs Code Review Never Separated#

Code review was never a single activity. It bundled two structurally different problems into one:

• Alignment: ensuring the team agrees on what is being built, why, and the constraints involved. This is where knowledge flows from senior engineers to juniors, architectural decisions surface, and ownership takes shape.
• Standards checking: verifying code meets quality bars—catching bugs, enforcing conventions, flagging security gaps, and confirming the implementation meets team expectations.

These look identical from outside the pull request, yet require opposite solutions. Attempting to automate them equally misses the mark entirely. Those defending traditional review usually protect alignment. Those pushing for automation typically target standards. Conflating them keeps the conversation stalled.

Why AI Cannot Solve Alignment#

Alignment depends on intent, and intent vanishes when an agent generates code. When a human writes, their reasoning accompanies the code through review: "I considered X, rejected Y, and worked within constraint Z." That context remains accessible, even unspoken.

An agent's intent lives in a prompt that was never saved, a ticket that doesn't capture the real decision-making, or solely inside the engineer's head. Only the implementation survives.

Spec-driven development sounds like a solution—write complete intent before generation begins. The impulse is right, but specs written before implementation teaches you anything are wrong in ways you can't predict. Real work surfaces a hundred micro-decisions the spec never foresaw, and those decisions vanish after the session ends.

Instead, intent needs capturing where it actually happens: during the back-and-forth with an agent, not in documents authored before the work begins. A brief scope description, acceptance criteria list, or out-of-scope notes—often recoverable directly from prompts—become the artifact reviewers actually examine.