Ivan Mišić product · tech · ai

Asking Claude Code to do multiple things at once

JAN 11, 2026 · updated AUG 19, 2026 · 4 min · 714 words

on this page · 6

Claude Code can delegate independent parts of a task to subagents. Each worker has its own context, tools, and permissions, then returns a result to the main conversation.

I use parallel work for separate checks and research. I keep dependent steps and overlapping edits under one owner.

That boundary matters more than the number of agents.

Split independent work

CSS, JavaScript, and HTML checks can run separately because one result does not depend on another. Ask for the split and the final format:

text
Review this project in three independent areas:
1. CSS structure and likely responsive problems
2. JavaScript errors and fragile behavior
3. HTML semantics, links, and accessibility basics

Use separate read-only subagents for the three reviews.
When they finish, return one report grouped by severity.
Do not edit files.

Keep the first pass read-only, so you can compare the findings before anything changes. You can decide which findings deserve changes after seeing the whole report.

Comparison showing independent CSS, JavaScript, and HTML checks running in parallel before one combined report, while dependent analysis, decision, and implementation steps remain sequential

Separate checks can run in parallel and feed one report. Keep work sequential when each step needs the previous result.

Automatic or explicit delegation

Claude Code includes built-in subagents and may delegate when a task matches one. Custom subagents also have descriptions that tell Claude when to use them.

If the split matters, I ask for it directly and name the independent areas. You can also @ mention an available subagent to guarantee that it runs for that task, and /subtask hands one job to a subagent without restructuring the whole prompt:

text
/subtask Check every HTML file for missing alt text and report the list. Do not edit anything.

/list-agents shows what is available to mention, and /tasks shows what is currently running.

Do not assume that a batch request will always create one worker per item. Claude may keep the task in the main conversation, group items, or run them in rounds. The current subagent documentation explains automatic and explicit invocation.

Always ask for synthesis

Several correct reports can still leave you with a mess. Ask the main conversation to combine them into one result.

text
Check each CSS file for deprecated properties.
Return one table with the file, line, property, browser risk, and recommended replacement.
Group repeated findings instead of listing the same issue many times.

I ask for one combined result, ranked by what changes the decision. Otherwise the review can become a pile of agent summaries.

Keep dependent work sequential

Do not parallelize steps that build on each other:

  1. inspect the current data model
  2. decide the migration
  3. create the migration
  4. run and verify it

The decision in step two needs the evidence from step one. The migration and verification need the agreed decision.

The same applies when two workers would edit the same files. Give each worker a separate area or use worktree isolation so changes do not collide. I still keep one owner responsible for reviewing and combining the changes.

For a file-organization task, start with a plan:

text
Review the downloads folder and propose where each file should move.
Do not move, rename, or delete anything until I approve the plan.

Parallel deletion is still deletion. More workers do not make the decision safer.

Account for context and permissions

A subagent starts with isolated context. It does not automatically receive every detail from the parent conversation, so the task message needs the goal, constraints, paths, and expected output.

Background subagents cannot stop to ask for a new permission. An action that needs approval may be denied, so use foreground work when the branch needs questions or interactive permission.

Parallel work also multiplies token use and can hit concurrency or rate limits. Each worker needs startup context, and the main conversation still spends time combining the results. Measure the result instead of assuming ten branches will finish in one-tenth of the time.

How I use it

My website has rules for areas such as CSS, security, PHP, and the database. When I audit those rules against the codebase, separate read-only workers can inspect different areas and return one report.

This saves me time because each worker checks one area and the main conversation combines the findings. I still review the report before changing a rule.

Start with two independent read-only checks. Ask for one combined result. Add parallel editing only when file ownership and recovery are clear.