How-to
How to let two people build on one repo with agents
Point both people's agents at CatWrangler and each one automatically gets its own line of work. Nobody writes the shared trunk directly. Incompatible choices get caught when intent is described; the rest is merged cleanly. Nothing is ever silently overwritten.
Two people on one repo, each running their own agent, is exactly where things usually go sideways: clobbered files, surprise rebuilds, a merge nobody volunteers for. Here's how to make it boring instead.
What you don't have to do
No branching scheme to agree on. No "who's touching that file right now" Slack thread. No merge-day standoff. CatWrangler sits in the middle of every write, so coordination is the system's job, not a meeting.
- Each agent gets its own identity and line of work the moment it connects — zero setup.
- Two agents editing different parts of the same file don't block each other.
- Conflicts on shared things — env vars, endpoints, tables — get caught too, not just the obvious file collisions.
- 01
Point both agents at the same repo
You and your collaborator each connect your own agent to CatWrangler on the shared project. On first connect it reads the existing code and decisions, so neither agent starts from a blank slate — and there's nothing to install or self-host.
- 02
Let each agent take its own lane
Every agent automatically gets its own line of work. The shared trunk is never written to directly, so one person's in-progress change can't land on top of the other's. No branch names to coordinate, no locks to pass around.
- 03
Describe the change before building
Each agent states its intent in plain language and gets back the exact files, functions, and the decisions behind them. If the two intents make incompatible choices, that clash surfaces here — before any code exists — and gets negotiated while it's still cheap to change.
- 04
Build on the briefing, reuse what's there
Before either agent writes a line, CatWrangler surfaces code and decisions that already do the job, so an agent extends rather than duplicates. Often the planned work turns out to be half-done already — by the other person, last week.
- 05
Submit and let the merge sort it out
On submit, each change is validated: it must cover the decision it claims and build and pass tests before it can merge. Compatible changes from both agents are combined automatically; anything that can't be safely resolved is routed back to the responsible agent, blocking until it's clean.
- 06
Ship without a handoff
A merged change builds, validates, and deploys itself — no separate pipeline, no downtime, and a bad deploy rolls back. Both of you keep moving; the result is one coherent codebase instead of two people's edits stapled together.
“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.”
Related questions
What stops one person's agent from overwriting the other's work?
Work is never silently overwritten. Each agent has its own line of work and the shared trunk is never written directly, so a submit can't land on top of someone else's change — it has to merge cleanly first, or it blocks until it does.
Do we have to agree on who works on what beforehand?
No. Incompatible choices are caught for you — once when each agent describes its intent, and again at merge. If both agents pick the same task, the system tends to surface it as already-done before the second one writes anything.
Keep reading
Vibe-Engineering
Many agents. One codebase. Zero collisions.
Point your agents at CatWrangler and build — the discipline runs underneath.