One Human, Four Agents: A Practical Multi-Agent Parallel Development Workflow for Vibe Projects

You know the feeling: you fire up a coding agent to build a login page, then sit there scrolling your phone while it runs. Fifteen minutes later it says "done," you review it, the button color is wrong, you ask for a fix, and wait another ten minutes. The morning is gone, you finished "one thing," and 80% of the time was spent waiting.

That's not the agent being slow — that's you using it as a typist. The real way to use agents is as employees. And you can hire several employees at once.

Here's the core claim up front: one human directing 2 to 4 coding agents working in parallel is the cheapest productivity leverage a solo developer can get in 2026. It's also the easiest thing to get catastrophically wrong: four agents editing your code at once, with no system, is four times the disaster. This guide is the system — when parallel makes sense, how to split tasks, how to isolate, how to merge, how to control cost — plus a list of mistakes paid for with real money.

This isn't a new idea. Simon Willison wrote Embracing the parallel coding agent lifestyle (simonwillison.net/2025/Oct/5/parallel-coding-agents/) back in October 2025, about juggling three or four agents at once. And Theo Browne, while porting the TypeScript compiler to Rust as ts-rust in October 2026, put it bluntly: his job wasn't writing code, it was "managing a team" — he ran a dozen-plus agent threads and triaged them every morning like an email inbox. What follows turns that style of working into steps anyone can copy.

Cold water first: when parallel pays off, and when it's not worth the hassle

Parallel isn't a silver bullet. It works in exactly one situation: the work splits into independent chunks. If your task is "fix this bug in this function," don't parallelize — one agent finishes it in five minutes, and spinning up four is performance art.

Three signals that parallel is worth it. First, you have a feature list with weak dependencies between items: login page, landing page, email templates, admin panel — the classic parallelizable combo. Second, you're waiting on one agent running a long task (say, "get test coverage to 80%") and your hands are free, so you might as well start a second one. Third, "writing code" can be separated from "writing tests" and "writing docs" — the latter two barely need you at all, and their output is directly usable.

Three signals to stay serial. First, tightly coupled tasks: A's output is B's input, like "finalize the schema, then write the API." Don't force that into parallel — having agent A wait on agent B's API is how you wait until the end of time. Second, you don't know what you want yet: four agents on a fuzzy spec just manufactures garbage four times faster. Third, your own mental bandwidth is tapped out — that's a hard ceiling: the number of parallel agents equals the number of diffs you can actually review. More than that, and unreviewed parallel work is the same as unreviewed work.

One line: parallel requires "independent tasks," not "lots of agents." Split the work first, then spin up agents. Don't reverse the order.

Splitting tasks: three axes cover 90% of cases

There are three axes for splitting:

By module (the most common). Auth module, payments module, notifications module — one agent per module. One requirement: modules talk through explicit interfaces, and the interfaces get frozen first. Parallelizing before the interfaces are frozen is like four chefs cooking one banquet with no recipes.

By layer. One agent on frontend, one on backend. Fits projects with a clean frontend/backend boundary, like Next.js plus a standalone API service. Layers need frozen contracts too: API paths, params, response shapes, written into a file and committed to main, so every agent develops against the same thing.

By nature (best bang for buck). One agent writes feature code, one writes tests, one writes docs. The test and doc agents barely need to talk to you, and their output is immediately useful. People hesitate — "tests have to wait for the code" — but they don't: with the interface contract in hand, the test agent writes against mocks first, then runs everything again once the code lands.

The axes stack: "frontend agent A builds the login UI, agent B writes integration tests for the login API." Before splitting, spend five minutes on paper: draw each task as a card, connect the ones with dependencies. Only cards with no incoming edges can start in parallel; the rest queue up behind. That five minutes saves four hours of rework later. Don't skip it.

Isolation: git worktree, one branch per agent, nobody steps on anybody

Four agents in one directory ends with overwritten files, deleted files, and git history that's pure mush. Isolation is the foundation of parallel work, and it has three layers — all mandatory.

Layer one: git worktree — one working directory and one branch per agent

This is the single most important command in the whole workflow. Memorize it:

# Give agent-a its own workspace on branch feature/auth-ui
git worktree add ../proj-agent-a -b feature/auth-ui

# agent-b: payments module
git worktree add ../proj-agent-b -b feature/payment

# agent-c: email templates
git worktree add ../proj-agent-c -b feature/email-template

# List all workspaces
git worktree list

# Cleanup after merge: remove the workspace
git worktree remove ../proj-agent-a
git worktree prune

The iron rule: an agent only works inside its own worktree, pushes only to its own branch, and never touches main directly. Merging is your job, and the next section explains why that power can't be delegated.

Layer two: runtime isolation — separate ports and databases

Four agents starting dev servers at once means port collisions — a classic wreck. The fix is boring but works: separate environment variables per worktree.

