Running many coding agents in parallel

How do you keep parallel agents from colliding?

Give every task its own branch and pull request, and give every agent its own area. At North Bay Ventures each long-running agent owns one thing, such as the website or infrastructure and mail, and asks the owner when it needs something outside it. Two agents editing the same files or the same server at once is the most common way parallel work goes wrong.

Small, separate pull requests also make each change easy to review and easy to roll back.

Git worktrees or one machine per agent?

Use git worktrees when parallel agents only edit and test code. Each worktree has its own files, but all of them share one machine's ports, hooks, home directory, credentials and services. Once agents run dev servers, databases or Docker, give each its own machine so they can all bind the same port without clashing.

Sandboxer's guide git worktrees or one VM per agent walks through the trade-off, and agent swarms covers running many at once on Sandboxer.

How should you brief an agent?

Brief it like a capable colleague who has none of your context. A good brief says:

• the goal and why it matters;
• what has already been tried or ruled out;
• which files, docs and sources to read, and which facts are allowed;
• what is out of scope;
• what to report back, and what would block it.

A vague brief produces confident work on the wrong problem. If you can't write a clear brief, the task isn't ready to hand off.

How do review passes work?

Review comes from an agent that didn't write the change. Give the reviewer the code and the goal, not the author's conclusion, so it reads the change fresh instead of agreeing with it. Small findings are fixed by the author straight away. Anything the reviewer and author disagree on goes to a person.

Then check the change where it runs. A deploy isn't done until production shows it: every page returns 200, the new text is on the live page, the old text is gone. Reports carry that proof, so nobody has to take "done" on trust.

What breaks when agents share infrastructure?

Shared configuration is where parallel work quietly collides. In one real case on our shared web server, a deploy script added a new site's certificate settings to the first entry in a shared list. That entry belonged to another site, which used a self-signed certificate, so the new site got one too and wouldn't load. Another agent found it in the server logs.

The fix was a rule worth copying: address shared things by a name or ID you own, never by position, and check whether something already exists before adding it. The same rule applies to DNS records, server routes and anything else several agents touch.

Which decisions stay with people?

The ones that are hard to reverse or visible to customers: spending money, legal terms, DNS, deletions, public launches and bulk email. Agents do everything up to that point, such as preparing a ready pull request or a staged deploy, and then wait for a person's explicit yes. Sandboxer has a guide on requiring human approval before an agent runs a command.

Shipping risky features switched off behind a feature flag moves more decisions into the reversible column: the deploy is routine, and turning the feature on is the deliberate step.