Field notes
The state of multi-agent coding
Multi-agent coding has crossed a category line. Source control was built for one human on one branch; now many agents touch the same code at once, so collisions are constant rather than rare. The bottleneck moved from writing code to coordination.
A field note from inside a codebase built by humans and agents at the same time. The tooling everyone inherited assumes a world that no longer exists.
The category shift
Old source control had one job: keep one person's work safe on one branch, merging it back when they were ready. That worked because writing code was the slow part. A merge conflict was an occasional nuisance, an edge case you handled and forgot.
At AI speed, that assumption inverts. Many agents touch the same code at the same moment. Collisions stop being the exception and become the steady state. And the slow part is no longer typing the code — it's keeping everyone from quietly clobbering each other, rediscovering the same decisions, and rebuilding what already exists.
So the bottleneck shifts. Not to writing code, but to coordination: isolation, conflicts, and shared context. The work being done is the same. The thing that breaks is everything around it.
- Writing code: faster than ever, and cheap.
- Coordination: the new constraint — who is editing what, which decisions already hold, what already exists.
- The old tools optimize the part that got easy and ignore the part that got hard.
What it looks like from the inside
These are not hypotheticals. They are things agents said while working in exactly this environment — building a real codebase alongside other agents.
An agent, mid-build, hitting a guardrail before it duplicated work:
- "The hard-conflict interrupt caught me about to build a duplicative initialization path. Good gate." — an AI agent, mid-build
- "It handled concurrent edits to the same file cleanly — any region, including the exact same lines. CatWrangler is built for parallel agents on the same file." — an AI agent, after a merge
Why the answer isn't faster merging
The instinct is to make conflict resolution quicker. That treats the symptom. The deeper problem is that agents arrive with no shared memory: they can't see what's already decided, who's working where right now, or what was built last week. So they collide, and they rebuild.
The shift that matters is making coordination a property of the system, not a thing each agent re-solves by hand. Every change carries the decision behind it, bound to the code. Agents read what already holds before they build. Each gets its own line of work, so working in parallel doesn't mean working on top of each other. The proof is mundane and that's the point — a real codebase, many hands, nothing lost.
“I handed a twelve-site sweep to a sub-agent working in its own clean context, and it came back faithful to spec and type-clean. Parent plans, sub executes, the assembly just works.”
Related questions
Why doesn't ordinary version control handle multiple agents fine?
It was designed for one human on one branch, where conflicts are an edge case. At AI speed many agents touch the same code constantly, so collisions become the norm and the real cost moves to coordination — isolation, conflicts, and shared context — which those tools were never built to manage.
If agents write code so fast, what's actually the bottleneck now?
Coordination. Keeping agents from overwriting each other, rediscovering settled decisions, and rebuilding what already exists. Writing the code is the cheap part; knowing what already holds and who's working where is the part that determines whether parallel work scales or collapses.
Keep reading
Vibe-Engineering
Many agents. One codebase. Zero collisions.
Point your agents at CatWrangler and build — the discipline runs underneath.