RIP Pull Requests: The 21-Year Code-Review Ritual Built for Humans Is Quietly Dying

On April 15, 2026, GitHub did something it had never done in 21 years: it let repo owners disable Pull Requests on their open-source repositories. Until that day, you could only turn off Issues. PRs were treated as a permanent piece of plumbing — the load-bearing wall that held the entire modern code-review culture in place.

The same week, Latent Space filed the obituary: "RIP Pull Requests (2005–2026)". The headline was deliberately blunt. The argument underneath it is more interesting — and more uncomfortable for anyone who has built their team's identity around code review.

PRs did not get worse. The humans they were designed for are no longer the bottleneck.

What PRs Were Actually Designed For

Pull Requests were proposed on the Git mailing list in July 2005 and popularized by GitHub three years later. Read the original design — or any of the thousand Medium posts celebrating "the GitHub flow" — and the assumption is always the same:

Code will be written by one human at one moment, then reviewed by a different human at a later moment, and the only way to bridge that gap is a public thread with diffs, comments, and an explicit sign-off.

Five load-bearing assumptions:

1. Asynchronous human contributors. Someone writes code tonight; someone else reads it next week.
2. Untrusted code from strangers. The reviewer cannot trust the author to have read the style guide, written tests, or not pasted in a backdoor.
3. Discussion as a forcing function. Disagreement has to be resolved in a public thread because there is no other channel.
4. The reviewer is the bottleneck. Maintainers are scarce, contributors are plentiful, and the merge button sits behind a human pair of eyes.
5. Verification is mostly eyeballing. Tests are a courtesy; the real check is "does this diff look right to a senior engineer."

Every PR template you have ever filled out — "What does this PR do?", "How to test", "Screenshots", "Checklist" — is a ritual built on top of those five assumptions.

Why the Assumptions Are Collapsing — At Once

Three launches in the same week made the collapse visible. None of them mentioned PRs. All of them make PRs less necessary.

Anthropic shipped Claude Opus 4.7 on April 16. SWE-bench Pro jumped from 53.3% to 64.3% — eleven points in one cycle. Document reasoning went from 57.1% to 80.6%. On Vals AI's Vibe Code Benchmark, Opus 4.7 scored 71%; the highest score on that benchmark 4.5 months ago was 25%. Anthropic set a new xhigh reasoning effort as the default in Claude Code. Cat Wu, who runs Claude Code, told users on launch day to treat the model "as an engineer you delegate to, not a pair programmer you micromanage." Boris Cherny published the companion guidance: front-load goals, constraints, and acceptance criteria; encode the verification workflow in claude.md or a skill; let the machine verify its own work.

That last sentence is the one that kills PR-as-ritual. If the model can run the test suite, benchmark the result, and write a model card before asking for human attention, what exactly is the human reviewer reviewing?

OpenAI shipped "Codex for (almost) everything" on April 16. The new Codex app for macOS and Windows added computer use, in-app browsing, image generation, memory, and plugins. In the same window, OpenAI split the Agents SDK harness from compute/storage, open-sourced the harness, and let Cloudflare, Modal, Daytona, e2b, and Vercel plug their own sandboxes underneath. The competitive moat shifted, in OpenAI's own framing, from "we run the model" to "we orchestrate the workflow." The workflow no longer assumes a human sits at the end of it.

Aaron Levie, writing about Building for Trillions of Agents, made the line explicit: "the path forward is to make software that agents want." Git-based workflows were made for human collaboration reasons. Once you remove the human bottleneck from the flow of code, the Git-shaped workflow is no longer a neutral default — it is a layer built around a constraint that no longer exists.

The "Prompt Request" Has Already Won the Maintainer Vote

You do not have to take the meta-argument on faith. The maintainers of the most stressed open-source projects have already defected.

Pete Steinberger, who maintains dozens of high-traffic libraries, has been telling audiences for over a year that he only wants "Prompt Requests, not Pull Requests." His reasoning, quoted in the Latent Space obituary:

1. No merge conflicts.
2. The maintainer can edit the prompt faster than reading the code.
3. Less risk of malicious or insecure code being slipped into an innocent-looking PR.

Theo (thekitze) has said the same thing, with fewer words and more heat.

Mitchell Hashimoto (HashiCorp co-founder) and Amp Code have gone further: they built a "reputation" system for handling untrusted code contributions. The PR author's GitHub history, prior merges, and trust score become the gating signal. The diff itself is secondary.

If the maintainer no longer trusts the diff, the PR was never really about the diff — it was about the trust ritual. Replace the ritual with a score, and the PR becomes a vestigial form.

The quadrant makes the structural case. The upper-left quadrant — pair programming — is for high human contribution, low async need. The lower-right quadrant — long-running async human teams — is where most open-source maintenance has lived for two decades, and where the traditional PR still earns its keep. The lower-left quadrant — Agent-dominated work with no genuine async requirement — is where most new code is being written in 2026. That is the death zone for the PR-as-ritual, and that is where Opus 4.7, Codex sessions, and the new Claude Code defaults are spending their hours.

The Counter-Argument, Taken Seriously

PRs are not dying in the literal sense. They will survive for years in places where the assumptions still hold:

• Small teams where two engineers pair on every change.
• Public open-source projects where strangers contribute code they have never run.
• Compliance and regulated environments where a human signature is the audit trail.
• Onboarding, where a PR is the cheapest way to teach a junior engineer how the codebase thinks.

Calling the death of the PR is like calling the death of the post office. The post office is not dead. It just no longer shapes the architecture of the road network.

That distinction matters. We are not watching PRs lose a quality war. We are watching the architecture of code contribution lose the constraint that made PRs load-bearing in the first place.

What Replaces the Ritual

Three concrete moves for engineers and team leads who want to stop pretending the old workflow still serves them.

For individual developers. Rewrite your PR template. Replace the "What does this PR do?" section with a "Prompt + Acceptance Criteria" block: the goal you stated, the constraints you gave the model, the verification you asked it to run, and the output you reviewed. That is the new unit of trust. Everything else is decoration.

For team leads. Audit your "review checklist." If a checklist item is "does this look right to a senior engineer," it is now a bottleneck you can replace with "does the model run the relevant test suite and produce a passing benchmark." If a checklist item is "did the author follow the style guide," it is now a pre-commit hook, not a review item. Be honest about which items still need a human.

For open-source maintainers. Try the experiment GitHub just made legal. Turn off PRs on a low-stakes repo. Move the contribution flow to Issues with a clear "patch format" attached, plus an auto-verify step (CI runs the patch against a hidden test set). Track whether you actually lose contributions, or whether you stop spending your weekend reading diffs that the model could have validated in seconds.

The Bet

PRs will still exist in 2030. They will still appear in onboarding docs, conference talks, and the workflow diagrams drawn by recruiters. They will not, however, be the default plumbing for new code.

The bet is not "PRs disappear." The bet is that within 24 months, the median professional codebase will route the majority of its code changes through something that does not look like a Pull Request at all — a prompt, a verification harness, a merge — and that the people still writing PR templates will be the same people still faxing purchase orders.

Latent Space put the dates on the tombstone. Anthropic and OpenAI, in the same week, put the tools in the hands of everyone who wants to walk past it.

The 21-year ritual is not being murdered. It is being outgrown, by exactly the part of the workflow it was never designed for.