I lost most of two days this week, and I did it with a plan.
This wasn't a vibe-coding accident. I sat down and wrote a proper sprint plan for a multi-tenant SaaS product. I broke it into tickets in a GitHub Project with clean columns: Todo, In Progress, Ready for QA, Done. Every task had a clear description.
Then I asked Claude to run it like a team. Create the subagents. Each one pulls the next ticket from the board, in order, does the work and moves it to Ready for QA. A QA agent verifies it and marks it Done.
It looked like the perfect setup. It went very wrong.
What actually happened
The instruction was "pull tickets in order." What I got was 18 subagents starting on the story at the same time.
Each one created its own branch. Each one started from the same snapshot of the repo. None of them knew what the other 17 were doing.
A lot of the tickets looked separate on the board but shared code underneath. A brand refresh that moved the login page from a dark navy gradient to a clean, light design. Authentication bug fixes. A rebuild of the navigation shell. Different cards. Same files.
So every time one agent finished a shared piece of work and committed, the next agent's commit put the previous version back. The brand agent shipped the new login page. The auth agent, working from its older copy, overwrote half of it. The nav agent hit a merge conflict and settled it the easy way: keep its own version. That deleted the logo work entirely. Then the brand agent, still running, looked at the login page, decided it was "wrong," and restored the old navy gradient. The exact thing its ticket said to remove.
That pattern repeated across the board. Finish, commit, get reverted by the next agent to land. Tests passed on one branch and failed on another, because they were testing different versions of the same logic. QA was being asked to verify work that kept changing under it.
Meanwhile the board kept moving. Cards slid from In Progress to Ready for QA like everything was fine.
When I finally stopped everything and read the git log, I had a pile of branches with conflicting changes, agents still running and still billing, and a codebase in worse shape than when I started. Then came the part nobody puts in the demo: sitting down and merging it all back together by hand.
What the agents never understood
Two things, mostly.
Merge, don't replace. When an agent found a file that didn't match its picture of the code, it treated the difference as a mistake to fix, not as someone else's finished work to keep. It never asked "who changed this, and why?" It just put its version back.
Leave a footprint. No agent left anything behind for the next one to pick up. No note saying "I changed the login layout, here's why, build on top of this." Every agent showed up with no history and no handoff, so it had no way to know that the thing it was about to undo was already done.
And the sequence I asked for never happened. "Pull tickets in order" turned into everything at once.
The board wasn't the problem. It just wasn't enough.
A GitHub Project tracks status. It tells you which ticket is where. It says nothing about which files each agent is allowed to touch, what the code looks like right now, or who changed what last.
That's the gap the whole thing fell into:
- Tickets were split by feature. Code isn't. Separate cards all landed in the same files. The board had no idea.
- "In order" wasn't enforced. Agents pulling their own tickets is fine. Eighteen of them pulling at once is not a queue.
- One branch per agent, no merge discipline. Every branch was a private copy of the truth, and the last one in won.
- No handoff. Nothing carried context from one agent to the next.
- QA verified a moving target. Checking a branch means nothing if the next merge undoes it.
- "Done" meant the card moved, not that the work was still in main.
I'd built the process for a human team, where people talk in standup and say "hey, I'm in that file." Subagents don't do that unless you make them.
What fixed it
The immediate fix was boring: go serial.
Same board, same columns. But only one ticket moves at a time. One agent pulls it, works from the latest main, does the work and runs the tests. QA verifies it against main. Only when QA passes and the work is merged does the next ticket open.
On paper it's slower. In practice it was much faster, because nothing got undone.
How to manage subagents so this doesn't happen
Going serial stopped the bleeding. Beyond that, these are the rules I think every multi-agent setup needs:
- Enforce the queue. If tickets should go in order, something has to lock the next ticket until the current one is merged. An instruction alone isn't enough.
- Plan by files, not just features. Map which files each ticket touches. If two tickets share files, they never run at the same time.
- One writer per area. Only one agent writes to a given file, module or table at a time. Others can read.
- Start from main and pull fresh before every commit. Never from a stale snapshot.
- Merge, never overwrite. An agent that finds unexpected changes stops and asks, or merges them. It doesn't restore its own version.
- Leave a footprint. Every agent writes a short handoff on the ticket: what changed, which files, and what the next agent should build on.
- QA checks main, and Done means merged.
- Stop idle agents. When an agent finishes or stalls, shut it down. Running agents cost money even when they're doing nothing useful.
- Parallel only for read-only work. Research, reading docs and analyzing data can fan out. Writing code to shared files can't.
The lesson
A perfect sprint board doesn't make agents a team. It makes them a list.
Parallel agents are great when the work is truly independent. The moment they write to the same files, the same database or the same API, parallelism stops saving time and starts costing it, and you pay twice to fix the same bug.
More agents doesn't mean more done. A clear lane for each agent, a real queue, and a handoff the next one can pick up does.
Connect on LinkedIn: Wasim Sheikh · Site: sheikhwasim.com · Notes: Wasim Sheikh on Substack · X: @anciwasim
Related: Handoff Note · Shadow Path · Undo Ledger · Release Pin · Boundary Contract · Cheap Twin · Receipt Gate · Golden Trace · Smoke Evals · Ship Gate · 5-Layer Agent Stack