How to run parallel coding agents without losing the review

Split by decisions the agents can make independently

Suppose your team wants to improve an issue list. One change adds CSV export. Another improves the empty state when a filter has no matches. Those tasks can proceed together if the existing list API and filtering behavior stay fixed. Each has a result a reviewer can inspect without waiting for the other.

A third task changes the filtering API itself. That changes the assumptions under both earlier tasks. Settle the API contract first, or make the dependent work wait. Different filenames do not guarantee independent behavior: an API response and the component consuming it can disagree while Git merges both cleanly.

Write down which decisions belong to each task. For the CSV change, specify whether export includes all matching records or only the visible page, which columns appear, and how permissions apply. Those answers prevent two agents from inventing incompatible versions of the product.

Give each agent a brief that ends in evidence

A useful brief names the outcome, constraints, and acceptance checks. It should also tell the agent when to stop and ask. Use the same repository revision for related tasks so reviewers can distinguish deliberate differences from an outdated starting point.

Task: Add CSV export to the issue list.
Scope: Export the current filtered result, across all pages.
Keep: Existing API shape and visibility permissions.
Check: Empty result, commas in titles, and hidden records.
Handoff: Changed files, test commands and results, sample CSV.
Ask before: Adding an endpoint or changing the filter contract.

Assign the empty-state task its own checks, including keyboard navigation and clearing the filter. Copying one generic testing paragraph into every brief makes it easier to miss the behavior that distinguishes the tasks. An agent should know what would make its particular change wrong.

If you use Claude Code and Codex together, apply the same briefs and acceptance rules to both. Choose the tool after defining the work. This workflow does not depend on a claim that either model is universally better at a type of task.

Separate the running apps as well as the files

For local work, Git worktrees provide separate working directories attached to one repository. Each agent can work on a different branch without switching the other agent's checkout.

# Run in your repository; these create new sibling directories.
git worktree add -b agents/csv-export ../issue-csv HEAD
git worktree add -b agents/empty-state ../issue-empty HEAD
git worktree list

Both local directories still use the host machine. Assign different application ports, check each server's startup output, and keep each browser pointed at the intended instance. A screenshot from the other agent's server can look convincing while proving nothing about the branch under review.

A separate cloud computer can isolate local processes and ports. Shared external services still need a plan: two environments using the same development database can overwrite the same fixture records. Give each task disposable data or a separate namespace. The worktrees and sandboxes guide covers these boundaries in more detail.

Make contract changes visible immediately

Choose an owner for shared interfaces before implementation begins. If the export task needs a new response field, pause the dependent part and record the proposed field where both agents can see it. An instruction in one private session does not update another session's assumptions.

In Uno, a workspace groups repositories, tasks, sessions, rules, and skills. Use separate sessions for independent goals, and keep follow-up decisions with the original work. The workspace guide explains that arrangement. Each task still needs an owner to resolve conflicting requirements.

Check in at meaningful boundaries: when a dependency changes, when a check fails, and when a patch is ready for review. Asking every agent for constant summaries consumes attention without necessarily revealing a decision that needs intervention.

Test the combined behavior before merging

Review each patch against its own brief, then check the combination against the current target branch. For the issue-list example, export after applying a filter, clear the filter, and visit a filter with zero results. Verify that export and the empty state agree about which records exist.

Run the relevant checks again when the merged state changes the assumptions they tested. A GitHub merge queue can run required checks against the latest target branch and earlier queued pull requests. Your tests must cover the interaction for that process to catch it.

Runtime isolation cannot resolve a semantic conflict, such as two valid patches choosing different meanings for an empty filter. That requires a product decision and a corresponding check. See how to verify coding agent work for an evidence-based handoff.

Add concurrency only when completed work increases

Start with two independent tasks. Track the changes accepted after review, reviewer time, and work reopened because of integration failures. Keep waiting tasks visible too. A draft pull request and an accepted change represent different amounts of finished work.

If reviewers already have a queue, another agent may create more waiting patches. Improve the task boundaries or review capacity before increasing concurrency. The useful number of agents depends on the repository's dependencies and the people available to evaluate the results.