A year of AI coding / 08
One developer and several coding agents
Parallel coding agents can reduce waiting, but their value depends on task independence and how much attention the resulting decisions require.
By Grafty team · · 3 min read
Written in .
The first time several agents work on independent tasks, the benefit is obvious. One inspects a test failure while another updates a component. You stop waiting for a single conversation to finish before starting useful work elsewhere.
The harder question appears when both return. Each has a diff, an explanation, and a decision it wants you to make. Parallel execution can reduce machine waiting while increasing the number of things competing for your attention.
OpenAI's Codex app launch on February 2, 2026 made that working pattern explicit through parallel agent threads, worktrees, and review tooling. The official release record describes the desktop interface and its original features. The interface made concurrent work easier to manage, but the number of active agents is not itself a measure of useful throughput.
Open full-size diagram Choose tasks that can finish independently
Suppose a developer has three jobs: update a shared API response, modify the frontend that consumes it, and fix an unrelated documentation link. Starting three agents immediately looks efficient, but the first two tasks share a contract.
They may still run in parallel if the response shape is agreed first. Without that agreement, the frontend agent can build against an assumption that the backend agent later changes. The developer ends up integrating two plausible answers to different versions of the task.
We would separate work along actual dependency boundaries. An isolated test investigation can run while another agent handles a UI correction. A schema change and its consumers need an explicit contract or a staged handoff.
Worktrees help prevent file collisions, but they do not eliminate conceptual conflicts. Two clean branches can disagree about the meaning of a status field. The merge tool will not detect that kind of inconsistency.
Open full-size diagram Make interruptions worth the attention
A useful agent update explains why the developer needs to look now. It might report that a test exposes an undocumented requirement, or that the next step needs access to a different environment.
Routine progress usually does not need an immediate decision. If every command produces a notification, the developer becomes a dispatcher for activity they cannot usefully influence. We would prefer a view that separates ongoing work from work blocked on a specific choice.
The final handoff matters just as much. A concise summary should point to the changed behavior, the relevant verification, and any remaining uncertainty. It should not require the reviewer to reconstruct the task from a long chat transcript. Nor should it replace reading the diff.
There is a straightforward experiment for teams considering this pattern. Take a small set of comparable tasks and track the time spent preparing work, waiting, reviewing, and repairing integration problems. Then compare a single active agent with a modest amount of concurrency. The useful limit may be lower than the interface allows.
Keep some capacity free
We would avoid assigning every available slot at once. Unexpected failures and review corrections need attention too. When all work is in flight, a small blocker can force expensive context switching.
The goal is not to turn one developer into a permanently busy manager of automated workers. It is to let useful work continue while the developer handles the decisions that deserve judgment.
Parallel agents are most valuable when they return results that are easy to evaluate independently. If supervising them consumes the time they save, more concurrency is the wrong optimization.