# ../proj-agent-a/.env.local
PORT=3101
DATABASE_URL=postgresql://localhost:5432/proj_a

# ../proj-agent-b/.env.local
PORT=3102
DATABASE_URL=postgresql://localhost:5432/proj_b

# ../proj-agent-c/.env.local
PORT=3103
DATABASE_URL=postgresql://localhost:5432/proj_c

Databases: one database per agent is best (creating a Postgres database is a single CREATE DATABASE command), or at minimum table-name prefixes. Don't let agent A's migration nuke agent B's data — that kind of accident costs ten times more to fix than the code was worth. Same for shared services like Redis: split db indexes by agent number and write it into the kickoff brief.

Layer three: file-level conventions — restricted zones in writing

Spell out in the kickoff brief which directories belong to the agent and which are off-limits. schema.prisma and the migrations directory, for example: unless you're the one agent authorized to touch the schema, you don't go near them. Dependency files (package.json, pnpm-lock.yaml) are restricted by default too — real need means @-mentioning you for approval first.

The kickoff brief: four things every agent must receive before starting

Agents aren't people; they don't "get the hint." Vague instructions mean improvisation, and improvisation means incidents. So every agent gets a written kickoff brief before starting. The cheapest way: put it in each worktree's AGENTS.md (or CLAUDE.md, whichever your tooling respects), plus a task-specific prompt. Four components, none optional: goal, boundaries, acceptance criteria, prohibitions.

Copy this template:

# Kickoff brief: login page UI (agent-a)

## Goal
Build the login page UI under app/[locale]/login with email + password login.
Design reference: design/login.png (exported from Figma, match it).

## Boundaries
- Only touch app/[locale]/login/ and components/auth/
- Do NOT modify prisma/schema.prisma or migrations/
- Do NOT add npm dependencies; ask me (@me) before using a new library

## Acceptance criteria
- [ ] pnpm build passes, pnpm lint has zero errors
- [ ] No horizontal scrolling at 375px mobile width
- [ ] Failed logins show a Chinese error message, never alert()
- [ ] pnpm test login — all related cases green

## Prohibitions
- Do NOT refactor code outside the login page; "drive-by cleanup" is the most expensive kind
- Never put secrets or tokens in code or git commits
- If unsure, stop and ask — don't guess; a wrong guess costs ten times more than a question

## Report format
When done, tell me in 5 lines max: which files changed, how you verified, what risks remain.

Kickoff brief quality = parallel quality ceiling. The more specific it is, the less room for improvisation, and the lighter your review load. Ten minutes writing the brief saves an hour of rework arguments later. Do the math: the 10 minutes you save by skimping become an hour of agent improvisation.

Merging: you are the only merger, and nobody routes around you

The most dangerous illusion in parallel development is "the agent says it's done = it's ready to merge." No. You are the only merger on this pipeline. Every branch goes through your review before entering main. No exceptions. Theo Browne's "let the agent merge itself" setup is a privilege he earned after 150 PRs with 2 regressions — privileges are the destination, not the starting point. Until you're at his scale, be the gatekeeper.

Diff review checklist: run through it before every merge

• Do the interface contracts line up? Do its changed API signatures match what the other agents depend on? This is the most common cross-agent accident: A changes a response field, B still parses the old one, and the merge ships a 500 to production.
• Migration conflicts: did two agents each generate a migration? Hand-merge them into one, ordered by timestamp, then merge.
• Reinvented wheels: did agent B write yet another almost-copy of a function that already exists in utils? Agents love doing this — delete it in review and tell it to search first next time.
• New dependencies: what got added to package.json? Ask "do we really need this" for every single one — agents add dependencies even more eagerly than you do.
• Are the tests really green or fake green: run them yourself; don't trust the agent's "tests pass." Re-running its verification steps takes two minutes; trusting it once can cost two hours.

Conflict arbitration in three steps

Two branches touched the same spot — don't panic, three steps: look, decide, lock. Look: git diff both branches and mark the conflict points. Decide: interface-level conflicts defer to "the interface doc we froze first" — whoever deviated, fixes it; implementation-level conflicts go to whichever is simpler. Lock: run the full test suite right after merging — green means done, red means revert. Protect main's cleanliness first, fix the branch slowly.

One or two fixed "merge windows" per day

Say, once before lunch and once before dinner — batch-process every branch waiting to merge. Let the agents run on their own the rest of the time; don't merge them one by one as they finish — context-switching burns your own brain. Outside merge windows, your job is exactly two things: writing kickoff briefs, and answering agents' questions. Keep that rhythm and managing four agents won't wear you out.

Cost and control: parallel = spend × N, set the budget before you start

This is the most practical section. Four agents means your token bill runs at 4× speed. Theo Browne's ts-rust port burned tokens worth on the order of $400,000 at API prices — he paid a few hundred dollars on subscriptions, which is exactly why subscriptions are the parallel player's moat, and why he keeps several Claude accounts running. If you don't have his scale, build your own guardrails:

