The Pull Request Is Dying. What Comes Next?

Software engineering built its identity around collaboration rituals. Fork, branch, commit, push, review, merge — a choreography so familiar we forgot it was invented. When GitHub popularized pull requests in 2008, they solved a human coordination problem: how do strangers safely contribute code to shared repositories without breaking everything?

That problem assumed humans wrote the code.

GitHub now lets repository owners disable pull requests entirely. This isn't a UI tweak — it's an admission that the default workflow for open-source collaboration may no longer match how software actually gets built. The trigger isn't internal politics. It's that generative AI has inverted the economics of code production.

Consider what happens when an AI agent can generate, test, and refine code faster than a human can review it. The bottleneck shifts from "can we write this?" to "should we accept this?" and ultimately "who is responsible for this?" Pull requests were designed for a world where code volume was constrained by human typing speed. In a world of infinite code, the review surface area explodes.

Some teams are already operating without them. The pattern emerging isn't "AI-assisted pull requests" — it's a fundamentally different harness. Pete Steinberger and others have been vocal about wanting "prompt requests" instead: the contributor submits a natural language description of the intended change, and the maintainer either accepts the generated result or iterates on the prompt. No diff to review. No line-by-line scrutiny. Just intent and outcome.

This sounds reckless until you consider what actually breaks in production. Most bugs aren't subtle algorithmic errors caught by careful line review. They're integration failures, configuration mismatches, untested edge cases in the interaction between components. The kind of problems that emerge from system complexity, not individual function correctness. Line-level code review was always a partial solution. It made us feel rigorous without guaranteeing rigor.

The alternative taking shape looks more like reputation-based systems combined with automated verification. Mitchell Hashimoto's approach and tools like Amp Code track contributor trust scores — not based on whether their code was reviewed, but on whether their past contributions passed validation suites and stayed stable in production. The verification layer shifts from human judgment to executable proof. If the tests pass and the types check and the deployment succeeds, the code is definitionally correct enough.

This mirrors what we're seeing in agent infrastructure more broadly. The frontier labs aren't debating whether to use pull requests for their internal agent systems. They're building durable execution environments where agents generate code, execute it in sandboxed workspaces, validate it against eval suites, and either promote it to production or self-correct. The "review" happens through verification, not human eyes.

The implications for engineering organizations are significant. If you maintain a library or framework, you may soon face a choice: accept that most contributions will come from AI agents acting on behalf of users, or watch your project become irrelevant. The humans using your software won't be submitting patches. They'll be submitting prompts, and expecting your project to either interpret those prompts correctly or expose the right hooks for their agents to work with.

This also changes what it means to be a maintainer. The skill shifts from code review — reading diffs, understanding intent, catching bugs — to harness design. Defining the right verification pipelines, the right prompt interfaces, the right constraints that keep agent-generated code within acceptable bounds. The maintainer becomes a systems architect for automated contribution flows.

There's a risk here that we lose something important. Pull requests weren't just about catching bugs. They were a social ritual that distributed knowledge through a team, that trained junior engineers by exposing them to senior feedback, that built shared ownership of code quality. If we replace that with automated verification and prompt engineering, we need to be intentional about preserving the human elements that matter.

But we shouldn't romanticize the old system either. Code review was often performative — rubber-stamp approvals, nitpicking style while missing architecture problems, weeks of latency that killed momentum. The new workflows emerging from AI-native development may actually restore focus to what matters: does this change work correctly in production, and does it maintain the invariants we care about?

The death of the pull request is really the death of a specific coordination mechanism that made sense for human-scale contribution. What's replacing it isn't chaos — it's a different kind of order, optimized for a world where code is generated faster than it can be read. The teams that figure out how to validate and integrate that code without drowning in review backlog will have a structural advantage.

Git allowing repository owners to disable pull requests is just the surface signal. The deeper shift is that software engineering is becoming less about writing code and more about defining the constraints and verification layers that keep automatically-generated code useful. We're moving from craftsmanship to orchestration — and we don't yet have the vocabulary to describe what good looks like in this new regime.

The pull request had a good run. Twenty-one years is a respectable lifespan for a workflow pattern. But it was designed for human hands on keyboards. The future belongs to systems that can handle the output of autonomous agents — and that means rethinking every assumption about how code moves from idea to production.