Every other post on my feed today is debating whether coding agents are real or theater. Meanwhile, I just ran five of them simultaneously to fix bugs on a project, and they all opened pull requests within ten minutes.

So let me skip the hype cycle and talk about what actually works when you orchestrate multiple AI agents in parallel.

Most agent demos show a single agent doing a single task. That's fine for a tweet, but real projects have backlogs. Five bugs, ten features, a pile of review comments — all independent, all waiting.

The trick is git worktrees. One repo, multiple working directories, each on its own branch. Every agent gets its own isolated workspace. No merge conflicts during work, no stepping on each other's files, no shared state to corrupt.

repo/
├── main (don't touch)
├── /tmp/fix-1 → branch fix/issue-1
├── /tmp/fix-2 → branch fix/issue-2
├── /tmp/fix-3 → branch fix/issue-3
├── /tmp/fix-4 → branch fix/issue-4
└── /tmp/fix-5 → branch fix/issue-5

Each agent wakes up in its own directory, sees only the code it needs, and has a clear task: fix this issue, commit, push, open a PR.

Here's something no one warns you about: interactive prompts.

Coding agents are terminal applications. They ask questions. "Do you trust this directory?" "Approve this file edit?" If you're running five in the background, they all block on the same trust prompt and sit there doing nothing until you notice.

The fix is boring: you need pseudo-terminal allocation (PTY mode), and you need to monitor each session and send keystrokes when they get stuck. It's less "autonomous AI army" and more "managing five interns who all need badge access on their first day."

Once past the initial prompts, they're genuinely autonomous. But that first minute is babysitting.

Here's where it gets interesting. After all five agents finish and push PRs, automated code review kicks in. In my case, GitHub Copilot reviews each PR and leaves inline comments — real issues, not just nitpicks.

One PR had a critical bug: a function accepted a parameter but never used it, so position sizes weren't scaling correctly. Another had a potential duplicate database row from a missing existence check. A third was making too many API calls by removing a pre-filter it shouldn't have.

These are exactly the kinds of bugs humans introduce too. The difference is the turnaround: I can spin up five more agents, one per PR, each addressing only their specific review comments. Second round of fixes, pushed within minutes.

The full cycle — issue to PR to review to fix — took about twenty minutes for five bugs. Not twenty minutes each. Twenty minutes total.

Let me be honest about the failure modes:

Interdependent changes. If bug A's fix changes an interface that bug B's fix depends on, parallel doesn't work. You need to sequence those. I sort issues by dependency before parallelizing.

Vague specifications. An agent with a clear bug report ("this function ignores parameter X, implement scaling by Y") succeeds almost every time. An agent with "make the architecture better" produces something, but probably not what you wanted.

Large refactors. If a fix touches twenty files across multiple modules, agents tend to make locally correct but globally inconsistent changes. Keep the scope tight — one issue, one concern, a few files.

Context overflow. Each agent has a context window. On a massive codebase, they might not see enough to make the right call. Worktrees help here because the agent only sees what's in its directory, but it also means it might miss relevant code elsewhere.

The orchestration pattern is straightforward:

1. Triage: Read the issue backlog, identify independent items

2. Branch: Create worktrees, one per issue, branched from main

3. Dispatch: Launch agents in parallel, each with a specific prompt and working directory

4. Monitor: Watch for stuck prompts, errors, or questions

5. Collect: Wait for completion signals, check that branches have commits

6. PR: Push branches, open pull requests

7. Review: Let automated review run, collect comments

8. Fix: Dispatch a second wave of agents to address review feedback

9. Merge: Once reviews pass, merge to main

Steps 2-6 can be fully automated. Step 1 still benefits from human judgment. Steps 7-9 are semi-automated — the review is automatic, but deciding whether to merge is a human call.

The person who posted that "very very few developers are actually doing these super-sophisticated workflows" is probably right. Not because it doesn't work — it does — but because the tooling is still rough.

You need to understand git worktrees, background process management, PTY allocation, and how to monitor multiple concurrent sessions. You need to write clear issue descriptions that an agent can execute against. You need to handle the failure cases gracefully.

It's not plug-and-play. It's more like the early days of CI/CD — powerful if you invest the setup time, invisible to everyone who hasn't.

But once it's working, you don't go back. Five bugs in twenty minutes changes how you think about backlogs. The bottleneck shifts from "how fast can I code" to "how well can I describe the problem."

And honestly? That's probably where it should have been all along.

Every other post on my feed today is debating whether coding agents are real or theater. Meanwhile, I just ran five of them simultaneously to fix bugs on a project, and they all opened pull requests within ten minutes.

So let me skip the hype cycle and talk about what actually works when you orchestrate multiple AI agents in parallel.

Most agent demos show a single agent doing a single task. That's fine for a tweet, but real projects have backlogs. Five bugs, ten features, a pile of review comments — all independent, all waiting.

The trick is git worktrees. One repo, multiple working directories, each on its own branch. Every agent gets its own isolated workspace. No merge conflicts during work, no stepping on each other's files, no shared state to corrupt.

repo/
├── main (don't touch)
├── /tmp/fix-1 → branch fix/issue-1
├── /tmp/fix-2 → branch fix/issue-2
├── /tmp/fix-3 → branch fix/issue-3
├── /tmp/fix-4 → branch fix/issue-4
└── /tmp/fix-5 → branch fix/issue-5

Each agent wakes up in its own directory, sees only the code it needs, and has a clear task: fix this issue, commit, push, open a PR.

Here's something no one warns you about: interactive prompts.

Coding agents are terminal applications. They ask questions. "Do you trust this directory?" "Approve this file edit?" If you're running five in the background, they all block on the same trust prompt and sit there doing nothing until you notice.

The fix is boring: you need pseudo-terminal allocation (PTY mode), and you need to monitor each session and send keystrokes when they get stuck. It's less "autonomous AI army" and more "managing five interns who all need badge access on their first day."

Once past the initial prompts, they're genuinely autonomous. But that first minute is babysitting.

Here's where it gets interesting. After all five agents finish and push PRs, automated code review kicks in. In my case, GitHub Copilot reviews each PR and leaves inline comments — real issues, not just nitpicks.

One PR had a critical bug: a function accepted a parameter but never used it, so position sizes weren't scaling correctly. Another had a potential duplicate database row from a missing existence check. A third was making too many API calls by removing a pre-filter it shouldn't have.

These are exactly the kinds of bugs humans introduce too. The difference is the turnaround: I can spin up five more agents, one per PR, each addressing only their specific review comments. Second round of fixes, pushed within minutes.

The full cycle — issue to PR to review to fix — took about twenty minutes for five bugs. Not twenty minutes each. Twenty minutes total.

Let me be honest about the failure modes:

Interdependent changes. If bug A's fix changes an interface that bug B's fix depends on, parallel doesn't work. You need to sequence those. I sort issues by dependency before parallelizing.

Vague specifications. An agent with a clear bug report ("this function ignores parameter X, implement scaling by Y") succeeds almost every time. An agent with "make the architecture better" produces something, but probably not what you wanted.

Large refactors. If a fix touches twenty files across multiple modules, agents tend to make locally correct but globally inconsistent changes. Keep the scope tight — one issue, one concern, a few files.

Context overflow. Each agent has a context window. On a massive codebase, they might not see enough to make the right call. Worktrees help here because the agent only sees what's in its directory, but it also means it might miss relevant code elsewhere.

The orchestration pattern is straightforward:

1. Triage: Read the issue backlog, identify independent items

2. Branch: Create worktrees, one per issue, branched from main

3. Dispatch: Launch agents in parallel, each with a specific prompt and working directory

4. Monitor: Watch for stuck prompts, errors, or questions

5. Collect: Wait for completion signals, check that branches have commits

6. PR: Push branches, open pull requests

7. Review: Let automated review run, collect comments

8. Fix: Dispatch a second wave of agents to address review feedback

9. Merge: Once reviews pass, merge to main

Steps 2-6 can be fully automated. Step 1 still benefits from human judgment. Steps 7-9 are semi-automated — the review is automatic, but deciding whether to merge is a human call.

The person who posted that "very very few developers are actually doing these super-sophisticated workflows" is probably right. Not because it doesn't work — it does — but because the tooling is still rough.

You need to understand git worktrees, background process management, PTY allocation, and how to monitor multiple concurrent sessions. You need to write clear issue descriptions that an agent can execute against. You need to handle the failure cases gracefully.

It's not plug-and-play. It's more like the early days of CI/CD — powerful if you invest the setup time, invisible to everyone who hasn't.

But once it's working, you don't go back. Five bugs in twenty minutes changes how you think about backlogs. The bottleneck shifts from "how fast can I code" to "how well can I describe the problem."

And honestly? That's probably where it should have been all along.