One agent or subagents? When should you parallelize a coding task?

Short answer: use one agent for a small fix, a set of tightly coupled files, or a task with one acceptance check. Subagents can save time on codebase exploration, independent test groups, security review, or work packages that do not touch each other. Running three agents against the same files usually creates merge and verification debt rather than speed.

OpenAI says the mix of work delegated to coding agents inside its research organization has shifted toward higher-level, longer-horizon tasks. That is an internal company observation, not an independent productivity study.[1] The practical question has still changed from "Should I use an agent?" to "Should this job stay in one thread or be split into independent work?"

The shortest decision

• One agent: a small bug fix, one feature, a coupled refactor, or sequential execution of one plan.
• Subagents: codebase exploration, log analysis, independent tests, security review, and performance review.
• Separate worktrees or branches: parallel implementation across independent file groups.
• Human gate: architecture, data migration, payments, authentication, and production changes with expensive rollback.

Codex documentation recommends starting subagents on read-heavy exploration, tests, triage, and summarization. It warns that parallel write-heavy workflows can create conflicts and coordination overhead.[2] That is the vendor's usage guidance, not a guarantee for every repository.

When is one agent better?

Keeping context in one place matters when the steps are tightly coupled. Changing a function, updating its two callers, and fixing the tests is one example. If a second agent does not know the first agent's current decision, it may edit the same code under a different assumption.

Start with one agent when at least three of these are true:

• The change touches fewer than five files and they call one another.
• One test, build, or screen flow can measure success.
• Order matters because the second step depends on the first.
• You can read the complete diff in one sitting.

Raising reasoning effort is not the same as adding agents. An ambiguous but indivisible root-cause investigation may fit one strong agent with a plan better than three fast agents. The reasoning effort guide covers thinking depth; this guide covers how many separate work streams the job needs.

When do subagents save time?

Parallelism works only when the pieces are independent. A main agent can retain requirements and final decisions while subagents gather separate evidence. Codex documentation says subagents work in separate contexts, summarize results back to the main thread, and each perform their own model and tool work.[2]

Good candidates include:

• One agent maps authentication while another inspects the test harness.
• Separate reviewers look for security issues, test gaps, and performance risks.
• Independent package test suites run at the same time.
• A large migration is split into groups with non-overlapping file ownership.
• A fresh context reviews a diff without sharing the implementer's assumptions.

Anthropic also recommends subagents for research that would otherwise fill the main conversation with file reads and command output. Its Claude Code guide suggests a separate reviewer that looks only for correctness or explicit requirement gaps.[4] This is vendor advice too. A second agent's finding is evidence to inspect, not an automatic verdict.

Three bad parallelization patterns

The first is assigning the same file to two agents. Even two sound solutions may choose different names, data shapes, or error behavior. One gets lost during merge, or the merged result creates a third behavior nobody intended.

The second is starting dependent stages together. If the database shape is not settled before API and UI work begins, both agents guess the missing contract. The quick start returns later as two repair passes.

The third is splitting work with vague prompts: "look at the backend," "check tests," and "review security." Without a distinct output, forbidden scope, and acceptance check for each worker, the main agent receives three long reports that do not fit together.

OpenAI states that subagent workflows use more tokens than comparable single-agent runs because each worker performs its own model and tool work.[2] Wall-clock time can fall while cost and review load rise. The benefit comes from clean work boundaries, not agent count.

A practical split test

Write five lines for every proposed work package:

1. What is the expected output?
2. Which files or systems may it read?
3. Which files may it change?
4. Which command or evidence proves success?
5. What input must arrive from another package?

If the fifth line is empty, the package may run in parallel. If it is not, run it later or freeze that input first. This small check catches work that only looks independent.

For a payment module change, exploration may be parallel: one agent maps the call chain, one finds existing tests and fixtures, and one checks the official API change. Implementation should remain one stream because data shape, error handling, and test expectations depend on the same decision.

How should model and reasoning settings be assigned?

Not every worker needs the most expensive model. Codex documentation recommends a faster model for narrow, repeatable work and a stronger model for ambiguous multi-step jobs. Subagents can also inherit the parent model and reasoning settings.[2] These are OpenAI's own routing suggestions, but the task principle survives model-name changes.

A practical distribution:

• Fast model, low or medium reasoning: file listing, symbol search, log classification, and running tests.
• Balanced model, medium reasoning: test-gap analysis, bounded implementation, and documentation checks.
• Strong model, high reasoning: architecture conflicts, security review, the main plan, and reconciling results.

The GPT-5.6 Sol–Terra–Luna pillar guide covers the broader speed, balance, and depth choice. This article is not another model-family comparison. It decides where the chosen models belong in a single-agent or multi-agent workflow.

The tool also matters. The Codex CLI, Claude Code, and Gemini CLI comparison covers which terminal agent fits each job. Choose the execution boundary first, then add parallelism inside it.

What should the main agent own?

Treat the main agent as the decision and integration point, not as a fourth developer. It should retain requirements, make sure work packages do not overlap, collect results with evidence, and judge the final diff against one acceptance list.

OpenAI's Codex guide frames a useful task with a goal, context, constraints, and a "done when" condition. The same guide recommends tests, lint, type checks, behavior checks, and diff review before accepting a change.[3] Keep those completion criteria with the main agent. Local success by every worker does not prove the product flow works as a whole.

A short main-agent brief:

• Collect findings with file and evidence references.
• Do not merge conflicting advice automatically; make and explain the decision.
• Separate out-of-scope changes.
• Run focused checks, then the appropriate broader tests and build.
• Compare the final diff with the original request.

The coding-agent output verification checklist expands this final gate. More agents do not reduce verification. They make it more important because the workflow creates more independent assumptions.

A low-risk start for a solo builder

Do not begin with three writing agents. One main agent and two read-only workers are enough:

1. The main agent writes the task and acceptance check.
2. One worker maps the relevant code path.
3. Another finds test gaps and likely regressions.
4. The main agent implements and runs the checks.
5. A fresh reviewer examines the diff only for correctness and missing requirements.

Exploration is parallel, writing is serial, and review is independent. File conflicts stay low and decisions remain traceable. If the job grows, move independent packages into separate worktrees. The local vs cloud coding-agent guide helps decide where longer jobs should run.

Final choice

Keep one agent as the default. Add subagents when work packages are genuinely independent and their outputs and verification paths are written before they start. Parallel reading is usually safe. Parallel writing needs separate file ownership and a merge plan.

Do not use agent count as the success metric. Measure elapsed time, token or credit cost, merge conflicts, human review time, and first-pass acceptance checks. If one agent takes 20 minutes while three agents take 12 plus 15 minutes of integration, parallelism lost.