Last Tuesday I sat down to audit every dev project I'd written over the past few years. 77 of them. Old courier-logistics monorepos, abandoned starters, a clinical reasoning engine, half a dozen Telegram bots, a SaaS framework I keep reusing, two startups, a Rust process manager. Different stacks, different ages, different employers, different states of git hygiene.

I gave the job to four Claude Code agents working in parallel. They were done in about 90 minutes.

Below is the pattern they used, and why a version of it now runs inside a 2,200-commit production codebase at my day job.

Why one agent isn't enough

Single-agent Claude Code is fine until you hit one of three walls.

The context window starts choking on a big codebase. The work is wider than it is deep, and serial reading wastes wall-clock. You want the orchestrator to keep judgment, not get buried in file diffs.

A swarm fixes all three. Each agent gets a slice. The lead keeps the map.

The hard part isn't spawning agents. Spawning is one tool call. The hard part is making sure four of them don't trip over each other.

The pattern

Claude Code ships with two primitives that, combined, give you a clean swarm.

TeamCreate + named teammates. Each agent has a stable name (analyst1, designer, metrics) and joins a team with a shared task list.

SendMessage to coordinate. The lead addresses any teammate by name. Teammates idle between turns and wake when messaged.

Wire those to a TaskList and you have a coordination plane. Each task carries an owner field. Setting owner = analyst3 is your atomic lock. Until that field changes, the task belongs to that agent.

For the audit I made 77 tasks, one per project. I spawned four analyst teammates with the same prompt template: read the project at code level (not commit messages), parse Claude Code session transcripts if any exist, write a per-project dossier. Then let them loose.

The race condition I shipped on day one

First attempt: each teammate, on idle, runs TaskList, finds the lowest-ID task with no owner, claims it, does it, marks it complete, repeats.

That worked for the first ten minutes. Then two analysts grabbed the same task within the same second. The TaskUpdate that set the owner went through twice. Both did the work. The second one overwrote the first dossier with a slightly different version of the same content.

Classic optimistic-concurrency mistake. The fix is boring and reliable: stop racing for low-ID tasks. The lead pre-assigns owners on the entire remaining range before spinning the swarm back up.

I partitioned the remaining work into four contiguous blocks (#33–43, #46–56, #57–67, #68–77) and set every owner in advance. Now when any agent reads the list, every task is already claimed by someone. Nothing left to race for. Each agent processes its own block in ID order and reports back when the block is empty.

Zero collisions for the rest of the run.

What came out

Sixty dossier files. Twenty-two tagged showcase, thirty-eight supporting, seventeen skip. The skips were honest: client work where my commit share was under 10%, abandoned scaffolds, empty stubs. Bad data is worse than no data when the goal is a personal-brand audit.

The interesting findings weren't in the headline projects. They were in the cross-cuts. My boilerplate had quietly become the foundation under four products. The same codebase showed up in five different clients. On one healthcare CRM my commits totalled 962 out of 2,208 (top contributor), even though the surface-level metadata I'd been relying on said only about 700. Manual git history is lossy. A swarm with shared output catches the drift.

The production version

This isn't a hobby pattern. The same multi-agent Claude Code workflow runs in our healthcare CRM at the day job, on a 2,200-commit codebase. The CLAUDE.md there defines four custom subagents:

• django-backend-specialist — owns models, views, URLs.
• advertiser-frontend-developer — owns the advertiser dashboard.
• patient-frontend-specialist — owns the patient portal.
• linting-specialist — runs last, owns the diff.

There's an explicit inter-agent contract. When the backend changes a view, it reports the new endpoint, the URL, the response shape. The frontends know to ask for that data before they start. Linting runs at the end of the chain, not the middle. The orchestrator (me) holds the architecture. The agents hold the file diffs.

On one of the products I ship with this pattern, an internal-tools rebuild, about 29% of the commits are AI-authored under my direction. The other 71% are mine. The split is visible in git shortlog. Nothing to hide, nothing to inflate.

The honest part

This doesn't replace senior engineering judgment. The orchestrator still has to know what good looks like. When an analyst returns a weak dossier, you have to recognize it and ask for a redo. Two agents disagreeing? You resolve it.

What it does give you is leverage. One engineer with a swarm covers staff-level surface area. The bottleneck shifts from typing speed to judgment quality, which is the right bottleneck to have.

If you want to see what the swarm actually produced, the 60 dossiers live at davr.dev/projects. Each one is a code-level audit, not marketing copy.