Running Multiple AI Coding Agents in Parallel: A Solo Developer’s macOS Workflow

For most of 2025, “using an AI coding agent” meant opening one terminal, typing a prompt, and watching a single session grind through a task. In 2026, that model is already the bottleneck. A single Claude Code or Codex CLI session spends most of its wall-clock time thinking, reading files, and running tests — and during all of that, you are just watching. If you are a solo developer or a one-person software business, the real leverage is not a faster agent. It is running three to six agents at once and becoming the person who routes work between them.

This post is a practical account of how that actually works on macOS: what to parallelize, what breaks, and how to keep six terminals from turning into chaos.

Why Parallel Agents Beat One Fast Agent

The economics are simple. An agent task — “add pagination to the admin list view, with tests” — typically takes 4 to 12 minutes end to end. Of that, your actual attention is needed for maybe 60 seconds: approving a plan, answering one ambiguous question, reviewing the diff. The other 90% is dead time.

Run four agents and that dead time overlaps. Your attention becomes the scarce resource instead of the model’s throughput, which is exactly the trade you want. In my own week-to-week work on a WordPress automation stack, moving from one session to four roughly tripled the number of shipped changes — not four times, because review and merge conflicts eat some of the gain.

Note the last row. Parallelism has a ceiling, and for one human that ceiling sits somewhere around five or six concurrent agents. Past that, you stop reviewing properly and start rubber-stamping, which is how bad code enters a codebase faster than ever before.

The Hardware Reality on macOS

Each CLI agent session is comparatively light — the model runs remotely — but the surrounding work is not. Six agents means six Node processes, six language servers, six test runners, and often six copies of your repo on disk. Unified memory is the first thing to run out.

• 16 GB Macs: comfortable at 2–3 agents. Expect swapping if one of them runs a build.
• 32 GB: the practical sweet spot for 4–6 agents with a browser and editor open.
• 64 GB+: only necessary if agents are running containers, local models, or heavy test suites.

Disk matters more than people expect. Six git worktrees of a mid-size repo, each with its own node_modules, will happily consume 40 GB. An external SSD for worktrees and build caches keeps your boot volume from filling up mid-session — a USB-C External SSD on Amazon Japan → is the cheapest fix here.

The other underrated purchase is screen real estate. Tiling six terminals on a 13-inch laptop display is genuinely impossible; you end up tab-switching and losing track of which agent asked you a question. A 34-inch Ultrawide Monitor on Amazon Japan → fits three full-width terminal columns side by side, which maps almost perfectly onto a three-to-six agent workflow. If you work from a laptop, a USB-C Docking Station on Amazon Japan → removes the friction of reconnecting every morning.

Rule One: One Agent, One Worktree

This is the single most important operational rule, and almost everyone learns it the hard way. If two agents edit the same working directory simultaneously, they will overwrite each other’s changes, and neither will notice. The fix is git worktree:

• git worktree add ../wt-pagination feature/pagination
• git worktree add ../wt-auth-fix fix/auth-redirect
• git worktree add ../wt-docs chore/docs-refresh

Each agent gets its own directory, its own branch, and its own file locks. They cannot collide. When one finishes, you review the diff, merge, and git worktree remove the directory. Claude Code has native worktree support that automates this, and it is worth using rather than managing the directories by hand.

The cost is disk space and setup time — each worktree needs its own dependency install. A shared package cache (pnpm’s content-addressable store, or a shared Yarn cache) cuts this dramatically.

Rule Two: Partition Tasks So They Don’t Touch

Worktrees prevent file-level collisions but not logical collisions. Two agents refactoring the same module on different branches will both succeed, and then you will spend 40 minutes resolving a merge conflict that erases most of the parallelism gain.

Good parallel task sets look like this:

• Agent 1: backend API endpoint — touches src/api/
• Agent 2: frontend component — touches src/components/
• Agent 3: test coverage for an untouched legacy module
• Agent 4: documentation and README updates
• Agent 5: dependency upgrades and CI config

Bad parallel task sets share a module, share a schema, or depend on each other’s output. If task B needs task A’s interface, run them sequentially — pretending otherwise just moves the work to merge time.

Rule Three: Mix Your Models

Running both Claude Code and Codex CLI side by side is not redundancy; it is a review mechanism. My global config has a standing rule: anything important gets drafted by one and critiqued by the other. In practice:

• Claude Code drafts the implementation in its worktree.
• codex exec --sandbox read-only "Review this design as a skeptical senior engineer; list factual errors, gaps, and weak reasoning" runs against the diff.
• You arbitrate. The second model catches roughly one real issue in three reviews — not a huge hit rate, but the issues it catches are the ones you would have shipped.

Use codex exec, not bare codex: the interactive TUI will hang a scripted pipeline forever. Read-only sandboxing by default means a review agent cannot accidentally “helpfully” rewrite your branch.

Rule Four: Make Permissions Decisions Once

The fastest way to destroy parallel throughput is permission prompts. Six agents each stopping to ask “may I run npm test?” turns you into a full-time approval clerk. Configure an allowlist in .claude/settings.json for the read-only and routine commands you always approve — git status, git diff, test runners, linters — and reserve real prompts for writes outside the worktree, network calls, and anything destructive.

What you should not do is disable permissions globally across all six sessions. An agent that misreads an instruction and runs rm -rf in a worktree is recoverable; the same command one directory up is not.

Rule Five: Batch Your Review Passes

Context switching is what actually exhausts you, not the number of agents. The workflow that holds up over a full day looks less like monitoring and more like a shift pattern:

• Dispatch window (10 min): write clear, self-contained prompts for all agents. Over-specify. An agent that has to ask a clarifying question has stalled.
• Deep work window (20–30 min): do your own work. Ignore the terminals.
• Review window (15 min): sweep every session, answer questions, review diffs, merge what is done, dispatch the next batch.

Two or three of those cycles is a productive day. Watching agents type in real time is not work, and it feels far busier than it is.

Where It Actually Breaks

Honest accounting of the failure modes, because they are real:

Rate limits deserve emphasis. Weekly quotas that felt generous with one session evaporate with six. Budget for it, stagger long-running tasks, and keep a second provider configured so a limit on one does not stop the day.

The Missing Piece: Visual Tile Management

Everything above is process. The unsolved practical problem is looking at six agents at once. Terminal tabs hide state — an agent that finished eight minutes ago looks identical to one still working until you switch to it. iTerm2 panes and tmux help, but neither knows which pane is blocked on a question and which is running fine.

This is the gap worth tooling around: a single view where each agent is a tile showing its current state, its last output, and whether it needs you. If you want to go deeper on terminal ergonomics, a good Mechanical Keyboard for programmers on Amazon Japan → and a solid reference like The Pragmatic Programmer on Amazon Japan → remain worth the shelf space — the fundamentals of small, reversible, reviewable changes matter more with agents, not less.

Start Small

If you are running one agent today, do not jump to six. Add a second one tomorrow with its own worktree and a task that cannot possibly collide with the first. Get comfortable with the review rhythm. Add a third the week after. The constraint you are managing is your own attention, and the only way to find its limit is to approach it gradually.

For managing multiple agent sessions as visual tiles, see Agent Desk — it gives each running agent its own tile so you can see at a glance which one needs you.

📝 More in-depth guides available on note.com: Follow @ksta877 on note.com for deep-dive OSS reviews, tutorials, and premium technical articles.

This post contains affiliate links. As an Amazon Associate I earn from qualifying purchases.