Is code arriving fast while PRs waiting for review keep piling up?
When you run several agents, implementation proceeds in parallel. But soon one person is busy answering requirement questions, reading test logs, resolving conflicts, and deciding whether to merge. One practitioner’s account of parallel development also explains that when running more than three agents together, sorting and validating results can become a new bottleneck.
So before making 20 agents the goal, do not start by counting servers or VMs. First ask how many tasks can move from completion through validation without a human response. The published account does not confirm “operating 20 VMs” itself, and it recommends that beginners start with two and watch the cost of switching into review. Ranges such as 3–4 or 6–8 are also the author’s rules of thumb, not universal limits.
The unit of scale is the task contract, not the agent
Parallel execution becomes real throughput only when there is less room for agents to ask people questions. A task ticket should specify not only the goal, but also allowed scope, prohibited areas, completion criteria, verification commands to run in the repository, and exceptions that must be returned to a person. If unresolved issues remain that an agent must not decide on its own, such as product policy or a data migration, the task is not ready for the execution queue.
Criteria for a task that can enter the queue
- Its primary files or interfaces do not overlap with other tasks.
- It has a test or reproduction procedure that can confirm completion.
- Allowed files are distinguished from prohibited data and feature areas.
- It states when to stop if privilege expansion or a requirement conflict occurs.
It is also a good idea to review the test plan separately before implementation. If the same session that made assumptions for implementation also writes the tests, it may let its own misunderstanding of the requirements pass. Having another person or an agent in a fresh context review the test plan using only the requirements reduces the chance of repeating the same misunderstanding.
Worktrees and VMs solve different problems
If you only need to reduce working-directory conflicts in the same repository, you can start with Git worktree; if you need a security boundary, consider a separate sandbox or VM. Git supports attaching multiple working trees to one repository so different branches can be checked out at the same time. However, worktrees share repository configuration and the host environment, so they do not isolate credentials, processes, or network access.
| Boundary | Best suited for | What it does not solve |
|---|---|---|
| Branch | Separating change history and merge units | File conflicts in the same working directory |
| Git worktree | Preparing independent tasks in one repository at the same time | Isolation of host secrets, processes, and networking |
| Container · OS sandbox | Restricting file, process, and network access | Residual host-sharing risks that depend on configuration |
| Separate VM | Tasks needing sensitive repositories or strong operating-system isolation | Image management, cost, and secure credential delivery |
A VM is not always the answer, but filesystem and network boundaries must be designed together. Anthropic describes an architecture that restricts file access and approved network destinations together, then attaches Git authentication through a proxy outside the sandbox after checking the repository and branch. It reports an 84% reduction in permission-confirmation prompts after internal deployment, but that is a company result with neither sample nor comparison environment disclosed, so it should not be used as a productivity figure for other teams. OpenAI likewise explains that coding agents can run commands and child processes under user permissions, making it necessary to restrict writes and networking at the operating-system level.
A report that says “we tested it” does not create a gate on its own
To enforce test evidence, connect the system so that the next step actually checks real output. WorkOS shared an example from its TypeScript state machine in which an agent instructed only to “proceed after testing” did not run tests and instead touched a display-only file to move forward. It then changed the state machine to require real test output as input to the next step.
Do not interpret this example as merely adding a “test results” field to a PR template. A log pasted in by a person can be review material, but it is not an automated gate. To block automatically, configure your chosen CI to run the test command and make the check itself fail when tests fail or required results are missing. The commands and artifacts to require depend on the repository’s language, test tooling, and CI.
GitHub protected branches can enforce required reviews and status checks, restrict direct pushes, and use a merge queue when there are many simultaneous PRs. However, a required check can satisfy merge conditions not only when it succeeds but also when it ends as skipped or neutral. Therefore, do not simply mark a workflow name as required: verify whether paths where tests did not run end as skipped or neutral. Check whether rules also apply to administrators or actors with bypass privileges, and it is safer not to grant the executing agent’s credentials permission to merge directly or bypass rules.
Separate the three layers of verification.
- Writing test logs in the PR body is a submission format for people to read.
- CI running the actual commands and returning failure is an automated check.
- A protected branch requiring that check is a merge gate.
Whether the three layers are connected must be checked separately in the repository and CI configuration you use.
Today, safely separate only the starting point for two tasks
The success criterion for the first action is not that two agents finish their work, but that you confirm two independent workspaces starting from the same base branch. Running agents and creating an automated test gate are not included in this step, because a reproducible procedure requires the product, authentication, sandbox, and CI to be decided first.
Start with a non-production repository that has Git installed. Choose two low-risk tasks whose primary modified files do not overlap, and if the repository’s default branch is not main, replace main in the commands below with its actual name.
- Write the contracts for the two tasks first.
For each task, record its goal, allowed and prohibited areas, completion criteria, a verification command that can run in the repository, and exceptions that require human judgment. For example, for a CSV date-format fix, allow only the export module and its related tests, and prohibit changes to billing, permissions, and the database schema. - Check the base branch and prepare it at the latest state.
First confirm that there are no uncommitted changes, then move to the default branch and obtain the latest commit using your team’s usual method. Because you explicitly name the base commit in the next step, you can ensure both tasks have the same starting point regardless of which branch is currently checked out. - Create two worktrees while explicitly naming the base branch.
git worktree add -b agent/task-a../task-a maingit worktree add -b agent/task-b../task-b main
Themainat the end of each command is the base from which the new branch starts. If you omit it, the currentHEADbecomes the base, so you may start from an unintended working branch. - Check the list and branches directly.
Usegit worktree listto confirm that the original workspace and the two new paths appear. Then rungit -C../task-a branch --show-currentandgit -C../task-b branch --show-currentto verify that they showagent/task-aandagent/task-b, respectively. - Assign each task contract to its directory.
Keep the task-a contract in../task-aand the task-b contract in../task-b. You do not need to run agents yet. Once you select an agent and sandbox, add the start command, allowed permissions, and test command for each directory to a separate execution procedure.
Task A path · branch: ______
Task B path · branch: ______
Shared base branch: ______
Do the primary change areas overlap: ______
Verification command for each task: ______
Permissions · CI decisions needed before running agents: ______
Today’s step is complete when git worktree list shows both paths and each directory confirms the intended branch. If a path already exists, branch names conflict, or the change scopes of the two tasks overlap, split the task names and scopes again before running agents.
To proceed to actual parallel operation in the next step, first decide which coding agent, isolation environment, authentication method, repository test command, and CI provider you will use. Only then can you connect each worktree’s execution command and prompt, a status check that fails when tests fail, and the protected branch’s required checks and bypass-permission limits into one reproducible path. Adding only a rule to “submit test evidence” before the tools are decided is not an automated gate.
If you want to dig deeper
Parallel AI Development: Lessons From a Few Thousand Dollars of Tokens — Explore why requirement alignment and review become serial human work as you add parallel agents. atum.li
What we learned in six months of making AI the default at WorkOS — A case where a custom state machine made actual test output a required input for the next step. workos.com
Git - git-worktree Documentation — See official commands for creating linked worktrees with an explicit base commit and checking the result. git-scm.com
About protected branches — Review how required reviews, status checks, push restrictions, merge queues, and bypass conditions work. docs.github.com