First, per-run caps. Give every agent a per-run cost or token ceiling. Use your tool's budget parameter if it has one; if not, wrap it in a script that tracks usage and kills the run when it exceeds the cap. An agent with no cap is a credit card with no limit — you only feel it when the bill arrives.

Second, scheduled kill patrols. Check on all four agents every 30 minutes. Don't read their "thinking" — look at output only: did files change, did tests advance, is it waiting on you? A minimal patrol script on a timer works:

# Patrol script: list each agent session's runtime and last-output time
# Replace the agent-cli part with whatever your tooling actually uses
for s in agent-a agent-b agent-c agent-d; do
  echo "=== $s ==="
  agent-cli session info "$s" --show-runtime --show-last-output-time
done

# Run every 30 minutes via cron, log the output
# */30 * * * * /home/you/bin/agent-patrol.sh >> /home/you/logs/patrol.log

Third, zombie agent detection and termination. The rule is simple: an agent with zero file output and zero questions to you for 30 minutes is a zombie. Don't get sentimental — kill the session, delete the branch, start fresh. A zombie's biggest cost isn't the tokens it burns; it's the task slot it occupies while you believe "someone's on it" — by the time you notice it produced nothing all afternoon, the day is gone. Killing zombies fast and without mercy is basic management craft.

Fourth, a daily spending ceiling. Say $20 a day (converted to your subscription or usage plan) — hit it and stop, continue tomorrow. Parallel's biggest temptation is "the machines are running anyway," but every second they run is money. Log the daily spend; after a week you'll know exactly which agents earn their keep and which tasks aren't worth parallelizing.

One line: do the math before you parallelize — parallel you can't account for is just burning money.

Anti-pattern list: every one of these was paid for in real money

• Two agents editing the schema at once. A adds a field, B drops a field, migrations fight, the database won't start. Fix: the schema is an "exclusive resource" — one agent touches it at a time, or you edit it yourself. That's why the restricted-zones clause exists in layer three of isolation.
• Agent A waiting on agent B's API until the end of time. Tell A to "integrate once B's login API is ready" and A will ask you "is B done yet" every ten minutes. Fix: freeze the interface into a file first, A develops against mocks, integration happens in the merge window. Never let runtime dependencies form between agents.
• Rubber-stamp reviews merging bugs into main. Review is the most tiring part of parallel work, and tired reviewers go "looks fine, merge." Fix: the merge checklist is a checklist, not a suggestion; if you're tired, rest — main's cleanliness matters ten thousand times more than merging one extra branch today.
• Agents "helping" each other. Unsupervised, agent A will wander into agent B's directory to "fix a bug real quick," and then both branches are wrecked and the git history is unreadable. Fix: hard-code the working directory in the kickoff brief; one boundary violation gets a warning — treat it like a red line in code review.
• Kickoff briefs so vague that four agents produce four interpretations. "Make a nice login page" gets you four login pages in four styles. Fix: acceptance criteria must be checkable — commands, pixels, copy. Translate every adjective into a number. "Nice" = matches design/login.png pixel for pixel, zero color deviation.

Today's startup SOP: the minimal usable process

Everything above, compressed into a checklist you can copy every day:

[15 minutes before starting]
1. List today's task cards, draw the dependency lines, pick 2-4 with no dependencies
2. Freeze interfaces first: shared types / API contracts go into files committed to main
3. One git worktree per agent, branch names feature/<task>-<agent-name>

[Starting]
4. Drop a kickoff brief in each worktree (AGENTS.md + task prompt)
5. Separate ports and databases via env vars; start all dev servers and confirm no collisions
6. Launch agents with: "report in the required format when done; ask when unsure"

[In progress]
7. Patrol every 30 minutes: output only, never the "thinking process"
8. Zombie agents (30 min, no output, no questions) get killed and restarted — no dithering

[Merge window (1-2x daily)]
9. Run every branch through the diff review checklist (contracts/migrations/duplication/deps/real-green)
10. Arbitrate conflicts in three steps: interface doc wins, simpler implementation wins
11. Full test suite after merging: green means done, red means revert — main stays clean first
12. git worktree remove to clean up merged workspaces

[Wrapping up]
13. Check today's token bill and log it
14. Unfinished branches stay for tomorrow — a branch is your save file

One honest closing line: multi-agent parallel work turns "you write code" into "you manage a four-person team." And managing a team — splitting tasks, freezing interfaces, doing reviews, controlling budget — is a different muscle from writing code. Simon Willison and Theo Browne make it look easy not because they write great prompts, but because they figured out early: in the agent era, your core output isn't code, it's judgment. Let agents write the code; keep the judgment for yourself. That's the real division of labor in "one human, four agents."