Kill the Pull Request

We have too much process around pull requests. Open the branch, push, wait for CI, ping the channel, wait for a stamp, rebase, wait for CI again, merge, wait for CI a third time. That loop made sense when writing code was slow and every change carried a human’s guesswork. It isn’t worth the squeeze anymore.

I’m not the first to say it. Thorsten Ball, who builds the coding agent Amp, has spent most of 2026 making the case. This post collects his argument and the people around it, then adds what I think should replace the PR: rules instead of reviewers, and a reset for the code we already have.

The case

Thorsten’s argument goes like this. Review used to be how we caught bugs, shared knowledge, and integrated code. Agents now do a lot of the checking, can generate a walkthrough or video of any change, and run the tests before they push. So the PR mostly adds waiting: the same tests on a branch, again on merge, and a human stamp in between.

a note on the numbers

Attention isn’t proof. But it shows how many people are having this argument.

The part of his branches post that stuck with me: trunk-based development was always the right idea, it was just tedious. Feature flags, splitting a change into safe pieces, keeping two configurations alive for a day, migrating one call site at a time. That busywork is exactly what agents are good at. They do the tedious part now.

It isn’t just Amp

Others got there too. Some reject PRs outright, and some just think they’ve stopped making sense for routine work.

Review already stopped scaling

Agents don’t prove code correct. But neither does a reviewer skimming a 640-line diff, and that’s what review has become on teams that merge four times the code they did a month ago. The bottleneck moves to review, then CI, then deploys, then GitHub’s rate limit.

Even people building better review tools are moving away from reading diffs.

They still require a human approval on every PR, and I think that’s the step to question next. If the evidence is already recorded and most decisions are already settled, the PR is mostly a container. Thorsten makes the same point with an agent-recorded video of a feature working end to end: how differently do you review once you’ve seen proof?

The best objections

Some of the pushback is right about the goal. Teams need a shared mental model. Some domains need a human to read the money-movement code. Nobody wants half-finished work on main.

Here’s how I’d answer them without a PR:

Rules, not reviewers

A lot of what reviewers write is a rule they’ve written before. “Use the retryable exception here.” “Add a timeout.” “Don’t swallow that error.” Every senior engineer carries a private list like this and applies it by hand, inconsistently, to whatever they happen to notice.

I tried to make that list visible. We use Jira at work, like a lot of the industry, and for a while I turned every review comment into a ticket. It didn’t work. The tickets buried the few comments that mattered under hundreds that didn’t, and they ate the attention I needed for real decisions.

what the tickets taught me

A PR plus a ticket per comment is twice the ceremony.

The better move is to write the rule down for the machine instead of for a person. That happens at three levels:

Rules don’t replace judgment about intent and risk. They clear away the repetitive comments, so the few decisions that need a person are easy to see. And as shadcn found, agents will write slop into the very tools meant to catch it, so every rule needs an owner.

A jubilee for the codebase

New rules raise an awkward question: what about the code written before them? Most codebases have years of contradictions in them, and agents read all of it as context. If half the code does something one way and half another, the agent learns both.

Leviticus 25 has a word for this kind of reset. It prescribes a jubilee every fiftieth year: a horn blast on the Day of Atonement, the release of Israelites in debt servitude, a year of rest for the fields, and land returned to the families it originally belonged to. The idea is that debt and loss don’t get to compound forever.

leviticus 25:10, cast on the liberty bell

Proclaim liberty throughout all the land.

Do that to your codebase. Removing contradictions matters as much as the fixes, because every future agent gets a cleaner context. Just don’t do it as one giant cleanup PR. A jubilee is a season you declare, not a single change:

I’ve also written a draft arguing Git Flow deserves a second look, because its worst part was always the people. Humans are bad at resolving conflicts and at finding the bug in a big pile of commits, and agents are much faster at both. That’s a separate post. Faster merging doesn’t remove the risk of code that hasn’t run together, and the process around each change is the bigger cost.

Kill it

Talk to your teammates about the decisions that matter, and keep a gate only for the code that needs one. Try it on one repo for a week. See what you actually miss.