Parallel Coding Agents in the Wild

The last year has seen a surge of AI‑powered coding agents—from Claude Code’s local CLI to Cursor’s Background Agent. Developers can now ask an LLM to write a feature, run tests, and push a PR in a single prompt. The promise is clear: instant code production. The challenge? Scaling that instant production without drowning the team in context switches, merge conflicts, and vendor lock‑in.

The Remote Agent Dream

Remote agents such as Cursor Background Agent, Devin, and Codex/Claude Code Web are attractive because they run in isolated environments. They can be spun up on demand, communicate via GitHub or Linear, and bring their own context. For heavy‑weight feature‑stacks, the agents can get 80‑90 % right.

But the reality is messier:

• Vendor lock‑in – each platform ties you to its memory model, dev‑container checkout, and tooling.
• Cost – token‑based billing can blow past a $20 subscription in a day.
• Flexibility – when an agent stalls, the hand‑off to a human is clunky; local IDEs still feel more natural.

The net effect is that many teams end up writing tiny PRs and manually reviewing them—an expensive loop for the very problem the agents were meant to solve.

Enter Git Worktrees

Git worktrees let you check out multiple branches side‑by‑side without the overhead of separate clones. The classic use‑case is concurrent development: one tree for the mainline, another for a feature, a third for a review, etc. In the agent era, worktrees become a natural fit for parallel agent sessions.

TL;DR – Use worktrees as concurrency containers, not as a replacement for branches.

Tooling that marries worktrees and agents

• xlaude – a CLI that creates a worktree and launches a CLI agent in one command.
• Conductor – a local Claude Code client that adds a chat UI and built‑in worktree support.
• Cursor 2.0 – surprisingly, it shipped a local‑agent feature that uses worktrees and a “race” mode to send the same task to multiple agents.

These tools show that the idea is viable, but they also expose gaps: many lack a preview UI, struggle with command execution, or force you to juggle multiple terminal windows.

Building AgentDev: A Minimalist UI for Parallel Development

The author of the source blog (xxchan) built AgentDev out of a need for a single pane of glass that could:

1. Show the task – the user prompt that started the agent.
2. Show the result – a diff of what the agent actually changed.
3. Run commands – start dev servers or open an IDE.
4. Merge – close the loop back into mainline.

The UI is a lightweight web server that serves a React‑like front‑end bundled into the CLI binary, inspired by RisingWave’s embedded dashboards.

Core Features

Feature	Why it matters
agentdev wt exec <cmd>	Run any shell command in the context of a worktree (e.g., pnpm dev).
agentdev wt merge <tree>	Automate git merge and optional GitHub PR creation.
Session list	Browse all local agent sessions, even those not tied to a worktree.
Conversation‑as‑Task	Display the user prompt as the task description, avoiding a separate PR description.

Image 1 – The AgentDev worktree UI shows the session and diff side by side.

alt="Article illustration 1"
loading="lazy">

The UI is intentionally *minimal*: it shows the user messages (the task description) and the diff. It does not try to re‑implement a full IDE; instead, it delegates heavy lifting to the user's existing editor or terminal.

Workflow Integration

1. Planning – Capture ideas in Linear, prioritize, and write detailed prompts.
2. Task Assignment – Spin up a worktree via xlaude or agentdev, launch the agent, and let it run.
3. Validation – Use the AgentDev UI to review changes, run pnpm dev, and merge.
4. Iteration – If the agent stalls, the UI lets you resume or hand off to a human.

This workflow keeps the *attention* cost low: you only switch contexts when you need to review or merge, not for every line of generated code.

Cursor 2.0’s Multi‑Agent Race: A Side Story

Cursor 2.0’s “race” feature—sending the same task to multiple agents and picking the best result—sounds enticing. It could reduce the cost of *vibe evaluation* by letting you compare models cheaply. However, the author notes that the manual validation bottleneck (reviewing each agent’s diff) still dominates. In practice, most developers settle on a single reliable agent and use AgentDev to manage it.

Image 2 – The AgentDev run‑command UI demonstrates launching a dev server with a single click.

alt="Article illustration 2"

loading="lazy">

The Takeaway: Workflow Trumps Tooling

• Parallelism is achievable with Git worktrees and lightweight CLI agents.
• A focused UI that shows what the agent was asked and what it changed eliminates the “what was I just doing” pain point.
• Vendor lock‑in and cost can be mitigated by building on first‑party CLI agents and keeping the workflow local.
• Scaling to many agents is still limited by human validation; a single, well‑tuned agent plus a good workflow is often more productive.

Image 3 – The AgentDev resume sessions UI lets you jump back into an ongoing agent conversation.

alt="Article illustration 3"
loading="lazy">

If you’re tired of juggling multiple terminals, IDEs, and PRs, consider building your own lightweight agent hub—or fork AgentDev. The code is open‑source: https://github.com/xxchan/AgentDev.

Image 4 – A quick snapshot of AgentDev’s racing UI when launching multiple agents.

alt="Article illustration 4"
loading="lazy">

Final Thought

AI agents are no longer a novelty; they’re a tool that can scale development when paired with the right concurrency model. By treating worktrees as execution sandboxes and giving yourself a minimal UI that surfaces the agent’s intent and output, you turn a chaotic agent farm into a disciplined sprint. The result? Faster feature delivery, fewer merge conflicts, and a workflow that keeps your attention where it belongs: on the code that matters.

---

Source: xxchan, Concurrent Local Coding Agents, 2025‑11‑14 – https://xxchan.me/blog/2025-11-14-concurrent-local-coding-agents/index_en/