{"slug": "the-pull-request-lives-on-ai-gave-it-a-bigger-job", "title": "The pull request lives on. AI gave it a bigger job.", "summary": "GitHub reported that merged pull requests grew from 25 million per month in January 2023 to 90 million per month today, while commits are on pace to exceed 14 billion in 2026, driven by AI coding agents and automated systems. CodeRabbit observed an average 59% increase in pull requests per individual from November 2025 to July 2026, and a 33% increase per repository. Industry commentators, including Burak Dede, Andy G., Bill Easton, and The Pragmatic Engineer, argue that AI has transformed the pull request's role, with some declaring it 'dead' and reimagining it as 'prompt requests.'", "body_md": "The obituaries for the pull request keep piling up.\n\n[Burak Dede](https://burakdede.com/blog/the-pull-request-is-dead-surviving-the-ai-code-avalanche/) called his essay “[The Pull Request is Dead: Surviving the AI Code Avalanche.](https://burakdede.com/blog/the-pull-request-is-dead-surviving-the-ai-code-avalanche/)” [Andy G.](https://gieseanw.wordpress.com/2026/03/20/pull-requests-are-dead-long-live-pull-requests/) wrote “[Pull requests are dead, long live pull requests](https://gieseanw.wordpress.com/2026/03/20/pull-requests-are-dead-long-live-pull-requests/),” arguing that code reviews need to be different than before.\n\n[Bill Easton](https://strawgate.com/writing/pull-requests-are-dead-long-live-context/) published “[Pull Requests Are Dead. Long Live Context,](https://strawgate.com/writing/pull-requests-are-dead-long-live-context/)” with the argument that AI killed the drive-by pull request. [The Pragmatic Engineer](https://newsletter.pragmaticengineer.com/p/the-creator-of-clawd-i-ship-code) profiled an agent-heavy workflow under the headline “[I ship code I don’t read](https://newsletter.pragmaticengineer.com/p/the-creator-of-clawd-i-ship-code)” and summarized the shift as: “Pull requests are dead, long live ‘prompt requests.’”\n\nThe writers were looking at different parts of the transition. Dede focused on verification backpressure. Andy focused on preserving the reasoning behind decisions. Easton focused on drive-by open source contributions. The Pragmatic Engineer examined Peter Steinberger’s OpenClaw workflow, where he treats pull requests as “prompt requests” and focuses review on planning, architecture, and agent-verified results.\n\nNone of them agree on the cause of death, but they all raise the same question: What role does the pull request play when AI generates more of the code?\n\n## What the data shows\n\nPull request volume is rising as AI agents and automated systems join developers in writing code and proposing changes.\n\nAgents now turn issues, tickets, and incidents directly into code changes, while automated systems open pull requests for dependency updates and routine maintenance. All of it arrives in the same review queue, and GitHub's numbers show how fast that queue is growing.\n\nMerged pull requests grew from [25 million per month in January 2023](https://github.blog/open-source/maintainers/how-pull-request-limits-are-cutting-down-the-noise/) to [90 million per month today](https://github.blog/open-source/maintainers/how-pull-request-limits-are-cutting-down-the-noise/). Commits tell an even sharper story. GitHub recorded 1 billion commits in all of 2025, and developers now push 275 million per week, putting them on pace to hit [more than 14 billion this year](https://x.com/kdaigle/status/2040164759836778878).\n\nCodeRabbit saw an average 59% increase in pull requests per individual from November 2025 to July 2026. Pull requests per repository rose an average 33% over the same time period.\n\nGitHub is also feeling that growth at the platform level. The company has tied its [scaling work](https://github.blog/news-insights/company-news/an-update-on-github-availability/) and outages to the acceleration of agentic development, citing rapid growth in pull request activity, API use, automation, and large-repository workloads. A single pull request can involve Git storage, mergeability checks, Actions, search, permissions, webhooks, APIs, caches, and databases. GitHub attributed an August 17, 2026, outage to “[network saturation](https://www.githubstatus.com/history)” on load balancers in its Central U.S. region.\n\nBefore coding agents entered the picture, developers complained that pull requests were slow, bureaucratic, and dependent on human bottlenecks. AI coding agents seemed built to alleviate that frustration, promising a development process where code could appear on demand, without the drag of comments, approvals, and debate.\n\nThis vision is sometimes called “just-in-time software.” The phrase echoes just-in-time compilation, where code is compiled while a program runs, not in advance. Applied to AI, the concept shifts from compiling code on demand to creating software on demand. A user describes what they need, and an agent turns that request into working software on the spot.\n\nSoftware on demand makes the demise of pull requests sound plausible. When creation feels immediate, review can seem like a relic of a slower development process.\n\nThe promise makes the demise of pull requests sound plausible. When creation feels immediate, review looks like a relic of a slower process, and the argument holds right up until the code has to run in production. Turning generated code into dependable software still relies on testing, security checks, and a human who is accountable for the result.\n\nAt CodeRabbit, we call the system for managing software changes from proposal through production [Agentic Change Management](https://www.coderabbit.ai/blog/introducing-agentic-change-management). It gives proposed changes independent validation, a clear priority, and an explanation reviewers can understand. The same context follows each change after merge, helping teams monitor risk and keep the codebase governable as it evolves.\n\n## What’s the diff?\n\nAgentic Change Management starts with independent review and validation, then helps teams decide where human attention goes. More proposed changes do not create additional review time, and arrival order only tells a team which pull request came first, not which one deserves a reviewer first.\n\n[CodeRabbit Triage](https://www.coderabbit.ai/blog/introducing-agentic-change-management#coderabbit-triage-directs-attention) prioritizes pull requests according to consequence rather than arrival time. It routes higher-stakes work to the people equipped to judge it, while routine, low-risk changes follow automated paths.\n\nTriage settles which pull request gets opened first, but not what happens once it's open. A traditional diff shows where the code changed and little else, leaving the reviewer to reconstruct how the pieces fit together and what they mean for the system. As agent-generated pull requests grow in size and scope, that work becomes a larger part of the review itself.\n\nCodeRabbit’s [Change Stack](https://www.coderabbit.ai/blog/introducing-change-stack-the-first-ai-native-code-review-interface) reorganizes the pull request into a guided walkthrough. It groups related modifications into semantic layers, places those layers in a logical reading order, and anchors each explanation to the relevant lines in the diff. When a diagram makes the behavior easier to understand, it places that visual beside the code.\n\nThe repository and pull request workflow stay in place. Triage points teams at what matters most, and Change Stack helps reviewers understand larger changes that come with less author context. The decision to ship remains with the people who will own the outcome.\n\n## What a pull request carries now\n\nA pull request traditionally worked as a human-to-human request, with a developer proposing a change and walking a reviewer through the decisions behind it. When an agent produces the change, the person who opens the pull request may not be able to explain the thought process that generated the code. The pull request itself has to carry that context.\n\nIn practice, that means telling the full story of the change, from the prompt that kicked it off to the approval that ships it. The issue explains why the work exists, agent activity shows how the code took shape, and tests and security findings give reviewers something sturdier than vibes to judge it against. Review comments capture what the team debated, and the approval records who said yes and who answers for it in production.\n\n## Maintainers are changing the rules\n\nOpen source maintainers see the missing context first, courtesy of pull requests from contributors who can't answer questions about their own code. GitHub announced in June that maintainers could [set caps](https://github.blog/changelog/2026-06-17-limit-open-pull-requests-for-users-without-write-access/) on the number of concurrent pull requests outside contributors may keep open, and [previewed](https://github.blog/open-source/maintainers/how-pull-request-limits-are-cutting-down-the-noise/) other changes aimed at the deluge.\n\n“Maintainers carry the trust layer of open source,” GitHub's Director of Open Source Ashley Wolf told CodeRabbit. “As AI makes it easier to generate contributions, we want to give maintainers more choice in how they receive and review that work.\n\n“Pull requests are far from dead. They are evolving from simple code submissions into richer checkpoints for context, review, and accountability, and our job is to make sure maintainers have the controls they need as that evolution accelerates.”\n\nGitHub also shipped two pull request access controls earlier in the year. Maintainers can disable pull requests or restrict their creation to collaborators. Those settings give projects more control over how they accept contributions.\n\nSome projects made moves before GitHub did. Tldraw began [automatically closing pull requests from external contributors](https://tldraw.dev/blog/stay-away-from-my-trash) after a wave of low-quality AI submissions, and Kubernetes [drew the line](https://www.linkedin.com/posts/katcosgrove_pull-request-process-share-7448418176419250176-k9Gh/) at ownership, allowing AI to help write a change as long as a human contributor understands the change and can defend it in review. Curl maintainer Daniel Stenberg has [written](https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-slops/) about drowning in AI-generated security reports. They aren't pull requests, but any maintainer will recognize the problem. Someone fires off a report in minutes, and Stenberg burns an afternoon proving it wrong.\n\nEaston's drive-by argument comes down to the same math. When generating code is cheap and understanding a project isn't, the most useful thing an outsider can offer is a good bug report with a way to reproduce it. From there, a maintainer can hand the problem to an agent, get back a change that follows the project's conventions, and review it like any other pull request.\n\n## The pull request has a bigger job now\n\nThe question the obituaries raised has an answer, and it is not a funeral. As AI generates more of the code, the pull request's job gets bigger.\n\nThe writers were right about the strain, but wrong about the patient's prognosis. The industry's response has been to reinforce the pull request rather than retire it. GitHub added maintainer controls, Kubernetes wrote ownership rules, and CodeRabbit built triage and guided review into the workflow, all of it there to help people evaluate more changes than they can read line by line.\n\nAn approval could get away with being a quick LGTM when the person who wrote the code could answer for it. An agent can't answer for anything, so approval now has to mean that a person understood the change, weighed the evidence, and agreed to own what happens next.", "url": "https://wpnews.pro/news/the-pull-request-lives-on-ai-gave-it-a-bigger-job", "canonical_source": "https://coderabbit.ai/blog/the-pull-request-lives-on-ai-gave-it-a-bigger-job", "published_at": "2026-08-20 13:00:00+00:00", "updated_at": "2026-08-21 06:12:39.820112+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "developer-tools"], "entities": ["GitHub", "CodeRabbit", "Burak Dede", "Andy G.", "Bill Easton", "The Pragmatic Engineer", "Peter Steinberger", "OpenClaw"], "alternates": {"html": "https://wpnews.pro/news/the-pull-request-lives-on-ai-gave-it-a-bigger-job", "markdown": "https://wpnews.pro/news/the-pull-request-lives-on-ai-gave-it-a-bigger-job.md", "text": "https://wpnews.pro/news/the-pull-request-lives-on-ai-gave-it-a-bigger-job.txt", "jsonld": "https://wpnews.pro/news/the-pull-request-lives-on-ai-gave-it-a-bigger-job.jsonld"}}