Optimistic Merge vs Pessimistic Merge Queue Modes

Two pull requests can each pass every check in isolation and still break main the moment both land. That is the semantic conflict problem, and it is the reason merge queues exist at all. A developer renames a function in one branch, another developer writes a new call to the old name in a separate branch, and CI on each branch comes back green because neither branch ever saw the other's changes. The root cause sits in how CI actually tests a pull request: it runs against a temporary merge commit built from the PR's head and the base branch's tip at the time of the last push. That merge commit only gets regenerated when the PR branch itself is updated; it does not regenerate when main moves forward. A PR can sail through review, sit untouched for a day while three other PRs land on main, and get approved against a test environment that no longer resembles what main will look like the moment it merges. A merge queue's job is to close that gap by testing every PR against the future state of main. But enforcing that single invariant, that main is always green, costs something: serialization. Every team configuring a merge queue is really deciding how much of that cost to pay up front, in computation, versus how much to risk paying later, in broken builds and cascading restarts. That decision is what optimistic and pessimistic mode actually represent.

How optimistic and pessimistic modes work mechanically

Optimistic and pessimistic mode are two distinct parallelization strategies for how a queue tests multiple PRs at once, mechanical enough to trace in a two-PR example. Both modes rely on a technique called vertical parallelization: the queue stacks PRs on top of each other, with each layer representing what main would look like after everything beneath it has merged. Where the modes diverge is in what each layer assumes about the layers below it.

Under optimistic vertical parallelization, the CI system assumes every pending change in the pipeline will succeed. If PR 1 and PR 2 are both queued, PR 2 gets tested against a speculative state that already includes PR 1's changes, even though PR 1's own CI run hasn't finished yet. When both succeed independently, they merge fast, in any order, with no PR waiting around for another to clear first. The trouble appears when the assumption turns out to be wrong. Say PR 1 renames an API, and PR 2's test suite still calls that API by its old name. Each PR looks green on its own speculative stack. Together, they break main the moment both land, because the queue never tested the combination where PR 1's rename and PR 2's old call coexist in the same world.

Pessimistic vertical parallelization takes the opposite starting assumption. Instead of betting that everything ahead in the queue will pass, the system precomputes fallback integration states that account for the possibility that any upstream PR fails. Each PR gets tested not just against the "everything passes" future, but against the alternate futures that would exist if one or more PRs ahead of it got ejected. That means more CI jobs per PR, and the combination space grows as more PRs queue up concurrently. The payoff is that no speculative work goes to waste when a failure actually happens, because the queue already computed what the correct next state looks like.

Modern queue implementations often run this as speculative batches rather than one PR at a time: PRs A, B, and C get tested together as a group, and if the group passes, all three merge in one motion. If the group fails, the queue bisects to find which PR caused the failure and lets the innocent ones through. That bisection step is where the two modes genuinely part ways. An optimistic queue has to go figure out, after the fact, what the correct state looks like once the culprit is removed, then rebuild and retest from there. A pessimistic queue already has that state sitting precomputed, ready to promote.

The cascade failure problem that makes mode choice consequential

A single failure in an optimistic queue does not cost a single CI run. It invalidates every speculative state built on top of it. Every PR behind the failed entry was tested against a future that assumed the failed PR's changes were already part of main. The moment that PR gets ejected, each downstream PR needs a new speculative merge commit, built against a different base representing a different state of the world, and every one of those CI runs has to restart from scratch. If five PRs are queued behind the failure, the real cost of that single failure is five CI runs, not one. The cost scales with queue depth: the deeper the queue gets during a busy period, the more expensive a single bad PR becomes.

Flaky tests make this dynamic considerably worse, because the trigger for a cascade is the flake rate rather than code quality. A test that fails intermittently for reasons unrelated to the PR's actual changes still ejects that PR from the queue and still forces every PR behind it to restart. A team can write disciplined, well-reviewed code and still suffer constant cascades if its test suite has a meaningful flake rate, because the queue has no way to distinguish a flake from a real regression at the moment it bisects.

