The math stopped working somewhere in the last 18 months. A developer spends 15 minutes prompting an AI agent to generate a feature. The result: 800 lines of working (mostly) code across 12 files. The PR lands on a senior engineer’s desk, who spends 90 minutes untangling what changed, why it changed, and whether the edge cases are covered.
The code wrote itself. Understanding it took six times longer.
This gap isn’t a minor workflow friction. It’s a structural crisis in how software teams operate, and it’s getting worse with every new model release. The bottleneck in modern software delivery has shifted from writing code to comprehending it, and most teams haven’t updated their processes or tools to reflect that reality.
The Review-to-Write Ratio Has Inverted
Olena Babenko, Staff Software Engineer at Aiven, put it bluntly in a recent interview: “We have an ability to generate code very, very fast, thousands of lines of code… but code reviewing, scaling, and automation is not on that same level yet.” The result is a perverse dynamic where the person reviewing the PR spends more time than the person who allegedly wrote it.
Empirical research on code reviews backs this up with uncomfortable precision. Studies consistently show that effective code review peaks at around 400 lines per hour, and a single review session loses effectiveness after 60 minutes. For every 400 lines an AI agent generates, you need one senior developer-hour to review it properly. And that’s for straightforward code. Complex logic, unfamiliar domains, or poorly structured AI output? The throughput drops further.
This means a developer using AI coding assistants can realistically produce, review, and commit maybe 1,000-2,000 lines per day. The AI isn’t actually speeding up delivery to production. It’s shifting the bottleneck from creation to verification.
The situation is even worse than the raw numbers suggest. Research indicates that humans reviewing AI-generated code are more confident they’ve caught all defects, while actually finding fewer than when reviewing human-authored code. The machines are getting past us.
“Always Has Been”, But It’s Getting Worse
Seasoned developers will recognize this pain and respond with a weary “always has been.” The imbalance between writing and reviewing has been a background hum in software engineering for years. One Reddit thread on this topic collected the predictable chorus: reviewers rubber-stamping changes, leads taking it seriously while peers scan and approve, and the discouragement of spending time on thorough comments that get ignored.
What’s different now is the volume. AI-generated code went from 1% to 27.6% of all pull requests in the past year alone, according to Greptile’s research. Fully AI-generated code also introduces significantly more vulnerabilities than human-written code, and PRs got longer. The DORA 2025 report from Google Cloud found that AI adoption correlates with higher instability, more change failures, more rework, and longer cycle times. Faster shipping hasn’t meant safer production.
The data cascades in one direction:
– Incidents per PR are up 242.7%
– Median time in PR review is up 441%
– AI-generated code contains 1.7x as many bugs as human-written code
– 43% of AI-generated code still needs manual debugging in production after passing QA and staging
The review bottleneck isn’t just annoying anymore. It’s actively degrading production reliability.
Why Understanding Doesn’t Scale
The core problem is that human comprehension does not scale the same way as machine generation. CodeRabbit’s analysis of this dynamic captures it perfectly: “A diff is evidence, not a route.” When a change spans 45 files across authentication, environment handling, templates, and configuration (as in the real-world TanStack CLI pull request #490), the reviewer isn’t just checking a diff. They’re reconstructing a mental model of system behavior from raw coordinates.
Most review interfaces start with files, lines, and comments. That evidence structure is essential. It’s also a terrible place to begin when one system change touches routes, providers, templates, tests, and configuration files. The reviewer must mentally stitch together which changes belong to which system behavior, a slow and error-prone process that each reviewer performs independently.
This is why review needs a higher level of abstraction. Not a summary that asks for blind trust, but a path from intent to system behavior to code, with every claim traceable to the diff. Newer tools like CodeRabbit’s Change Stack attempt this by grouping related edits into named behavioral paths, proposing a reading order based on what changes should be judged together rather than which files share a directory.
The key insight: “No representation is sufficient alone. The value comes from moving between intent, behavior, and exact evidence without breaking the chain.”
The Management Blind Spot
The technical problem has a political dimension, and it might be the harder one to solve. Olena Babenko pointed out that “a lot of managerial tools are made on KPIs, they are made on individual contributions of code writing… while the people who do the PR reviews, their jobs are not valued that much.”
GitHub contributions and Jira velocity measure creation. They don’t measure the work of understanding, evaluating, and defending system integrity. When review time exceeds development time but only development time shows up on the dashboard, you’ve created a structural incentive to prioritize speed over safety. The person who merges fast is rewarded. The person who catches subtle bugs is invisible.
This misalignment is why many teams experience the pattern where a thousand-line PR lands on a reviewer who is, realistically, expected to just hit merge. The organizational expectation hasn’t caught up to the technical reality. Until management treats reviewing as real work worth rewarding, with smaller PRs, separated refactoring from logic changes, and earlier communication, the bottleneck will persist regardless of tooling.
The AI Review Paradox
The natural response to an AI-caused problem is an AI-powered solution, and the market has responded accordingly. Greptile, CodeRabbit, Qodo, Claude Code Review, Cursor BugBot, and a dozen other tools now compete to automate the review itself. They’re not all equal.
Greptile, for instance, indexes your entire codebase and reviews each PR against that full context, catching bugs in the seams between files. In head-to-head benchmarks, Greptile catches over 50% more bugs than CodeRabbit on the same open-source PRs. The difference is full-codebase context versus diff-level annotation.
But here’s the paradox that few are willing to confront directly: if the solution to unreliable AI code generation is more AI-powered review, at what point does the cognitive chain become so automated that the humans in the loop lose the skills to evaluate either the code or the review? Olena Babenko’s concern is prescient: “You might end up in a situation where you have a human in the loop, but those people do not have correct skills anymore.”
A safety net only works if the person holding it still knows how to catch something.
What Actually Works
The data and practitioner experience point to a layered approach, not a silver bullet.
First, automate the boring stuff. Linting, formatting, static analysis, and security scanning should never consume human attention. These are solved problems. Tools like SonarQube, Semgrep, and integrated linters handle the mechanical layer.
Second, use AI review for cross-file context. Tools that understand the full codebase (Greptile, DeepSource’s hybrid approach) catch bugs invisible from the diff alone. The recent Greptile catch on NVIDIA’s NeMo Guardrails, flagging that a refactor would break downstream clients expecting a specific response format, is exactly the kind of issue a human reviewer would miss until production.
Third, keep humans in the loop for architecture and correctness. No AI reviewer can answer whether a boundary is sound, whether a tradeoff is worth it, or whether the change points the system in a useful direction. The best review tools don’t replace judgment, they organize evidence so judgment can operate efficiently.
Fourth, restructure the PR. Smaller, focused changes with clear descriptions and separated refactoring from logic changes reduce cognitive load on reviewers. This isn’t a new insight, but it’s increasingly violated as AI agents generate mega-PRs that touch everything at once.
Fifth, consider runtime verification. Every tool that reads your diff is blind to how code behaves under real production traffic. Lightrun’s Runtime-Aware PR Verifier takes a fundamentally different approach by simulating a proposed change against live production samples. The difference is structural: static review sees what’s written, runtime verification sees what happens.
DORA data confirms that static AI reviewers catch roughly 44% of bugs, while 43% of AI-generated code still needs manual debugging in production. Runtime verification closes the remaining gap.
The Underlying Cost
When a team spends 90 minutes reviewing 15 minutes of AI-generated code, the cost isn’t just the time. It’s the accumulated technical debt in integration layers that grows when review quality suffers. It’s the context switching that destroys deep work. It’s the slow erosion of judgment that happens when engineers read code they didn’t write, don’t fully understand, and can’t confidently defend.
One particularly pernicious pattern is AI-generated unit tests that look good but provide no real safety. Models will patch internal implementations or hardcode expected outputs rather than genuinely verify behavior. The result: high coverage numbers that protect against nothing, discovered only after a production incident reveals the false sense of security.
As one engineer noted, this erosion doesn’t “fall apart in one day. This is a process that’s eroding your system with a small step day by day until you realize that your new system is really unreliable.”
The Path Forward
The industry is collectively stumbling into a future where code generation is cheap and code understanding is expensive. That inversion demands a fundamental rethinking of how we structure development workflows.
Smaller PRs. Behavior-grouped review paths. AI tools that organize evidence rather than replace judgment. Management metrics that value review contributions alongside code creation. And a clear-eyed recognition that the hidden costs of loosely coupled architectures and the risks of centralized development infrastructure compound when review quality degrades.
The code writes itself now. That’s the easy part. Understanding whether it belongs, whether it’s sound, and whether it improves the system, that’s the work that actually matters. And right now, we’re not treating it that way.
The bottleneck has moved. It’s time to acknowledge it, measure it, and build processes that address it. Otherwise, we’re just generating technical debt faster than we can review it, and calling that productivity.
