AI Wrote 3,000 Lines of Code, But Nobody Read It: The Code Review Bottleneck Crisis

Title

AI Wrote 3,000 Lines of Code, But Nobody Read It: The Code Review Bottleneck Crisis

Meta Description

AI boosts code generation speed 10x, but code review becomes the new bottleneck. A Harvard paper shows PR merge waits lengthened by 49%, and AI review tools even approve their own bugs. This article analyzes the imbalance between generation speed and review throughput, and offers actionable practices like small PRs and test evidence.

Article Content

A satirical short drama from YouTube has recently been circulating in developer circles. The story is simple: a student uses a single prompt to have AI generate 3,000 lines of code, completing a group project. The team submits a Pull Request at 2 AM, and 4 seconds later it's approved by teammate Jordan—averaging 750 lines per second. The problem only truly surfaces when the teaching assistant asks each person to explain their code during the demo: three login systems, a room booking logic that can't prevent double bookings, and a self-inflicted bug that an AI review tool stamped "approved."

This fictional plot happens to correspond to a widely discussed Harvard working paper. According to the drama's citation, the study covers about 700 companies and 700,000 developers, finding that after introducing coding agents, code volume increased by 30%, Pull Request count increased by 23%, but the number of completed features and fixed bugs showed "no measurable change." That said, Pull Request merge wait times lengthened by 49%, and review comments requiring changes nearly doubled.

This is not a story about whether AI can write code. It's a story about "who reads it"—when generation speed improves by an order of magnitude, human reviewers' attention becomes the narrowest gate in the entire pipeline.

The Review Bottleneck Amplified by AI

The short drama has a precise metaphor: the pizza oven is 10x faster, but there's still only one person slicing pizzas. Pizzas pile up on the counter and go cold. Code review is that pizza slicer.

According to the original YouTube video and analyses by multiple creators on Bilibili, this bottleneck forms through two mechanisms. The first is a volume shock: AI enables every developer to write 3,000 lines of code before lunch, PR counts surge, but reviewers' cognitive bandwidth remains unchanged. The second is quality degradation: when reviewers face giant PRs, the rational choice is often to "glance, sigh, look again tomorrow," or simply rely on AI review tools.

The scene in the original video where "AI grades AI" is especially jarring. The review tool gives code containing a double-booking vulnerability a "well-structured, clear logic, approved"评价. A character in the drama quips: "It gave its own bug a gold star."

This doesn't negate the value of AI review tools—they do catch real defects. The problem is that when reviewers themselves have already given up reading, the tool's "approval" becomes a rubber stamp.

Coding Agent is the core technology driving the phenomenon described. Unlike traditional code completion tools (like early GitHub Copilot), coding agents can receive natural language task descriptions, autonomously plan multi-step operations, and generate, modify, or even test code across files. It's more like a junior developer who can independently complete a "small project" rather than an assistant prompted line by line. This autonomy is the direct reason 3,000 lines of code can be generated in a short time: the agent can produce complete implementations of multiple files and modules at once, expanding the task granularity from "write a function" to "implement a feature." This also explains why PR sizes spiral out of control—the generation unit has moved from lines to modules, while the review unit remains at lines.

Pull Request (PR) is the core review unit in code collaboration platforms (like GitHub, GitLab), representing a set of code changes to be merged into the main branch. Reviewers gatekeep code quality by reading diffs, commenting, approving, or requesting changes. PR size (number of changed lines, files involved) directly affects review effectiveness: research shows that for PRs over 400 lines, reviewers' probability of finding defects drops significantly. The 3,000-line PR in the article far exceeds this threshold, causing reviewers to lean toward "rubber stamp" approvals. PR merge wait time and number of change requests are key metrics for measuring review bottlenecks—the former reflects queue backlog, the latter reflects review depth.

The Small PR Comeback: How 40 Lines Beat 3,000

The turning point in the drama comes from an overlooked team member, Priya. She asks a question no one answers: "Which file handles the booking?" Then she reads the code herself, finds the problem, and writes a 40-line fix and a test.

