# Merge Queues Just Became a Solo-Dev Problem > Source: > Published: 2026-07-30 03:09:08+00:00 [Dev Tools](https://sourcefeed.dev/c/dev-tools)Article # Merge Queues Just Became a Solo-Dev Problem A tiny Show HN tool serializes commits from parallel Claude Code agents — and previews where agent-era git workflow is heading. [Lenn Voss](https://sourcefeed.dev/u/lennart_voss) In 2014, Graydon Hoare described the "not rocket science rule" that governed Rust's development: automatically maintain a repository that always passes all its tests, by testing every change against the current main before it lands. That idea spawned bors, OpenStack's Zuul, GitLab merge trains, and eventually GitHub's built-in merge queue. All of it was infrastructure for one problem: too many humans landing commits at once. Now the same problem has arrived on a single laptop, and it took a fanless MacBook Air to prove it. [claude-code-merge-queue](https://github.com/funador/claude-code-merge-queue), a small TypeScript tool that hit the Hacker News front page this week, is a merge queue for exactly one machine — built by a developer who says they run four to five parallel [Claude Code](https://code.claude.com/docs/en/agents) agents pushing up to 90 commits a day through 8GB of RAM. That single data point is the story. Coordination infrastructure used to scale with headcount. With agents, it scales with ambition, and ambition is cheap. ## What it actually does The mechanics are deliberately boring. Each agent works in a numbered "lane" — a git worktree with its own directory and a dev-server port derived from the directory name. When an agent finishes, it runs `land` , which joins a FIFO queue stored in local temp storage, rebases the lane onto the integration branch, runs your configured `checkCommand` , and pushes — one lane at a time, never two mid-push at once. A separate `build-lock` serializes heavy builds machine-wide, and `sync` fast-forwards your main checkout (re-installing dependencies if the lockfile changed) so the dev server you're actually looking at reflects what just landed. Two design details stand out. Locks are crash-safe by PID liveness rather than timeouts — kill a process mid-claim and the next one notices the dead PID and reclaims the lock, so there's nothing to tune and nothing to go stale. And when a rebase conflicts, the tool aborts cleanly and hands the lane back to the agent to retry, rather than leaving a half-merged worktree for a language model to improvise around. Zero runtime dependencies, MIT-licensed, `npm install --save-dev` and an `init` command that wires up config, hooks, and Claude instructions. None of this is novel as computer science. It's a batch scheduler with file locks. What's novel is where it's running and who it's for. ## The gap GitHub left open GitHub's [merge queue](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue) went GA in 2023, but for private repositories it remains an Enterprise Cloud feature — it's not available on the Team plan, despite years of requests. And every queued merge burns Actions minutes. That pricing made sense when merge queues were a hundred-engineer problem. It makes no sense for a solo developer whose "team" is five Claude instances hammering a private repo, which is precisely the population this tool serves: high commit velocity, zero budget, one machine. There's precedent for solving this the expensive way. Anthropic's own [experiment building a C compiler](https://www.anthropic.com/engineering/building-c-compiler) with 16 parallel Claude agents skipped the queue entirely — agents claimed tasks via lock files, then pulled, merged, and pushed against a shared repo, resolving frequent merge conflicts themselves. It worked, and produced a 100,000-line compiler for just under $20,000. Letting agents burn tokens on conflict resolution is a legitimate strategy when someone else is paying. The local queue is the frugal inversion: spend a rebase instead of an inference call, and never let two builds compete for your last gigabyte of RAM. ## The part that should make you pause The README is refreshingly honest about its sharpest edge: there are no human reviews in this loop. The only gate between an agent's diff and your integration branch is `checkCommand` . That's the not-rocket-science rule reduced to its purest form — and its biggest assumption. If your test suite is thin, flaky, or (worse) largely agent-written, you've built a machine that launders unreviewed code into main at 90 commits a day. The tool explicitly guards against mistakes and races, not adversarial or confidently-wrong agents. The mitigation is the two-stage branch model: agents land freely on an integration branch, and a human runs `promote` to ship to production. That's the right shape, but it relocates review rather than eliminating it — you're now reviewing a day of merged agent work in bulk instead of five PRs individually. Whether that's better depends entirely on how good your `checkCommand` is, and that's where adopters should spend their effort before installing anything. Serialization is also a ceiling. One-at-a-time landing is exactly what you want at five agents on 8GB; at fifty agents it's a queue that never drains. GitHub's queue solves this with speculative batching — testing candidate merges in parallel against predicted future states of main. Nothing local and single-machine will replicate that, and the author doesn't pretend otherwise. ## Adopt the pattern, hold the tool loosely There are two honest risks here. First, git itself may be the wrong substrate — the top HN suggestion was [Jujutsu](https://github.com/jj-vcs/jj), whose workspaces handle parallel checkouts with far less ceremony than worktrees, and the author conceded the point. Second, Anthropic is converging on this territory from above: Claude Code now moves background sessions into worktrees automatically, and its `/batch` skill fans one change out to as many as 30 worktree-isolated subagents that each open a PR. First-party tooling that creates the parallelism will eventually own the landing step too. A 40-star weekend project sitting in between is a candidate for being absorbed. But the pattern is correct, and it's ahead of most teams' practice. If you're running more than two agents against one repo today, you already have a merge queue problem — you're just resolving it with retries, corrupted dev servers, and OOM kills. Whether you fix that with this package, a jj workflow, or 80 lines of flock-based shell script matters much less than internalizing the shift: integration discipline is no longer something you grow into at 20 engineers. It arrives the day you open your third terminal tab and type `claude` . ## Sources & further reading - [claude-code-merge-queue: The local merge queue for parallel Claude Code agents](https://github.com/funador/claude-code-merge-queue)— github.com - [Show HN: A local merge queue for parallel Claude Code agents](https://news.ycombinator.com/item?id=49104747)— news.ycombinator.com - [Building a C compiler with a team of parallel Claudes](https://www.anthropic.com/engineering/building-c-compiler)— anthropic.com - [Managing a merge queue](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue)— docs.github.com - [Run agents in parallel](https://code.claude.com/docs/en/agents)— code.claude.com - [The Not Rocket Science Rule Of Software Engineering](https://graydon2.dreamwidth.org/1597.html)— graydon2.dreamwidth.org [Lenn Voss](https://sourcefeed.dev/u/lennart_voss)· Cloud & Infrastructure Writer Lenn writes about cloud platforms, Kubernetes internals, and the infrastructure decisions that quietly make or break engineering organizations. Based in Berlin's vibrant tech scene, they have a talent for turning dense platform-engineering topics into prose that people actually finish reading. ## Discussion 0 No comments yet Be the first to weigh in.