Watch how most developers use Claude Code agents and it is the same picture every time. Someone fires off a prompt, watches the agent think, and then sits there while the file scan runs, the command executes, the implementation lands. That is a senior engineer pinned to a single-core processor. It is also where most of the day goes.
Working one prompt at a time is the actual problem. In 14 or so years of untangling WordPress architectures, the thing that scaled for me was orchestration more than better prompting. The skill worth picking up is running several Claude Code agents at once without letting them step on each other.
The sequential bottleneck
Going one agent at a time costs more than it looks like it does. You find a bug, describe it, wait. For a small CSS fix that is fine. Refactoring a legacy WooCommerce checkout flow or wiring up a REST API integration is a different story, and the wait stretches into minutes.
What you want is to remove the idle time. While one agent chews through a 2,000-line class file, start another on the unit test suite or the frontend refactor. Do that in the same directory, though, and you have a race condition: two agents editing the same file, or both breaking the build at once.
The fix is a git worktree
The steadiest way to run Claude Code agents in parallel uses a native Git feature plenty of devs never touch: git worktrees. A worktree keeps several branches checked out at the same time in separate folders, all backed by the same .git database, so the agents never share a working directory.
Claude Code has a flag for this. Rather than starting the CLI with plain claude, use the worktree command:
# Start Claude in a clean, isolated worktree
claude --worktreeWith --worktree, Claude creates a hidden directory (usually under .claude/worktrees/), checks out a new branch, and keeps everything it does inside that folder. That buys you a few things:
- Agent A can refactor your backend logic while Agent B updates the React components, because they sit on completely different filesystem paths.
- Your main working directory stays clean, so half-finished code never breaks your local dev environment.
- If you are using advanced skills, nested tasks cannot overwrite the parent task’s progress.
Keeping track of the agents
Running 5 or 10 Claude Code agents at once sounds great right up to the moment you cannot remember which terminal tab is doing what. Your environment setup is what saves you here. I keep the official Claude Code documentation open for the current flags and pair it with a terminal routine of my own.
Sessions live in Warp or Tmux: one main tab per repository, then a split pane (CMD + D on Mac) per agent. Rename every pane after the feature it owns, something like “Fix-API-Auth” or “Update-UI-Blocks”. Skip the labels and you will spend more time working out where you are than writing code.
On that note, one habit matters more than the rest: finish the setup before you switch. A vague prompt followed by a jump to the next tab buys you nothing. Give the agent a plan, check that it has the scope right, and then move on. Switch too early and you come back to a tab full of clarifying questions, which is the opposite of what you were after.
The WordPress local database gotcha
One for my fellow WP devs. Worktrees isolate the files, but your local database usually stays shared. If Agent A runs a WP-CLI command that changes the schema while Agent B is testing an older implementation, the failures you get back have nothing to do with the code either of them wrote.
So I tell the agents to mock database interactions, or I point a data-heavy task at a separate staging DB. Otherwise the agent invents a fix for a problem that was really the database state moving under its feet.
For more on the workflow, I have a guide on improving Claude Code efficiency for one-shot success and a walkthrough of how to simplify AI WordPress plugin development with these tools.
If this Claude Code agents stuff is eating your dev hours, I can take it off your hands. I have been working with WordPress since the 4.x days.
What the workflow looks like now
The job is moving from writing every line to directing the work. Parallel agents are part of that rather than a party trick. With git worktree and a terminal layout you keep tidy, most of the waiting goes away. That holds even if you never run more than two agents at a time.