Pessimistic mode's answer to this is structural rather than procedural. Because fallback states are precomputed ahead of time, the queue already knows what the correct next state is for every PR behind a failure, the moment that failure occurs. Promotion to that fallback state replaces the restart. That is the mechanism by which pessimistic mode reduces latency on failure recovery, even though it costs more compute during ordinary operation when nothing fails.

Mode selection can't be made independently of a team's flake rate. A team running a clean, stable test suite is paying for a great deal of pessimistic insurance it rarely needs to collect on. A team whose failures, flaky or genuine, happen often is collecting on that insurance constantly, and the resource overhead starts looking cheap by comparison. Vex's agentic merge queue is built around that exact asymmetry: it lets teams configure mode based on their own observed flake rate and conflict frequency, rather than picking a mode once and assuming the failure pattern that justified it will stay fixed.

How agentic development changes failure frequency and severity

AI coding agents do more than add volume to the queue. They change the arrival rate, the conflict rate, and the retry behavior of everything moving through it, and each of those changes makes optimistic mode's failure modes worse at exactly the moment teams are least prepared for it. When one developer runs several agents in parallel across separate worktrees, PR arrival rate grows faster than any throughput gain a team can buy by adding more CI runners. Teams with high AI adoption are merging nearly twice as many pull requests as they used to, and delivery metrics barely move, because every one of those PRs still has to squeeze through a queue sized for the pace of human typing. Queueing theory explains why this gets dangerous quickly rather than gradually: as arrival rate approaches a system's capacity, wait times don't climb in a straight line, they explode. A queue that added a few minutes of latency last quarter can add hours this quarter with no change at all to how fast CI itself runs.

Agentic PRs also conflict with each other more often than PRs written by people, which raises the rate of genuine, non-flaky cascade triggers running through the system at the same time arrival rate is climbing. And agents behave differently than humans do when something fails. An agent instructed to get a PR merged will re-queue the same change repeatedly after a failure, burning a full CI run on each attempt and re-triggering the cascade for every PR sitting behind it. A retry pattern that was mildly wasteful at human frequency, where a developer might retry once or twice before investigating, becomes something closer to a denial-of-service condition at agent frequency, where the retry is automatic and tireless.

Review capacity is buckling under the same pressure. Faros AI's "Acceleration Whiplash" report, built from telemetry across tens of thousands of developers on thousands of teams, found that code churn has risen dramatically and that pull requests merging with no review at all have risen substantially. That shift didn't come from teams deciding to loosen review policy. It came from reviewers losing the ability to keep pace with the sheer volume of agent-generated code moving through the pipeline. Put the four effects together, higher arrival rate, higher conflict rate, automatic retries, and reviewers falling behind, and the result is a queue that used to hiccup once a month thrashing continuously. Teams running merge queues at agent scale need to treat mode selection as a deliberate, ongoing decision rather than a default left over from when PR volume was lower and conflicts were rarer.

What optimistic mode trades away

Optimistic mode's throughput advantage is not a marketing claim, it is the direct consequence of its mechanics. When PRs 1 and 2 build in parallel under optimistic vertical parallelization and both succeed independently, neither one waits around for the other to finish before merging. No time gets spent testing against a shared future state in sequence. That parallelism is free throughput for the overwhelming majority of PRs, which in practice don't touch the same code. It's the reason optimistic mode is the default behavior in most forge UIs: most of the time, most PRs genuinely don't interact, so the speculative assumption that everything will pass turns out to be correct far more often than it's wrong.

The cost side of the ledger matters just as much. Pessimistic mode's precomputed fallback states multiply with every additional concurrent PR, since the queue has to account for every permutation of which upstream PRs might get ejected. With three PRs running concurrently, that combination space expands quickly, and for a team whose CI suite already takes a long time to run, the resource spend on speculative states that mostly never get used can make pessimistic mode prohibitively expensive before it ever proves its value.

