Is the PR Dead? AI Coding Makes Code Review the Bottleneck—How to Cope with 34x the Code Volume

Title

Is the PR Dead? AI Coding Makes Code Review the Bottleneck—How to Cope with 34x the Code Volume

Meta Description

AI coding tools have increased code submissions by 30%, but PR merge times have lengthened by 49%, with senior engineers becoming the bottleneck. Some developers have disabled PRs and only accept ideas. This article analyzes research data and case studies to explore the direction of PR process evolution.

Article Content

As AI agents flood into software development processes, code generation speed has soared—but a neglected link is collapsing: code review. A study covering 718 enterprises and 700,000 developers shows that AI coding tools have increased code submissions by about 30%, yet final deployment volume has barely changed, while the time from Pull Request (PR) to merge has surged 49%, extending from about 7 days to over 10 days. A more intuitive example comes from Anthropic: its daily code changes jumped from 2,500 to over 30,000, an increase of more than 10x. Faced with such massive code volume, manual review has long been overwhelmed. Some developers have even announced disabling the PR feature, accepting only ideas rather than code. Is the PR really about to be eliminated?

AI Coding Boosts Code Output but Gets Stuck at Review

This preprint study, not yet peer-reviewed, was led by Fiona Chen and James Tretton of Harvard University, with data from engineering efficiency platform Jellyfish, covering 718 software enterprises between 2021 and 2026. The researchers compared engineering metrics before and after the introduction of AI tools, finding that the code generation stage indeed saw greatly increased efficiency: lines of code increased 30%, commits increased 20%, and PR count increased 23%. However, the task completion volume recorded in Jira showed no significant change. Where is the problem?

The key issue is that the cycle from PR creation to merge has been stretched by 49%. This means that while writing code has become faster, the "review gate" before code enters the main branch has become a new choke point. The study points out that most teams still require senior engineers for final approval, and AI-generated code often needs more careful scrutiny. A typical case: in one team, a senior engineer originally reviewed a junior developer's code once a week; after AI adoption, they had to review daily and were ultimately required to approve all changes. This senior engineer became the "human bottleneck" in the process.

Preprint refers to academic papers that have not yet undergone peer review but have been publicly posted on preprint platforms (such as arXiv, SSRN). Its advantage is fast publication, allowing researchers to share the latest findings first; its disadvantage is the lack of independent expert review, so readers must judge the reliability of conclusions themselves. The Harvard study cited in this article falls into this category, so conclusions such as "PR merge time lengthened by 49%" should be regarded as preliminary evidence, not definitive. Readers should cross-validate with more peer-reviewed literature or industry reports.

Pull Request (PR) is the core collaboration mechanism of code hosting platforms such as GitHub and GitLab. After completing code modifications, a developer initiates a PR requesting to merge the branch into the main branch; other members can comment line by line and suggest changes, and upon approval, someone with permission approves the merge. PRs are not only a technical means of code merging but also carry functions of code review, knowledge sharing, and change recording, and are therefore often regarded as the "gatekeeper" of code quality.

When AI Generates PRs in Bulk, Where Do Human Reviewers Go?

AI has not only increased code volume but also changed the nature of PRs. In the past, the person submitting a PR at least needed to understand the code, which itself constituted a quality filter. Today, anyone can direct an AI agent to generate large amounts of code and open a PR in seconds, while the submitter may not have read what the AI wrote at all. This leaves reviewers facing a flood of machine-generated code that may be meaningless.

Anthropic's case is highly representative: daily code changes leapt from 2,500 to over 30,000. Imagine if each change corresponded to a PR—how could a review team digest that? In reality, many PRs may be hastily approved or simply ignored, sharply increasing code quality risks. More ironically, in some scenarios a closed loop of "AI generates code, AI reviews code" has already emerged, marginalizing humans.

