Codex finished 15 of 26 tasks with parallel agents, versus 9 without them. The average run still took longer.
In Han Li and colleagues’ October 7 study of dynamic concurrency, those NL2Repo runs used a July GPT-5.4 configuration. Mean runtime increased from 9.4 to 9.9 minutes. More completed tasks and faster delivery were different outcomes.
When your coding tool offers another agent, the choice is what to give it. Consider a hypothetical CSV export feature: a serializer and a download button can progress together once the input format is agreed. Before that, a second writer must wait or guess.
Following that feature through shared files, handoffs, and the final download gives you a way to choose the next assignment: a second writer, an independent reviewer, or a single owner for the unresolved decision.
Dynamic concurrency lets the main agent decide during execution when to create workers and what to assign them. The authors compared this policy enabled and disabled across 354 tasks and 2,124 executions. NL2Repo was one subset of that broader evaluation.
This small subset distinguishes completion from speed. It cannot establish an October product ranking; extensive repeated runs were outside the study’s scope.
Before choosing an orchestration pattern, decide which improvement matters for the task. A larger implementation may justify extra coordination if it produces a complete feature. A short repair with an obvious next edit has less independent work to distribute.
The model’s ability to write code is one layer. The product’s scheduling and state handling are another. Dividing a particular feature into useful assignments is a workflow decision. More capable models still receive whatever dependencies that workflow creates.
In the hypothetical export feature, the button downloads the currently visible table rows as comma-separated values (CSV).
“Build the CSV exporter” and “wire up the button” sound like separate jobs. They become separate once both workers know what crosses the boundary. Does the exporter receive already filtered rows? Who selects and orders the columns? Does it return text or a downloadable file? How does an error reach the interface?
Without those answers, the UI worker may pass every row while the serializer assumes filtering has already happened. Both pieces can look reasonable in isolation, yet the download contains records the user did not choose.
Put the shared decision first. For this example, define an exporter that receives the visible rows and an ordered column list, and returns CSV text. Agree how commas, quotes, line breaks, empty values, and errors are represented. Keep download creation with the UI owner. This is a proposed division of responsibilities, not a tested implementation.
Now the serializer worker can implement the conversion while the main agent connects the button to the agreed function. Neither needs to invent the other’s inputs.
The main agent still has useful work during that overlap: handle the button’s disabled state, follow the application’s existing download pattern, and collect edge cases for the combined check. Waiting for a worker should not silently become the entire plan.
This gives a concrete rule for starting a branch: its required inputs must already exist. If the serializer’s return type is still being decided, a second implementation worker will either wait or guess. Assigning it a read-only investigation of existing export behavior creates a useful result without competing to settle the same interface.
Anthropic’s dynamic-workflow documentation describes moving orchestration into a script. Intermediate results live in script variables, and the runtime coordinates sub-agents. That changes where the plan and returned information are held.
It leaves a separate question for any deployment: what can those workers change together? Separate conversation histories do not, by themselves, create separate files, temporary directories, package manifests, databases, or running servers.
In the CSV example, two workers could edit different source files while both writing a fixture called /tmp/export.csv. One worker’s check would then read the other’s output. A clean source-file split would not explain that interference.
Give each worker its own output location for disposable artifacts. Keep shared configuration changes with the integration owner, or have workers return proposed changes for that owner to apply. When isolated checkouts are available, they can separate code edits; shared services and external state still need explicit ownership.
The distinction also changes the assignment. “Only edit the serializer” says little about test fixtures or dependency updates. A usable brief names the allowed source files, the scratch location, and which shared resources the worker must leave for the main agent.
A worker returning “done” leaves several decisions unresolved. The main agent needs the actual patch, the interface version it assumes, the checks performed, and anything still unfinished.
For the serializer branch, a useful handoff identifies the changed files and includes output for a row containing a comma, a quote, and a line break. It also states whether the worker changed the agreed error behavior. The integration owner can then decide whether to accept the patch or resolve the disagreement before connecting it to the button. The final check belongs after that connection. Download the file through the feature’s actual entry point and compare its rows and column order with the visible table. Exercise the empty and error states agreed in the contract. A serializer check cannot establish that the UI passes the correct row set.
Factory’s September 27 concurrency-testing guidance makes a related verification point: a successful dynamic detector run covers the paths exercised by its workload. The claim needs to match what the check actually reached. For this export, passing a conversion check and passing the click-to-download path support different conclusions.
Leave room for integration inside the task budget. If a worker cannot finish in time, the main agent needs an explicit choice: take over the remaining change, reduce the deliverable with approval, or report the unresolved part. Waiting beyond the deadline cannot produce an integrated result within it.
For the export feature, a second writer becomes useful once the shared contract is settled and both branches have their inputs. Before that point, an independent reviewer has a clearer job: identify cases the proposed contract misses, using the feature requirement rather than editing the same implementation. That reviewer should return a concrete case and the behavior it expects — for example, a filtered-out record appearing in the downloaded file. The implementation owner can act on that finding. A generic request to “review quality” gives the main agent less to integrate.
For the next CSV export assignment, the first parallel task should therefore follow the feature’s state: an independent requirements review while the interface is unsettled, or serializer implementation once it is agreed. The main agent keeps the button and the final download. That allocation gives each worker a useful place to finish. Parallel Coding Agents: What to Delegate First was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.