According to the YouTube channel's presentation of this plot, this PR is reviewed, approved, and merged within 90 seconds—and enters the main branch earlier than the 3,000-line PR. The test fails without the fix and passes with it, which is the signal reviewers most want to see.

In contrast, a 3,000-line PR requires reviewers to ask line by line, "If this is wrong, what breaks?" This isn't a matter of reading speed, but the essence of review work: it's not a read-through, but risk reasoning. 40 lines can complete two rounds of questioning within a coffee break; 3,000 lines exceed the reasonable scope of a single review session.

The Organizational Dilemma Behind the Data

The Harvard paper's data is worth mentioning, but needs to be treated with caution—the original video also explicitly states it "has not yet undergone peer review." According to the study, nearly 80% of companies adopted AI review tools after introducing coding agents.

Multi-source cross-validation shows that technical commentators on different platforms diverge in their interpretation of this data. Some believe the 30% code increment is pure waste and should be suppressed through stricter admission control; others believe the increment itself is neutral, and the problem is that organizations haven't scaled review capacity in sync, causing the increment to turn into backlog.

These two views are not contradictory. The consensus is: AI generation speed improvements alone won't automatically translate into delivery speed improvements unless review throughput improves in sync. The disagreement is only about the governance path—restrict generation or restructure the review process.

Peer Review is the cornerstone of quality control in academic research. The Harvard working paper in the article "has not yet undergone peer review," meaning its data and methods have not been systematically examined by independent experts, and conclusions may have biases or omissions. When citing such research in technical decisions, it should be treated as an "early signal" rather than a "definitive conclusion." Peer review typically includes methodological scrutiny, data replication, and assessment of conclusion soundness, and can take months. This is why the original video specifically notes this status—reminding viewers to remain cautious when adopting data like the "30% code increment," and to avoid using unverified research directly as a governance basis.

Practical Implications: Design Review as a Product

The drama's ending offers a simple solution: the protagonist splits the 3,000 lines into small PRs, deletes two redundant login systems, keeps only a good one, and commits to reading every PR before Monday's demo.

This solution corresponds to several actionable practice principles:

Control PR size. 40 lines is a magnitude where risk reasoning can be completed in a single focused session. Beyond this magnitude, review quality drops non-linearly.

Require test evidence. Priya's PR passes in 90 seconds because the test itself constitutes a verifiable review signal. Large PRs without tests can only rely on reviewer trust, and trust is the scarcest resource in the AI generation era.

Make authors bear the responsibility of explanation. The teaching assistant's requirement in the drama—"everyone explains their code"—is the most effective precondition for review. Code that can't be explained shouldn't enter the main branch, regardless of who wrote it.

AI review tools are辅助, not a replacement. They can catch patterned defects but cannot replace judgment of business semantics. Letting them review their own output is like letting students grade their own exams.

The last line of the drama is the protagonist's reaction after pulling the reviewer into 10 PRs: "57."—57 PRs pending review. This number is both a punchline and the real situation of engineering teams today. Generation is not the bottleneck; reading is.

One-line Summary

AI coding agents boost code generation speed, but the review bottleneck prevents the increment from translating into delivery value.

Paragraph Summary

Through a satirical short drama and Harvard working paper data, the article reveals the core contradiction brought by AI coding agents: code volume up 30%, PRs up 23%, but no significant change in completed features or fixed bugs, PR merge waits lengthened by 49%, and change requests doubled. The review stage becomes the narrowest gate in the entire pipeline, due to volume shock and quality degradation—giant PRs cause reviewers to give up reading, and AI review tools become rubber stamps. In the drama, a 40-line small PR passes quickly because it includes test evidence, contrasting with a shelved 3,000-line PR, showing a non-linear relationship between review quality and PR size. The article proposes practical principles: control PR size, require test evidence, make authors explain code, and position AI review as辅助—emphasizing that generation is not the bottleneck; reading is.