Coordinating Ten Agents That Share One Codebase

Ten shared work slots, five of them tagged as finished, and the team still couldn’t start new work. That’s the moment that mattered.

We run ten parallel copies of the same project so people and AI sessions can work on separate tasks without stepping on each other. Each copy comes with two pieces of paperwork: the ticket it’s currently serving, and whatever it’s still holding onto. When five of the ten looked unavailable despite their tickets reading finished or closed, the easy move was to wipe the board and call everything open again.

Trusting the label would have cost us real work

That easy move was also the wrong one. One of those ten slots was holding a prototype that was still being shaped. Another had work sitting in it that had never been backed up anywhere else, a local-only copy that existed in exactly one place. A blanket reset would have treated both as garbage, because the ticket attached to each one said nothing about what was still sitting inside.

The opposite move, trusting every open ticket completely and touching nothing, wasn’t right either. That approach keeps everything “safe” by never freeing anything, which quietly turns finished work into a permanent reservation on a resource other people need.

Neither shortcut answered the actual question, which was: does this slot’s paperwork match what’s really in it?

What checking both signals actually looked like

We went through all ten slots, one at a time, and compared the ticket state against the real contents. Five were attached to genuinely finished or closed work with nothing left behind, and those got freed. Three were on work that was still open and active. One was a prototype, deliberately paused, that someone would come back to. That left one interesting case: a slot whose ticket said done, but which was still holding a piece of work that existed nowhere else.

That last one is the case a fully automated cleanup would have gotten wrong in either direction. Wipe everything, and it’s gone. Trust the ticket blindly, and the slot stays tied up forever on a technicality. The right move was neither. It was a specific question put to a person: does this still need saving, or is it safe to let go? Someone made that call, the work either got backed up properly or was confirmed as no longer needed, and only then did that slot rejoin the free pool.

What the check bought us

After freeing the five that genuinely matched, we had six workable slots instead of a board that looked full. The number matters because it’s proof the process changed something real, not just proof that a status board got tidier. Ten slots don’t multiply how much work can happen at once if a third of them are quietly stuck holding onto claims nobody re-checked.

The same two failure modes show up in any shared pool, a fleet of vehicles, a set of hotel rooms, a bank of loaner equipment: trust the sign-out sheet completely and you lose track of what’s actually happening, ignore it completely and you can’t tell what’s free. Ten slots, checked one at a time against what they actually held, turned into six usable slots and exactly one question for a person to answer. That’s the ratio worth remembering: most of the pool sorts itself out from the two records agreeing, and only the leftover disagreement needs someone to actually look.

dxdev LESSON · paste into your AI coding agent
LESSON: Check the resource, not just the label on it, before you call it free
SOURCE: dxdev.com/blog/2026-07-18_locks-across-ten-clones
WHAT HAPPENED: A pool of ten shared work checkouts looked mostly occupied, even though the tickets attached to five of them were already finished or closed. Wiping the board and marking everything free would have destroyed a prototype and a piece of local-only work that neither ticket mentioned. Trusting the tickets and freeing nothing wasn't right either, since that lets finished work sit on capacity forever. The fix was to check both signals for all ten checkouts, the ticket state and the actual contents, and only free the ones where both agreed.
THE RULE: A shared resource pool's tracking state and its actual contents can disagree, and checking only one of them either destroys real work or leaves a growing pile of stale claims. Capacity comes back only when both signals are checked together, item by item, not through a blanket reset or a fixed time cutoff.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any shared resource pool, checkouts, worker slots, sandbox environments, licensed seats, whose "is this free" answer comes from only one signal, without also checking what is actually still sitting in it.
  2. Any proposed cleanup of a stuck-looking pool that is a blanket reset or a blanket trust, rather than an item-by-item check against two independent signals.
  3. Any automatic age-based cleanup rule applied to a pool where a legitimately long-lived, deliberately parked item could exist and get destroyed by it.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.