RIP Pull Requests (2005–2026): The 21-Year Workflow Git No Longer Needs
胡新宇
发布于 2026-08-17
On April 14, 2026, GitHub made Pull Requests optional for the first time. The 21-year workflow built for human collaboration is being made optional — because the contributors arriving are not human.
RIP Pull Requests (2005–2026): The 21-Year Workflow Git No Longer Needs
On April 14, 2026, GitHub shipped a feature that should have made every engineering blog on the internet ring alarm bells: you can now disable Pull Requests on a repository. Until that day, you could only disable Issues. The change went out quietly — caught first by Sam Morrow-Drumm on X and reported the next morning by Latent Space's AINews (latent.space/p/ainews-rip-pull-requests-2005-2026) — but the implication is enormous.
For 21 years — since Linus Torvalds announced the workflow on the git mailing list in July 2005 (lore.kernel.org/git/20050726073036) — the Pull Request was a load-bearing pillar of open source. GitHub popularized it in February 2008 (github.blog/2008-02-23), and for nearly two decades every team on earth built their contribution policy around the same ceremony: branch, push, open PR, assign reviewer, wait, debate, request changes, push again, approve, merge.
The whole ceremony was a coordination protocol for humans. AI does not need a meeting to merge code.
The PR was a patch, not a protocol
The PR solved exactly one problem: how do two humans who have never met agree that one line of code can replace another? Three assumptions are baked into that question, and every assumption is now breaking:
Humans write the diff.
Humans read the diff.
Humans merge the diff.
The ceremony is bandwidth-limited by design. Reviewer time, context switching, calendar slots — all of it is human latency dressed up as process. A four-person review that takes two days is "thorough." A 12-hour async review is "fast." A one-hour agent loop that retries, tests, and merges is "reckless" — except the agent's PR ships with a passing test suite and a reproducible build, which is more than most human PRs can claim.
#AI Agent#Agent#AI代码#AI工程#上下文工程
RIP Pull Requests (2005–2026): The 21-Year Workflow Git No Longer Needs
OpenAI Frontier ran a five-month experiment that should quiet the recklessness objection. Ryan Lopopolo, who leads the Frontier Product Exploration team, told Latent Space in early April 2026 that his team built an internal beta product with zero human-written code, zero human-reviewed code before merge, more than a million lines in the repo, thousands of PRs across multiple Codex generations, and roughly a billion tokens of inference per day (latent.space/p/harness-eng). At market rates and assuming caching, that is approximately $2,000–3,000 per day. Lopopolo calls it borderline negligent if your team is not spending at least that.
When the agent failed, the team's response was no longer "prompt it better" or "try harder." The response was: what capability, context, or structure is missing? That is not a workflow that needs a Pull Request. It needs a spec, a test, and a build loop.
Three things AI breaks about the PR
1. The reviewer is the bottleneck
Pete Steinberger (the developer behind the now-ubiquitous signing library) and Theo have been arguing for "Prompt Requests" rather than Pull Requests for two years. Their reasoning is short and sharp:
No merge conflicts, because the agent owns the worktree.
It is easier for the maintainer to fix the prompt than read a 1,400-line diff.
It is less likely that malicious or insecure code slips into an innocent-looking PR.
The last point matters more than the first two. Most security incidents in open source in the last decade started with a friendly-looking PR from an unfamiliar GitHub profile. A reputation system that judges output rather than identity, like the one Mitchell Hashimoto and Amp Code are building, is structurally harder to social-engineer. The PR's review chain assumes the contributor is human and accountable; that assumption is breaking faster than the workflows built on top of it.
2. The GitHub profile is no longer proof of trust
For most of open source history, a contributor's value was their commit history. The PR ritual gave newcomers a way to demonstrate competence to strangers — by submitting a small, reviewable change to a project they did not own. That worked when the contributor pool was a few million engineers with predictable skill distributions.
An agent does not have a GitHub profile. It has a build log. When the agent opens a PR, the maintainer cannot use "I know this username" as a heuristic. The contribution either passes the spec-driven CI gate, or it does not. Mitchell Hashimoto's Amp Code experiment and several reputation-ledger projects now in beta all share the same shape: trust is computed from output quality, not contributor identity. GitHub's profile-as-resume model was a 2008-era workaround for a 2008-era collaboration problem. It is the wrong primitive in a world where the contributor is a model with weights, not a person with a résumé.
3. The spec is the new diff
Aaron Levie's April 2026 essay "Building for Trillions of Agents" makes the argument explicit: "the path forward is to make software that agents want" (x.com/levie/status/2030714592238956960). Humans invented git for human collaboration reasons. Git-based workflows are increasingly unsuitable once the human bottleneck is removed from the flow of code.
If the bottleneck moves from human attention to model capability, the artifact that travels through the workflow also changes. A diff is what a human sends. A spec is what an agent reads. The OpenAI Frontier team's failure response is the cleaner formulation: when the build fails, do not patch the diff. Patch the spec, the test, the build script, or the harness. The PR diff becomes a downstream artifact of the spec, not the unit of contribution.
Why GitHub did it now
The disable-PR flag is a six-line change. GitHub could have shipped it in 2014. The question worth asking is why April 2026 — and why so quietly.
Two shifts were happening at the same time. First, the agent contribution rate crossed an internal threshold at GitHub itself. Industry-side, the Latent Space AINews summary on April 15 reported that a non-trivial fraction of new commits across major open-source repositories are now agent-authored in their index of public repos. GitHub has not published a number, but the maintainer-fatigue pattern is observable: threads on Hacker News, Lobsters, and the GitHub Community forum in March and April 2026 are dominated by maintainers asking how to slow down agent PRs, not how to encourage them.
Second, maintainer fatigue reached the point where the cost of enforcing the PR became higher than the cost of removing it. The economic logic is straightforward: a PR that nobody reviews is a worse artifact than no PR at all. Disabling the PR is cheaper than enforcing it. GitHub shipped the option because the option is, for many projects, the right answer.
What replaces the PR
The PR will not vanish next month. It will hang around for a decade — half the industry still believes in code review theater, and the other half has not yet felt the cost. But the flag exists now. The first repository that disables PRs without anyone noticing will be the proof.
The question is no longer whether your team can run without Pull Requests. The question is whether you have a workflow that can survive when half of your contributors are not human. Here is the minimum viable version of that workflow — the three things every engineering org should ship before the end of this quarter.
1. Rewrite CONTRIBUTING.md for prompts, not branches
The first change is the cheapest. Replace your branch-naming policy and PR-template with three artifacts: a spec template, a prompt template, and a failure-mode log. The PR diff still travels with the change, but it travels as evidence the spec was met, not as the primary artifact the reviewer reads. Lopopolo's team calls these "skills" — markdown files that encode engineering taste directly into context the agent can use. You can ship the first one in an afternoon.
2. Replace the reviewer gate with a spec-CI gate
The hard part is the second change. Your CI pipeline currently scores a PR diff against a reviewer. Replace it with a pipeline that scores the spec against the diff: does the change satisfy every assertion in the spec? Does the spec satisfy every invariant in the type system? Does the build run in under a minute? Lopopolo's team treats one minute as the upper bound on the inner build loop. Builds slower than that do not just slow humans down; they strangle the agent's retry budget. If your CI takes 15 minutes, your agent-driven workflow cannot exist.
3. Build a reputation ledger, not a contributor ladder
The third change is the one most teams will resist. Stop tracking contributor identity through GitHub usernames. Start tracking contribution quality through a ledger: which agents and which humans shipped changes that survived their first 30 days in production? Which ones generated the most reverted commits? Which ones consistently passed the spec-CI gate on the first try?
Amp Code, Hashimoto's project, and a handful of in-house tools at OpenAI, Anthropic, and Stripe are already running versions of this. The reputation ledger is the PR's logical successor, the same way the spec is the diff's logical successor and the build is the reviewer's logical successor. None of these replacements require a flag-day migration. All of them require that someone on your team write the first ledger entry.
The bigger picture
The disable-PR flag is not the story. The story is that the workflow the rest of the industry has been politely ignoring for two years — that humans are still the bottleneck, that review latency is the most expensive tax in software, that the spec is the artifact, not the diff — finally has a UI checkbox attached to it.
For 21 years, the Pull Request was the universal ceremony: a small, repeatable ritual that let strangers collaborate on code without meeting in person. The ceremony worked because the contributors were human, the bottleneck was human, and the cost of the ceremony was a small fraction of the value of the collaboration.
None of those three conditions hold anymore. The disable-PR flag is GitHub admitting it. The teams who notice first will be the teams shipping the most code per engineer per quarter. The teams who notice last will still be arguing about code review etiquette in 2030.
The PR is not dead. But the assumption that built it is.