AI Agent refers to AI systems capable of autonomous planning, tool invocation, and execution of multi-step tasks. In coding scenarios, agents can read requirements, write code, run tests, and even automatically submit PRs, while humans only need to give natural language instructions. This is fundamentally different from traditional code completion tools (such as early Copilot): the latter is "human writes primarily, AI assists," while the former may be "AI writes primarily, human only gives instructions." This is precisely the root of the change in the nature of PRs—submitters may never have read the AI-generated code line by line, and reviewers face a code flood lacking human understanding as a pre-filter.

A Radical Experiment: Disable PRs, Accept Only "Ideas"

Facing this dilemma, a well-known developer in the AI agent field (named Huntley according to the video) took an extreme approach: disabling the PR feature in his GitHub project and keeping only the discussion area. His logic is straightforward: reviewing machine-generated PRs has low value; what he really needs are "ideas." If someone proposes a good idea, he can implement it himself by invoking an AI agent in minutes, without accepting external code.

He gave a concrete requirement as an example: use a PR to prevent Git force pushes. He directly wrote a Nix configuration file, applied the modification to local, Docker, and test environments, all without forking or others' approval. This approach also touches an old wound in the open source world: project maintainers are often morally coerced into accepting and maintaining PRs submitted by others for free. The "remix" model lets ideas flow freely, with no debts owed.

Nix is a declarative package management and system configuration tool that describes the entire software environment through purely functional configuration files, ensuring consistency across local, container, and test environments. The developer in the article used a Nix configuration file to implement the "prevent Git force push" requirement, precisely leveraging Nix's reproducible, cross-environment consistent characteristics: write one configuration and apply the same modification across local, Docker, and test environments without requiring others to submit PRs. This explains why he is confident that "ideas can be implemented in minutes"—Nix lowers the marginal cost of environment setup and deployment, making it possible for individual maintainers to bypass external code contributions.

Can Giant Projects Withstand "De-PRing"?

This experiment on a personal project seems dangerous when applied to large open source projects. Projects like Linux or React that affect millions of users rely on strict official review to ensure security and stability. If everyone makes "remixes" based on their own ideas, the ecosystem will fragment into countless versions—which one should users trust? Who can guarantee that a given version has no malicious code implanted?

The video author also admits that review will not disappear—it will only shift location: from the endorsement of the project name to the judgment of users when choosing a version. But for ordinary users, the bar is too high. Therefore, a more realistic path may be the evolution of the PR process rather than simple abolition. For example, using AI-assisted review, automated testing, and finer-grained permission control to focus human energy on high-risk changes.

Conclusion: PRs Won't Disappear, but Must Be Reshaped

The efficiency gains brought by AI coding tools are real, but the bottleneck shift is also real. As the gatekeeper of code quality, the PR's form may need to change, but its core goal—ensuring code reliability and security—will not change. For personal projects, disabling PRs may be feasible; for serious teams and large open source projects, a more pragmatic approach is to redesign the review process, letting AI handle more mechanical checks while humans focus on architecture and logic. Otherwise, the flood of code will only burst the review dam.

Are you ready for a future without PRs?

One-line Summary

AI coding increases code submissions by 30%, but PR merge times lengthen by 49%, making review the new bottleneck; the PR process urgently needs reshaping.

Paragraph Summary

A Harvard preprint study based on 718 enterprises and 700,000 developers shows that AI coding tools have increased code submissions by about 30%, but final deployment volume has barely changed, while PR-to-merge time has surged 49%, from about 7 days to over 10 days. Anthropic's daily code changes jumped from 2,500 to 30,000, overwhelming manual review. Senior engineers have become the "human bottleneck," AI-generated PRs lack human understanding as a quality filter, and even a closed loop of "AI generates, AI reviews" has emerged. Some developers radically disable PRs, accepting only ideas and implementing them with AI themselves. But giant open source projects still need strict review; a more realistic path is to let AI handle mechanical checks and humans focus on architecture and logic, driving PR process evolution rather than simple abolition.