How I run AI coding agents in parallel to ship faster

Most evenings I've got three Claude Code agents going at once, each in its own copy of the repo, each on a feature it can't see the others touching. One builds a settings screen, one hunts a sync bug, the third rewrites an API client. I described all three out loud, set them going, and now the work is mostly steering and reading what comes back.

I write about a tenth of the code by hand these days, and none of the setup is tied to a particular language.

The stack

• Linear holds the work. Every feature and bug is an issue, so there's always a queue to pull the next agent onto.
• Superset runs the agents. Each one gets its own git worktree, a separate checkout of the repo, so several can run at once without touching each other's files. A worktree spins up straight from a Linear issue.
• Claude Code writes the code. Given decent context, it handles most of an implementation on its own.
• GitHub, through the gh CLI, handles commits, pull requests, and review comments without leaving the terminal.
• Wispr Flow turns talking into text. I dictate prompts at around 165 words a minute and type at about 85, so I talk.
• just wraps build, test, lint, and run into one-word commands, which is what lets an agent check its own work instead of waiting on me.

The core loop

1. Plan first. I open plan mode, describe the feature, and point Claude at the files it should read with @. I dictate this part, since saying it out loud at 165 words a minute beats typing it at 85. If there's UI involved, I paste in a screenshot.
2. Answer the questions. A good planning pass argues back and asks about the edge cases before it writes a line. I answer, and the plan gets sharper.
3. Let it build while I set up the next feature.
4. Check the work. The agent runs the build and the tests itself, then I read the result and send a follow-up if something's wrong.
5. Simplify. I run /simplify, which reads back everything that changed, finds the reuse I missed and the redundant code, and applies the cleanups.
6. Review. I run Claude's own /code-review on the branch. It flags the real problems, and I have it fix the ones worth fixing.
7. Ship it. When I'm building solo on a self-contained change, /ship commits, pushes, and fast-forwards main in one step, with no PR to babysit. When the work needs review or it's part of the parallel flow, /pr opens the pull request that Linear tracks instead.
8. Write the lesson down. If I had to fix something by hand or repeat a prompt, that goes into the project's CLAUDE.md so I never explain it again.

How the three stay in sync

The thread that ties Linear, Superset, and GitHub together is the branch name. When I start an issue in Linear, it hands me a branch named after it, something like will/lin-412-fix-sync-bug, and flips the issue to In Progress. Superset opens a worktree on that exact branch, so the agent is on the right one before it writes a line.

From there the status takes care of itself. The agent commits and opens the PR through the gh CLI, and because the issue ID is baked into the branch, GitHub and Linear find each other with no input from me. The PR links to the issue, and as it moves from open to reviewed to merged, the issue walks from In Progress to In Review to Done on its own. I never drag a card across a board. Superset shows the CI and review state next to each workspace, so one glance tells me which of the running branches is green.

Running several at once

The loop is useful on its own. Running a few of them at once is what changed my output.

The thing that used to make this impossible was the filesystem. Two agents editing the same checkout would always run into conflicts. A git worktree is just a second working copy of the repo on its own branch, so an agent in one can't reach the files in another. Superset leans its whole design on that, giving every agent its own worktree, so several running at once is safe by construction.

I write the plan for one, set it loose, and open the next issue. An hour in, all three are going, each blind to the rest, and the job is to rotate between them: answer a question here, read a diff there, approve a PR on the third.

Three is the most I run. The real limit is how much direction I can give, and past three I can't give enough. I'm spread too thin to brief any of them properly, rushing to keep up, losing track of what each one is doing. That's when the sloppy code starts slipping through and getting merged. Some people run ten at once and never lose track. I'm not one of them. Three is where I can still think each feature through and steer it, and the steering is the whole job now. The other thing I watch is overlap. Put two agents on the same file and you're back to clobbering, so I split features along lines that don't cross.

Keeping the agents sharp

An agent gets noticeably dumber as its context fills up. Past about 60% full it starts dropping instructions and writing confidently wrong code, so I keep the context window clear the way I'd keep a desk clear. I watch it with /context. Around a third full I run /compact, which summarizes the conversation so far and keeps going. For anything genuinely new I run /clear and start clean, because a fresh window aimed at one task beats a stuffed one dragging three features of history behind it.

The other half of staying sharp is CLAUDE.md. It holds the project's standing context: the conventions, the build and test commands, the gotcha that bit me last week. The conversation window empties after every task. CLAUDE.md is the part that remembers.

No IDE required

An agent can only check its own work if everything it needs is a command. So every project gets a justfile: just build, just test, just lint, just run. When the build is one word, the agent runs it, reads the errors, and fixes them before handing the work back. No screenshots of red squiggles, no pasting stack traces out of a GUI.

Once build, test, and run are all commands, the IDE mostly stays closed. The agent lives in the terminal, and so do I. This works the same whether you write Swift, Go, or TypeScript. If your build hides behind a button only a person can click, your agent is stuck waiting on that person every loop.

Not married to the harness

I could move off Claude Code in an afternoon. Everything I've taught the agent, the conventions, the build commands, the gotchas worth keeping, lives in one file. Claude Code reads it as CLAUDE.md. Codex reads it as AGENTS.md. They're the same file behind a symlink, so both tools get the same brain. My skills sit in one folder wired into wherever each tool goes looking for them.

So the switching cost stays near zero. The day Codex or whatever comes after it clearly pulls ahead, I change which command I type and bring the whole setup with me.

The only piece of all this that can't run in parallel is me.