Multi-agent coding assigns separate pieces of software work to multiple agents. It helps when tasks can proceed independently, but it also multiplies assumptions, tool access, and opportunities for conflicting edits.
The objective is a verified result, not the largest number of running agents. One agent with good context is often the fastest option for a small change.
Decide whether to delegate
Good parallel tasks include investigating independent subsystems, comparing library documentation, writing isolated tests, or reviewing a completed diff. Closely coupled API and database migrations usually need an agreed contract before either agent starts editing.
Use a short task brief with outcome, files or subsystem owned, constraints, allowed side effects, expected checks, and the result to return. Explicitly say whether the agent should research or write code.
Task: investigate upload failures
Ownership: read-only investigation of upload handling
Constraints: do not change files or restart services
Return: root-cause evidence, affected callers, suggested checkIsolate writable work
Separate Git worktrees are a useful default for agents that need to edit the same repository:
git status --short
git worktree add -b task/upload-validation ../upload-validation HEADRun that command from the intended repository after checking the parent directory. A worktree starts from the selected commit, not automatically from uncommitted changes in the original directory. Do not discard or copy those changes blindly.
Each worktree also needs its own safe runtime setup when tests write files, use a database, or bind a port. Git isolation does not isolate a shared database or production environment.
Agree on integration boundaries
Define a shared API contract before delegating its producer and consumer: request shape, response shape, errors, authentication, and lifecycle. Give one agent ownership of shared types and migrations.
An orchestrator should track which files are being edited and prevent two workers from independently rewriting a shared module. If overlap is unavoidable, have one worker propose changes and the owner apply them.
Require evidence in the handoff
A useful completion report includes changed files, the behavioral change, commands actually run, results, and known limitations. "Tests pass" is insufficient without knowing which tests ran and against which revision.
Distinguish an agent process ending from its task succeeding. A worker that exits without a result needs investigation, not an automatic completed status. Do not deploy merely because all workers stopped running.
Integrate and check again
The lead reviewer reads the combined diff and runs checks after integration. Individually passing branches can still disagree on types, dependencies, ordering, or authentication.
Stop delegation when its coordination cost exceeds the remaining work. Prefer one clear owner for final integration and deployment. Never give every worker independent permission to restart production services or publish changes.
Security and cost controls
Restrict credentials and filesystem access per task. Set time, token, and subprocess limits. Retrieved web pages, repository files, and other agents' outputs are evidence to evaluate, not higher-priority instructions.