DEV Community

Honey Kiran
Honey Kiran

Posted on Originally published at honeykiran.substack.com on

Stop the Line. Ten Agents Passed Every Test. It Still Broke.

#git #ai #devops #programming

Picture this: ten AI agents. Ten branches (each a separate line of changes). Ten green checkmarks at 3AM.

Merge them, and main — the one shared branch that has to keep working — falls over.

Nobody wrote a bug. The combination was the bug.

Getting agents to write code is solved. Getting their work safely into main is the part nobody plans.

Ten branches, ten green checks - then main falls over.

Claude Code, Codex and others run agents in parallel, each on its own branch. Merging didn't get the memo. Spawning them is a fun afternoon. Landing their work is the rest of your week.

Three agents share one working directory and overwrite each other in turns.

Three agents share one working directory (the folder of files you edit). B builds on A's half-finished edit; C commits both. They're not collaborating. They're overwriting each other in turns.

One desk per agent

A worktree is a separate desk (folder) on the same repo, with its own files and branch. claude --worktree builds one; subagents get theirs via isolation: worktree.

git worktree add -b agent/auth    ../wt-auth    main
git worktree add -b agent/billing ../wt-billing main
claude --worktree auth-fix
git worktree list
Enter fullscreen mode Exit fullscreen mode

Gotcha: a fresh desk has no .env (your local secrets file) and no installed packages. List files in .worktreeinclude, and install packages before agent #2 starts.

Green alone, broken together: a rename and a stale call pass alone, break merged.

Illustrative: Agent A renames a function. Agent B still calls the old name. Both pass every test. Merged, the build falls over. That's a semantic conflict: two changes that never touch the same line but still break each other. Long-lived branches make this worse; keep them small and same-day. A week-old agent branch is a fork with good intentions.

One door into main

When ten agents land, put a merge queue at the door: a line where each change is tested on top of everything ahead of it, then lands. A failing pull request (PR, a proposed change awaiting review and checks) drops to the back. CI (the automatic build-and-test robot) must also run on merge_group, the event for queue entries. Forget merge_group and the queue sits there, polite and frozen. Limit: it needs an org-owned public repo or Enterprise Cloud, and it orders and re-tests but does not review.

on:
  pull_request:
  merge_group:   # without this line, the queue waits forever
Enter fullscreen mode Exit fullscreen mode

The review bottleneck in numbers: code and PRs up about 30% and 23%, shipped work flat, merge time up 49%.

Chen and Stratton's "Artificial Intelligence in the Firm" studied 718 firms and more than 725,000 workers. After coding agents arrived, lines of code per worker rose about 30% and pull requests about 23%. Resolved issues and epics, the study's measure of actually-shipped work, did not significantly move. PR open-to-merge time rose 49%. The share sent back for changes nearly doubled. Review comments per PR rose 35%. Ten agents don't make ten times the software. They make ten times the review pile.

Before you spawn agent number six

Before you spawn agent number six: the seven checks.

  1. One worktree, one branch, one agent. No shared checkouts.
  2. Branch from fresh main, never from another agent's branch.
  3. One small change per agent, landed the same day.
  4. Copy .env via .worktreeinclude and install packages before starting.
  5. CI on pull_request AND merge_group, or the queue freezes.
  6. Require the merge queue on main; failures rejoin last.
  7. A named human owns the door and caps the agents.

Parallel is a property of your desks. Serial is a property of your door. Plan the door first, then hire the writers.

How many agents are you running, and who holds the door into main?

Examples are illustrative — validate in your own environment before running in production.

Disclaimer

  • This post describes my personal experience with my own systems and accounts, in my own words. It is a first-person account of what I observed and what I do in my own work — not a statement of any company’s intentions, policies, or internal decisions. Where I do not know something, the post says so.
  • I am not affiliated with, endorsed by, or speaking for any company, product, or vendor named in this post. All product and company names are trademarks of their respective owners and are mentioned only to describe the experience accurately.
  • Any error messages, documentation excerpts, or figures quoted here are reproduced from my own records or from the public sources linked in the post, believed accurate at the time of writing. Product behavior changes over time; verify against current official documentation before relying on any detail.
  • Nothing in this post is professional, financial, legal, or security advice for your specific situation. Examples are illustrative — validate in your own environment before running anything in production.
  • Corrections are welcome. If any company named here publishes an official statement, or if any detail is wrong, I will update this post and note the correction. The goal is an accurate public record, not a verdict.

© 2026 Honey Kiran. All rights reserved.

Honey Kiran · DevOps & Platform Engineering

I write about SRE, Kubernetes, Terraform, and platform engineering — the defaults that bite, the incidents that teach, and the guardrails that hold.

Top comments (0)