# Steve Yegge Deleted the Wrong Thing

> Source: <https://julien.danjou.info/blog/steve-yegge-deleted-the-wrong-thing/>
> Published: 2026-08-18 00:00:00+00:00

# Steve Yegge Deleted the Wrong Thing

Yegge's agents write 250 commits a day, so he stopped gating main. The math is right. But he didn't delete the merge queue, he deleted the one thing that makes a fix cheap.

Steve Yegge deleted the wrong thing. He’s right that merging one pull request at a time is mathematically dead at agent scale, and I’ll grant that without hedging, because seven weeks ago I wrote down this exact scenario as the one way my bet loses. I sell merge queues for a living. Discount me accordingly, then keep reading, because the part he got wrong is more interesting than the part he got right.

In [The Continuous Thunderdome](https://yegge.ai/essays/the-shape-of-things-to-come/), Yegge describes running about forty agents around the clock on Wyvern, the MMO he’s been writing for twenty-five years. They produce roughly 175 real commits a day, some days 250. His build takes about half an hour. He started with batches of ten and bisection on failure, and watched his merge queue grow past a hundred, then to a hundred and sixty-six.

Then he stopped:

Just slam all the commits onto main, and then just friggin’ deal with it. No bisections, no sequencing, no blame, none of that old crap.

He calls it the Land Rush. Let the queue build to a hundred, drop 120 to 150 commits onto main at once, and when main goes red, point agents at the wreckage. “Swarm diagnosis (*not* bisection).” He found out afterwards that AAA studios have done a version of this for years and call it Game DevOps, where main generally stays red and nobody minds.

## The math is not in dispute

Here’s the line worth keeping:

Once your commit rate outruns your build slots, one commit per green build becomes mathematically impossible.

That’s true, and it’s the whole diagnosis. If you can run two builds an hour and you receive ten changes an hour, no amount of clever ordering saves you. The serial queue was sized for humans opening four pull requests a day. [I said as much in June](/blog/merge-queues-built-for-humans): the human-scale queue strains under agent churn, grant it and move on.

So we agree on the problem. We disagree about what he actually removed.

## He didn’t delete the queue, he deleted the intent

Look at what a batch of 150 commits is before it lands, and what it becomes after.

Before, it’s 150 changes, each with an agent that wrote it, each with a goal, a plan, and a reason. Every failure in there, if it fails, belongs to something.

After, it’s one merged artifact. Main is red. The mapping from “this test is failing” back to “this agent was trying to do this” is gone, and it’s gone permanently, because by then those agents have finished and moved on. David Crawshaw put his finger on why that’s fatal in [a post that reaches the opposite conclusion from the same premises](https://blog.exe.dev/replace-your-ci): by the time CI reports a failure, “the agent context window is dead and gone.”

So the swarm arrives at a red main with no author, no intent, and no plan, and has to reconstruct from scratch what 150 agents were collectively attempting. That is the most expensive debugging context you can possibly build. Yegge is right that binary search is too slow. He’s wrong that the fix is to stop attributing, because attribution is the thing that makes the repair cheap.

And look at what “swarm diagnosis, not bisection” actually is. It’s a parallel search for which change broke the build. That’s still attribution. He kept the expensive half of bisection and ran it on the worst possible substrate, then threw away the half that was free.

Bisection was never really about finding the guilty commit. It was about finding the guilty *intent*, and handing the problem back to whoever had it.

## Fix one thing, in one context

The alternative isn’t the queue he abandoned. It’s the queue nobody has built yet.

You still gate before merging. Main stays green, because a green main is what lets everything downstream stop thinking about it. But the queue stops behaving like a turnstile that admits or rejects, and starts behaving like the place where you sort things out as fast as possible.

A batch goes red. Instead of evicting the offender and making it start again from the back of the line, the queue works out what’s actually broken and hands one diff back to the one agent that owns it, with the failure attached. Not “your pull request was dequeued, resubmit.” Closer to “this assertion fails because of this thing you changed, here it is, fix it.”

That’s a different job than any merge queue does today, and I’m not going to pretend we ship it. But it’s cleaner in the way that matters: you fix one piece of code, in one context, with the intent still attached, instead of untangling a hundred and fifty changes that have already been stirred together.

Yegge’s own vision needs this more than mine does. What he’s building toward, across Gas Town and these essays, isn’t a framework you download. It’s a civilization of colleagues running on datacenter silicon. Civilizations need infrastructure, and the CI and the merge queue that one would run on don’t exist yet. That’s the interesting problem. Not whether Git survives.

## Where I’d lose

Two places, and both are real.

The first is coherence. Sometimes a batch fails and no single change owns it: three agents each wrote something defensible and together they contradict. Attribution doesn’t help, because there’s nothing to attribute to. Green is not coherent. A merge queue keeps main buildable, it does not keep main good, and that half is [a review problem](/blog/the-code-review-bottleneck-is-you) that nobody has answered.

The second is that a red main costs Yegge nothing. He’s the only human on that codebase, and he says so, in the same essay where he enters Sam Altman’s solo unicorn contest. When you’re alone, “main generally stays red” is a workflow. The moment a second team pulls from your main, the same sentence is an outage, and the cost stops landing on the person who chose it. That isn’t a refutation of the Land Rush for him. It’s the reason it doesn’t travel.

## The real constraint was never the queue

Strip it back and the thing that forced his hand is a thirty-minute build and a finite number of build slots. That’s it. He didn’t have an ordering problem, he had a throughput budget, and he balanced it by setting the quality bar to zero.

Which is a legitimate trade. It’s just a trade, and it deserves to be stated as one.

Main stays green. Changes land fast. CI spend stays under a number. Most days you get all three, and when they collide, something has to give. Nobody running a merge queue today gets to say which one. What they get is a batch size, which is a mechanism, and then they get to work backwards from it to an outcome they were never invited to state. [Your CI pipeline wasn’t built for this](/blog/your-ci-pipeline-wasnt-built-for-this), and neither was the settings screen bolted to the front of it.

Most of the work ahead is making CI cheap enough that none of this requires a sacrifice. Yegge’s real innovation was noticing that when you can’t afford the gate, you can simply stop paying for it.

I’d rather make it cheap enough to keep.

## Related posts

### [ The Hidden Corruption Tax of AI Delegation ](/blog/the-hidden-corruption-tax-of-ai-delegation)

Frontier LLMs corrupt 25% of what you delegate. The fix isn't going back to writing by hand. It's the same linters and CI we built for humans, finally pointed at the new worker.

[Read more →](/blog/the-hidden-corruption-tax-of-ai-delegation)

### [ Your CI Pipeline Wasn't Built for This ](/blog/your-ci-pipeline-wasnt-built-for-this)

AI writes code 10x faster than humans. CI still runs at the same speed, fails for the same flaky reasons, and costs more every month. Something has to give.

[Read more →](/blog/your-ci-pipeline-wasnt-built-for-this)
