After Pull Requests: Why the Next Unit of Code Contribution Is Intent, Not a Diff
Site Owner
Published on 2026-07-31
GitHub disabled Pull Requests in 2026. The PR didn't die because AI writes better code — it died because the unit of contribution shifted from diff to intent.
After Pull Requests: Why the Next Unit of Code Contribution Is Intent, Not a Diff
GitHub let maintainers disable Pull Requests for the first time in eighteen years. Not issues. Pull Requests. The feature that GitHub itself popularized in 2008 with a blog post titled, almost embarrassed, "Oh yeah, there's pull requests now" [1]. Last week, the company shipped the kill switch.
The story already got told as a news roundup. Pete Steinberger pushed "Prompt Requests." Theo seconded the motion on X. Mitchell Hashimoto launched a reputation-based review system at Amp. Aaron Levie said "make software that agents want." A few Twitter threads later, the headline wrote itself: PRs are dead, long live prompts.
That's the wrong frame. Pull Requests aren't dying because AI writes better code. They're dying because AI rewrites the trust equation. The PR was always a trust object — a 2005 protocol for humans who didn't trust each other yet. Once the agent in the loop is well-known, well-repped, and well-sandboxed, you don't need a human hovering over every diff. The unit of contribution shifts from "diff" to "intent." And once you shift the unit, the entire workflow collapses with it.
Let's walk through what actually happened, and what to build next.
The Funeral Nobody Mourned
On April 15, 2026, GitHub quietly enabled a repo setting that turns off Pull Requests. For eighteen years, you could only disable Issues. PRs were sacred, the load-bearing wall of open source [2].
The timeline matters. Pull Requests as a term showed up in a July 2005 email to the Linux kernel mailing list — the verb "pull up" was Linus's way of saying "fetch my latest into your tree" [3]. GitHub productized the workflow in 2008 and it has been the default code-collaboration object for almost every developer alive today. Recent grads have never experienced a software world without it.
#AI Agent#审批工作流#Agent#AI代码
The PR's obituary was soft-laid in parallel. The same week, Latent Space ran "RIP Pull Requests (2005-2026)" and noted that the previous round — "Death of the Code Review" — was a warm-up [2]. The headline was provocative but the data was mundane. What was exceptional was the coincidence: GitHub disables PR, OpenAI ships an Agents SDK with file/computer use primitives, Cloudflare ships Project Think, and Vercel/Modal/Daytona/E2B all announce sandbox integrations. All on the same day. Not because someone coordinated it, but because the underlying shift cleared the path for everyone at once.
PR Was Never a Code Object, It Was a Trust Object
A Pull Request is, technically, a set of diffs plus a comment thread. In practice, it's something else entirely. A PR is a trust handshake: an unknown contributor asks a maintainer to believe that their code is worth merging into a shared codebase. The reviewer checks line-by-line because they don't trust the contributor to know the codebase's unwritten rules, and they don't trust the diff to expose secrets.
The PR carried four jobs:
Communication. A description of the change, why it's needed, edge cases considered.
Inspection. A diff for the reviewer to read, sometimes with CI attached.
Negotiation. A comment thread to argue, fix, and re-submit.
Audit. A permanent record of who changed what, when, and why.
All four of those jobs were designed for humans collaborating async across distance. Linus in Portland, a contributor in Helsinki, a release manager in Berlin. The PR worked because humans were the bottleneck. The code would not be merged until a human approved it, and the human's job was to be a low-bitrate firewall.
Now the bottleneck is not the human. The bottleneck is the agent's planning, the agent's context, and the agent's blast radius. The PR's trust handshake was built for the wrong bottleneck.
Why AI Breaks the PR, Not the Code
Three concrete reasons surfaced in the past month, all from named voices with skin in the game.
No merge conflicts. Steinberger's first argument for Prompt Requests is the simplest: agents don't have merge conflicts [2]. The whole "rebase your PR" workflow exists because humans commit to a branch and then forget about it for three weeks. An agent doing the work keeps its context, knows what the rest of the codebase looks like, and updates its mental model as it goes. Conflicts don't appear because the agent never creates a stale branch.
Easier to fix the prompt than the code. This is the underrated one. Steinberger's second point: when a maintainer rejects a PR, the contributor often has to re-derive what the maintainer wanted. The PR was a frozen artifact; the reasoning behind it evaporated as soon as the issue was filed. With a Prompt Request, the maintainer just edits the prompt. The contributor — agent or human — re-runs against the new prompt. The "I wanted something different" round-trip becomes cheap.
Malicious code slips in. The third argument is the one that scares security folks. A PR hides a malicious change inside a 200-line diff. The reviewer skims, sees plausible-looking code, approves. The cost of a bad PR is measured in CVEs. An agent acting on a Prompt Request against a sandbox doesn't get to slip a backdoor into the production tree — the sandbox is the trust boundary, not the diff.
Notice what's not in this list. AI isn't writing better code than humans. AI isn't reading diffs better than humans. The argument isn't quality — it's trust topology. Replace the human bottleneck with the agent harness, and the diff loses the job it was hired to do.
The New Contribution Object: Intent
Here's the part that the news roundups missed. Aaron Levie, writing on X the same week, captured the deep shift: "the path forward is to make software that agents want" [4]. He wasn't being cute. He was naming a transition that has been underway for two years and only became undeniable last week.
Through 2024, the unit of code contribution was a diff. You wanted X. You changed files. You wrote a commit message. You opened a PR. The diff was the contract.
In 2026, the unit is becoming an intent. You want X. You write a prompt that says so. The agent, running in a sandbox, decides what files to touch, what tests to run, what to commit. The contract is the desired outcome, not the desired change.
The structural evidence: OpenAI's new Agents SDK (April 15, 2026) splits the harness from compute and adds first-class primitives for file use, computer use, skills, memory, and compaction [5]. That list is not a feature checklist. It's a list of the things a contributor needs to package intent — what to do, what to remember, how to compact, what file to touch. The diff is not on the list. The diff is downstream.
Cloudflare shipped Project Think the same day, with explicit durable execution, sub-agents, persistent sessions, sandboxed code execution, and a built-in workspace filesystem [6]. The Agent Lee dashboard agent runs in sandboxed TypeScript. The product team is no longer shipping features — they're shipping substrate for intent.
The Ecosystem Convergence: Sandboxes + Reputation
Look at the same week's vendor announcements and a pattern emerges.
Vercel had already shipped multiple Sandbox updates through 2026, including customizable names, sandbox forking, and 32 vCPU/64GB configurations [7][8].
Modal announced official sandbox integration with OpenAI's Agents SDK and demoed a Modal-backed ML research agent with GPU sandboxes, subagents, persistent memory, and fork/resume snapshots [9].
Daytona, E2B, and Cloudflare all shipped the same day, formalizing the same architecture [10].
The architecture is stateless orchestration + stateful isolated workspaces. The orchestrator is the agent harness. The workspace is the sandbox. The contributor (now an agent) is given a sandbox, runs a prompt, produces a result, and the orchestrator decides whether to merge, retry, or discard.
The missing piece is trust. If anyone can spin up an agent in a sandbox, how does the maintainer know which agents to merge? That's where Mitchell Hashimoto's Amp Code comes in. Amp shipped a reputation system for untrusted code contributions — agents earn trust over time, and the trust score gates what they can do without review [11]. It's a primitive designed for an era where the unknown contributor is not a person with a GitHub username but an agent with a public key.
Together: sandboxes isolate the act of writing code. Reputation measures the trust of the writer. Orchestration handles the flow. The PR sat in the middle of all three for twenty years. The new architecture removes it.
What This Means for Devs Tomorrow
Let's be specific. This is not a 2027 prediction. The shift is visible in this week's tools.
Open-source maintainers will triage prompts, not PRs. Your job stops being "did this diff look right" and becomes "did this prompt, with this sandbox, from this agent, produce what I asked for." Review becomes policy enforcement. You write the rules the agent has to follow, and you sample its outputs. The 200-line diff audit is replaced by the 2-line policy plus the run log.
Inside companies, code review becomes a CI artifact. Vercel Agent code reviews already run follow your code guidelines [12]. Datadog shipped an internal Codex system for system-level code review in January [13]. The review is the policy-as-code, applied by an agent, recorded as a build artifact. Human approval becomes an exception, not a default.
Git itself isn't dead. Forking isn't dead. Branches aren't dead. The PR — the social object — is dying. The 21-year-old workflow that asked a human to bless a diff is being replaced by a workflow that asks a sandbox to contain an intent. Git will keep tracking state; the merge will keep being a commit. What's gone is the waiting-for-a-human step, because that step was there to solve a problem agents don't have.
The Sharp Question
Latent Space raised the obvious question in their headline: "how long until Git itself is dead?" [2]. The honest answer is more interesting than the question.
Git is not dying. Git is forking. The commit is durable because state needs to be auditable. The branch is durable because experiments need isolation. The fork is durable because contributors need independence.
What is dying is the merge ceremony. The PR-shaped ritual of "describe-diff-discuss-approve" is being compressed into "intent-sandbox-run-merge." The diff is disappearing from the API surface. The intent is becoming the unit of contribution.
In 2005, Linus invented the Pull Request to let humans collaborate across distance. In 2026, GitHub shipped the kill switch for that workflow. Two years from now, the human reviewer will be one option among many — available for the projects that need it, irrelevant for the ones that don't.
What this means for you: if you're an open-source maintainer, write your intent better. Your README, your contributing guide, your prompt — that's the new merge gate. If you're an engineer, stop optimizing for diff clarity. Optimize for intent portability. The skill that mattered in 2018 was reading code. The skill that matters in 2028 will be specifying what you want clearly enough that an agent can deliver it without asking.
The PR didn't die because AI writes better code. It died because the bottleneck moved. And three years after the bottleneck moves, the workflow around it always does too.
