Merge Queues Were Built for Humans. AI Agents Need More.

Mitchell Hashimoto thinks merge queues stop holding up once AI agents start writing the code. On a recent Pragmatic Engineer episode he said it plainly: merge queues work for humans at a certain scale, but push that scale by 100x or 1,000x and getting “any semblance of cohesiveness onto the main branch quickly” becomes untenable. He is advising a stealth company living this exact problem right now, where agents generate so much more churn than humans that the work of landing it has become the bottleneck.

I build a merge queue for a living. He’s right.

What he is describing is the failure mode of one specific design: the queue built for human cadence. That design does bend under agent churn. The interesting question is what the next one looks like.

The queue he’s describing

A human-scale merge queue is a single lane. Pull requests line up, each one gets rebased on the latest main, CI runs against that rebased state, and only a green result lands. This is the whole point of a queue: it kills merge skew, where two changes each pass on their own and break once they sit on the same main. Tested first, promoted second.

At human cadence the lane is short. Reviews take time, people sleep, the queue drains faster than it fills. Crank the input rate up and the lane gets deep. Every change waits behind a serial line of CI runs, and you fall into the git failure Hashimoto names directly: “every time you pull there’s another chain, every time you push it’s rejected.” You rebase, someone already landed ahead of you, you rebase again. The queue is working exactly as designed and still losing ground.

What agents change

Agents do not take coffee breaks. They open pull requests continuously, in parallel, across every corner of the repository at once. Hashimoto calls 10x the conservative case and 100x to 1,000x the one you reach if you believe the hype. Either way the constraint moves. It is no longer review quality, and as he puts it, “it’s not an AI review problem, it’s really just a release problem.” The number that matters becomes throughput: how many correct changes can you land on a coherent main per hour, without ever breaking it.

A single serial lane cannot answer that question. So you change the machine.

A queue built for throughput

A queue built for agent churn behaves differently from the human-scale one in a few concrete ways, all of which ship in Mergify today.

It tests speculatively. Instead of validating one pull request, waiting, then starting the next, the queue runs several at once in parallel lanes and predicts the merges that will succeed. Green results land in order without paying for the wait.

It batches. Ten passing changes do not need ten CI runs. The queue combines them into one validation, and when the batch is green the whole group lands. If something fails, it bisects to find the culprit instead of punishing the rest.

It stops treating the repository as one lane. With scope-aware queues, batches that touch independent parts of a monorepo test at the same time, as a directed graph rather than a line. Churn in the billing service does not sit behind churn in the mobile client. This is the piece that actually answers the 100x problem, because independent work was never truly serial. We were just queuing it as if it were.

flowchart TB
  subgraph one[One lane, built for humans]
    direction LR
    p1[PR] --> p2[PR] --> p3[PR] --> p4[PR] --> m1[main]
  end
  subgraph many[Scoped lanes, built for agents]
    direction LR
    sa[scope A batch] --> M[main]
    sb[scope B batch] --> M
    sc[scope C batch] --> M
  end

Add two-step CI on top, cheap checks on every push and the expensive suite only inside the queue, and queue depth stops being the metric you watch. Once independent work runs concurrently and batches collapse the cost, a deep queue is just a busy one.

The rebase loop, and the SHA problem under it

The constant rebase Hashimoto describes is the queue’s job to absorb, not the developer’s. Nobody, human or agent, should be racing to win the pull-then-push lottery. The queue holds the order, rebases internally, and fast-forwards main so the exact SHA it tested is the SHA that lands. The thing you validated is the thing your users get.

Underneath that sits a harder problem we are still working through. Git identifies work by SHA, but the unit that actually matters is the change. A rebase produces a new SHA and the same change. Two pull requests batched A+B or B+A are different SHAs and the same set of changes. We already treat the change as the real identity inside our Stacks tooling, and the direction we are heading is to make it first class across the platform, so a rebase never re-runs a review or throws away a test result that still applies. That work is in front of us. Agent churn is what makes it urgent.

Getting agents the right data

The other half of Hashimoto’s release problem is access: humans, and now agents, “getting access to the right set of data in the repository.” An agent that hits a red check needs to know whether the failure is a real regression or a flaky test before it spends a cycle retrying or, worse, rewrites working code to chase a ghost.

Test Insights classifies every test as healthy, flaky, or broken from its rerun history, and exposes that over a CLI an agent can query straight from the terminal. CI Insights does the same at the job and runner level. The agent asks “is this failure mine?”, gets a grounded answer, and decides what to do. That is the unglamorous release plumbing he is pointing at, and it matters more, not less, when the thing reading the answer is another program.

Where this goes

The sharpest thing Hashimoto said was not about queues at all. He pointed out that this is the first time in fifteen years anyone can ask whether git survives the next five without the room laughing. The future he sketches has agents each working a scope on its own branch, with the pull request fading into a transient artifact and the real unit of code sitting closer to its structure than to a file.

That happens to be the future we are building toward. Whatever the branch model becomes, something still has to keep main coherent while the authors never sleep, and keep it coherent fast enough that the coherence is worth having. The human-scale queue bends there. A queue that reasons about changes rather than commits and runs scopes in parallel is the part of that stack that turns agent-speed output into code you can actually ship.

Hashimoto sees the problem clearly. We have been building the answer to it, and we still are.