The obituaries for the pull request keep piling up.
Burak Dede called his essay “The Pull Request is Dead: Surviving the AI Code Avalanche.” Andy G. wrote “Pull requests are dead, long live pull requests,” arguing that code reviews need to be different than before.
Bill Easton published “Pull Requests Are Dead. Long Live Context,” with the argument that AI killed the drive-by pull request. The Pragmatic Engineer profiled an agent-heavy workflow under the headline “I ship code I don’t read” and summarized the shift as: “Pull requests are dead, long live ‘prompt requests.’”
The 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.
None 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?
What the data shows #
Pull request volume is rising as AI agents and automated systems join developers in writing code and proposing changes.
Agents 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.
Merged pull requests grew from 25 million per month in January 2023 to 90 million per month today. 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.
CodeRabbit 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.
GitHub is also feeling that growth at the platform level. The company has tied its scaling work 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” on load balancers in its Central U.S. region.
Before 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.
This 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.
Software 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.
The 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.
At CodeRabbit, we call the system for managing software changes from proposal through production 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.
What’s the diff? #
Agentic 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.
CodeRabbit Triage 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.
Triage 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.
CodeRabbit’s Change Stack 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.
The 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.
What a pull request carries now #
A 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.
In 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.
Maintainers are changing the rules #
Open 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 on the number of concurrent pull requests outside contributors may keep open, and previewed other changes aimed at the deluge.
“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.
“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.”
GitHub 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.
Some projects made moves before GitHub did. Tldraw began automatically closing pull requests from external contributors after a wave of low-quality AI submissions, and Kubernetes drew the line 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 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.
Easton'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.
The pull request has a bigger job now #
The 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.
The 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.
An 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.