SylphxAI's merge queue implementation, shipped in September 2026 as PR #284 and merged into the puzzled project on September 29, 2026, is a concrete example of how teams operationalize that trade-off rather than just accepting it wholesale. The change moved the project onto a shared optimistic-merge template, configured with merge = "optimistic" in sylphx.toml, but paired that speed with a two-layer check structure rather than a single all-or-nothing gate. A fast pre-merge gate requires seven named checks before anything lands: Build, Unit Tests, Rust API, Lint & Type Check, Security Scan, Migration Integrity, and Identifiers. A ci-ok aggregate, built on a needs-pass condition, was added for the day the ruleset gets reduced to a single required check. The genuinely resource-heavy work, accessibility audits and Lighthouse performance checks, got moved out of the pre-merge path entirely and into post-merge verification, where it runs against what already landed rather than against every speculative stack in the queue. The structure effectively converts pessimistic-style pre-merge coverage into optimistic post-merge validation for the checks expensive enough to matter, without giving up the quality signal those checks exist to provide.

There's a cultural argument for optimistic mode as well, articulated by an open-source project maintainer before merge queues in their current form existed. Standard pessimistic practice, wait for CI, wait for review, test on a branch, gather feedback, fix, repeat, treats every incoming patch as toxic until it's proven otherwise. In open-source contexts where contributors are volunteering their time and patience is a genuinely finite resource, that assumption carries a real collaboration cost, independent of whatever it buys in correctness.

Optimistic mode earns its keep when conflict rate is demonstrably low, when CI is slow enough that precomputing fallback states would cost more compute than the occasional restart, and when a team can tolerate a red main branch after merge in exchange for fast rollback. Those conditions describe a large share of engineering teams operating at ordinary, pre-agentic PR volume.

What pessimistic mode buys

Pessimistic mode's extra compute is not waste, it is insurance paid up front against a cascade that would otherwise cost far more later. When a PR fails under pessimistic mode, the queue promotes the fallback state it already precomputed for everything behind that failure. There's no restart, no cascade, and no wasted work charged to the innocent PRs that happened to be queued next. Compare that to optimistic mode, where the same single failure forces every downstream PR to rebase and restart its CI run from zero, and where queue depth alone determines how expensive that one failure becomes. As conflict rate and queue depth both climb, which is what agentic workflows produce, the accumulated cost of cascades under optimistic mode starts outpacing the precomputation cost pessimistic mode demands, and the breakeven point between the two arrives earlier than most teams expect.

Uber's SubmitQueue stands as the fullest implementation of what pessimistic mode looks like when pushed to its limit. It addresses cascading failures through pessimistic vertical parallelization combined with dynamic horizontal parallelization, integrated deeply with Uber's own build systems. The system performs conflict analysis directly on build targets to figure out which PRs can be safely tested independently of each other, and it uses machine learning to speculate on which pruned paths through the merge pipeline are most likely to succeed, exploiting the fact that merging PRs often commutes and using runtime prediction to schedule work efficiently. SubmitQueue mitigates cascade failures effectively, but it depends on rigid assumptions about build structure and on specialized infrastructure that few organizations outside Uber's scale have reason to build. It's a ceiling worth knowing about, a limit most teams should not expect to replicate as a template.

More general-purpose queue systems, including GitHub's merge queue, GitLab's merge train, and Zuul, support optimistic vertical parallelization paired with static horizontal parallelization. That combination runs into real throughput trouble in high-demand environments with high failure rates, and closing that exact gap is what purpose-built pessimistic implementations are for.

Pessimistic mode is worth its cost when conflict rate is demonstrably elevated, when queue depth stays persistently high rather than spiking occasionally, when CI is fast enough that precomputed fallback states don't themselves become the bottleneck, and when a red main branch simply isn't an acceptable outcome regardless of how quickly it gets fixed. In agent-driven pipelines, where flake rates can shift unpredictably as agents drift in skill or change behavior between tasks, a fixed mode chosen once and left alone tends to either over-invest in pessimistic safeguards nobody needs yet or leave a team exposed to cascades it didn't see coming. Letting mode selection track observed agent behavior, rather than a static configuration set at the start of a project, is the practical answer to a problem that data from AgenticFlict suggests most teams aren't yet planning for: agentic workflows cross a conflict-rate threshold that the queues built for human-paced development were never sized to absorb.