Parallel coding agents, one human: how to stop being the bottleneck

Starting four coding agents is the easy part. Then the first one asks to run the tests, the second has a question about the cache, the third says it's done, and the fourth has been waiting on you for ten minutes in a tab you haven't looked at. Run agents in parallel without a plan for your own attention, and it mostly means waiting in parallel.

You are the one part of the setup that doesn't scale, so the work is in asking less of yourself. Here's what does that, in plain tools first, then the same thing in a desktop app.

Where the waiting comes from

Four things, roughly in order of how much time they cost:

1. Routine permission prompts. The agent asks to run the test suite for the twentieth time.
2. Questions the brief should have answered. Which cache? Which branch? Keep the old API?
3. "Done" you can't trust. It says it's finished, and you have to read everything to know.
4. Not knowing who's waiting. An agent stopped for you, and nothing told you.

1. Answer the routine asks once

Every agent CLI lets you decide what it may run without asking: allow rules, an approval mode, or a permission mode per session. Use them for the commands you'd approve every time anyway, like the test runner, the linter and the type checker, and keep everything else asking.

• Allow the boring, repeatable commands: npm test, yarn lint, cargo check, a formatter.
• Keep asking for anything you can't undo: pushing, deploying, deleting, publishing, anything that reads a secret or calls a paid API.
• Prefer a rule for this session over a saved one while you're unsure. A rule saved in the project outlives the task, and you'll forget it's there.

Each allowed command is one fewer interruption, and across four agents in a day that adds up to hours.

2. Write the brief so the agent doesn't have to ask

Most questions an agent asks are decisions the brief left open. A few lines up front save a round trip later:

Goal: rate-limit POST /quotes to 60 requests a minute per customer.
Files: src/quotes/routes.ts, a new src/quotes/limit.ts, their tests.
Decided: in-memory token bucket, keyed by the x-customer-key header. No Redis.
Done means: yarn test src/quotes passes and yarn typecheck is clean.
If something is unclear: pick the simpler option, say which in your summary, and go on.

That last line matters most. "Pick the simpler option and tell me" turns a blocking question into a note you read later.

3. Make "done" something you can check

"Done" from an agent is a claim. Make it a claim you can check in a minute:

• Put the check in the brief. Name the command that must pass, and ask the agent to run it before it says it's finished.
• Ask for a short handback: the branch, its head commit, git diff --stat against the base, what it changed, and the commands it ran with their results.
• Read the stat before the diff. Twelve files changed when you expected two tells you where to look before you read a line.

A handback that points at a commit is reproducible. You review exactly what the agent checked, not whatever is in its folder at that moment.

4. One queue for everything waiting on you

Don't react to each agent as it pings. Work through them in rounds, in the order that unblocks the most work:

1. Blocked agents first. A question or a permission prompt is usually seconds to answer, and the agent is idle until you do.
2. Finished ones next. Check the handback, then review, merge or send it back.
3. Running ones last. Leave them alone unless something looks wrong.

For that you need one place that shows which agents are waiting and why, and a notification when one stops for you. With terminals, that means a notification hook per agent and a habit of checking every tab. Without it, an agent that stopped for you can sit idle all afternoon.

5. Keep each agent out of the others' way

Interruptions also come from agents colliding: two of them editing the same file, or one's test run picking up the other's half-finished change. Give each task its own git worktree and branch, and those collisions stop, along with the questions about them.

Doing this in Moontors

I build Moontors, a free desktop app for running Claude Code, Codex, Gemini CLI and Grok Build side by side, so take this part as the maker's view. It's built around that queue:

• One count in the header for every session waiting on you, for an answer to a question, a plan to approve or a permission. Click it to go to the next one. (The header)
• Each card shows why. A waiting session's card shows the question or plan it's asking, so you can see what it needs before you open it. (Questions and plans)
• Done stays blue until you've looked, and a pill in the header counts the finished sessions you haven't seen yet. Click it for the next one. (Done and notifications)
• Notifications on your computer when a session starts waiting for you, hits an error or finishes.
• A permission mode per session, from Manual to Bypass, and Allow for this session, which adds a rule for that session only. You can remove it in Configuration. (Permission modes)
• Answer from your phone. The phone app pairs with your computer to follow your sessions and answer their questions and permissions.

Whatever you run them in, the rule is the same: let the agents work in parallel, and keep yourself to one queue.

---

AI did the writing, I did the reading, and we both took credit.