Senior engineers are leaving over AI code review burden—here's how to fix it

The most experienced engineers at organizations adopting AI-generated code are facing an unexpected crisis: they're spending less time building and far more time verifying machine-generated output. The engineers most committed to code quality—the ones who established review culture and built the systems their teams depend on—now face 15 pull requests with 400 lines of code each sitting in their queue daily.

In a community of senior engineers and engineering leaders, AI code review bottlenecks consistently rank among the top concerns. Research shows 77% of engineers report spending less time writing code; that time has shifted to reviewing AI output. Teams with high AI adoption are merging 98% more PRs, yet review times climbed 91%.

The job shifted from crafting to verifying

When a human colleague writes code, context accompanies the submission. They can articulate the tradeoffs they weighed, alternatives they considered, and constraints they operated under. This reasoning remains accessible even when unspoken.

When AI writes code, the reasoning is gone. The reviewer is left reverse-engineering intent from a diff.

Machine-generated code strips away this reasoning entirely. Reviewers must reconstruct intent by analyzing code alone—a fundamentally different cognitive task. The challenge intensifies because AI-generated code often appears correct at first glance.

Why reviewing AI-generated code is harder

Five shades of AI slop

• Plausible but wrong: Code reads coherently and handles typical cases, but edge cases expose misaligned assumptions. These defects evade review because they require knowing what the code should accomplish, not merely what it does.
• Over-engineered: Trained on vast codebases including enterprise patterns and production architectures, models often generate 200-line abstraction layers when 15 lines suffice, anticipating generality nobody requested.
• Convention-blind: Models produce generic code rather than code fitting your specific system. Repository conventions around naming, error handling, logging, and module boundaries get ignored.
• Confidently hallucinated: Calls to nonexistent APIs, deprecated methods, invented config options. Some catch immediately; others only surface in production.
• Cargo-cult patterns: Copies structures without understanding purpose. Retry logic where retries make no sense. Circuit breakers for synchronous calls. Error handling appearing thorough but misaligned with actual failure modes.

The unifying factor: it all resembles legitimate code, making large-scale review extremely difficult.

How to fix the code review

The solution is not demanding reviewers work harder or deploying an LLM reviewer. When the same model writes and reviews code, it inherits its own blind spots. Adding adversarial agents and multiple steps transforms the process into a workflow theater where engineers become bot-sitters, configuring filters instead of building systems.

What actually works involves shifting burden from reviewers in three directions: codify repetitive feedback, preserve the intent behind the code, and measure the work that genuinely prevents problems.

Create your AI slop registry

Examine your team's last 100 PR review comments. Classify each one: Is it deterministic—something a rule can check? Is it execution-testable—something running the code catches? Or is it genuine judgment?

Teams performing this exercise typically find roughly 45% deterministic, 30% execution-testable, and 25% judgment. Three-quarters of review feedback is codifiable.

Three-quarters of review feedback is codifiable. Every recurring review comment is an invariant you haven't written yet.

Statements like "New endpoints must have OTel spans" are not judgment calls—they're AST checks. Write the rule once and it never requires a reviewer again. The criterion for promoting something to an invariant is recurrence: if you've posted the same comment multiple times, codify it.

Preserve the reasoning trail

The prompts and agent sessions generating code contain its intent. Most organizations discard them, equivalent to deleting commit messages and PR descriptions while expecting reviewers to reconstruct intent from diffs alone.

Capturing intent from prompts and agent sessions and structuring it as acceptance criteria—what the change does, what falls outside scope, how to verify success—makes the architectural choices, scope decisions, and behavior tradeoffs reviewable. Reviewers then ask the high-value question: "Are we solving the right problem with the right constraints?" This is where senior engineers contribute most. Reading a 400-line diff at 4 p.m. is not.

Code itself matters least in reviews. Intent—acceptance criteria, non-goals, blast radius—is what counts.

How knowledge sharing survives

When reviewers read specifications and acceptance criteria, they're reading decisions, not scanning syntax. They debate tradeoffs, understand system evolution, and see what constraints shaped the approach. That's where knowledge sharing persists. If code review moves left, knowledge sharing must move left too.

Measure and reward verification work

31% more PRs are merging without any review. Engineers are voting with their behavior.

Dashboards tracking AI adoption and productivity in lines of code never capture the work senior engineers perform carrying the review burden. They never surface the effort building systems and guardrails preventing problems. If metrics show throughput and cycle time looking good, the wrong things are being measured.

Tracking across 158 engineers in 28 countries reveals a troubling pattern: engineers are resigning. Some hope the role returns to what it was. Others are leaving the profession entirely. The shift toward verification-heavy work is transforming the job into something they don't want.

Those dashboards don't show the senior engineer who spent her afternoon reverse-engineering intent. They show throughput. And throughput looks great right up until the people carrying the review burden walk out the door.

The engineers bearing the review load aren't complaining—they're departing. Some move to teams with better tooling. Others leave engineering entirely, not because they lack capacity, but because the work diverged from what they signed up for.

Leaders chasing generated lines of code and merged PRs won't see this coming. Those dashboards hide the senior engineer reverse-engineering intent from a 400-line diff. They hide the review catching a cargo-cult pattern before production. They show throughput. And throughput looks excellent until the people carrying the review burden walk out the door.

Fixing the code review process requires codifying what's repetitive, preserving the reasoning trail, and measuring the work that actually prevents problems. Otherwise, organizations watch their best engineers leave and wonder why their AI-powered team ships faster but breaks more.