Shipping a Feature with Parallel Claude Code Agents

Most writing about parallel agents stays abstract — orchestrators, subagents, token budgets. What teams actually want is a concrete story: here is a real feature, here is how it got decomposed, here is what each agent did, here is what went wrong, and here is the shipped result. So this post is a walkthrough. We will take one ordinary feature request and follow it all the way through the redesigned Claude Code desktop, where several agents run in parallel against the same repository, to a merged pull request.

The feature is deliberately mundane because mundane is where most engineering time actually goes: add a customer data export to a SaaS app. Users want to download their orders, invoices, and activity as a CSV. It touches the backend, the frontend, the data layer, and the docs. It is exactly the kind of multi-surface task that parallel agents are good at — and exactly the kind that goes sideways if you decompose it carelessly.

Key takeaways

• A multi-surface feature decomposes cleanly into backend, frontend, data-export logic, and docs — four agents that barely overlap.
• The interface contract written before launch is what lets agents build against each other without waiting.
• Expect one agent to hit a real blocker; the walkthrough shows how to unstick it without derailing the others.
• Verification happens in parallel via tests, then a focused human review of only the risky diffs.
• End to end, the human spends most time on specs and review, almost none on implementation.

Step one: decompose before you launch anything

The instinct to open Claude Code and start prompting is exactly what to resist. The first ten minutes are spent on paper, deciding the seams. The export feature splits into four pieces that touch mostly separate files: a backend endpoint that streams the CSV, the export-generation logic that turns records into rows, a frontend button and download flow, and user-facing docs. The only shared surface is the contract between the endpoint and the generation logic — and that is exactly what to nail down first.

The contract is one paragraph: the endpoint calls generateExport(userId, format), which returns a readable stream of CSV bytes; errors throw a typed ExportError. With that written down, the backend agent and the export-logic agent can both work immediately, each assuming the other's half exists. No waiting, no collision.

flowchart TD
  A["Feature: customer data export"] --> B["Write interface contract"]
  B --> C["Agent 1: backend endpoint"]
  B --> D["Agent 2: export-generation logic"]
  B --> E["Agent 3: frontend button + download"]
  B --> F["Agent 4: docs"]
  C --> G{"All tests pass?"}
  D --> G
  E --> G
  F --> G
  G -->|Yes| H["Review risky diffs & merge"]

Step two: launch the agents with scoped specs

Each agent gets a spec that names the files it owns and the files it must not touch. The backend agent owns the route handler and its test. The export-logic agent owns the generation module and its test. The frontend agent owns the component and its test. The docs agent owns one markdown file. Because ownership is disjoint, the four can run truly in parallel in separate worktrees without ever editing the same line.

Here is the export-logic agent's spec, the kind of thing that takes two minutes to write and saves an hour of confusion:

## Agent: export-generation
Goal: Implement generateExport(userId, format) returning a CSV stream.
Files you own: src/export/generate.ts, tests/export/generate.test.ts
Do NOT touch: src/routes/*, src/components/*
Contract: pull data via existing repo functions getOrders(userId),
  getInvoices(userId). Throw ExportError on unknown format.
Acceptance: test covers empty data, multi-row data, and bad format.
Format: RFC-4180 CSV, header row required.

The Contract line points the agent at existing data-access functions so it does not reinvent them or wander into the data layer another part of the system owns. The acceptance criteria double as the agent's definition of done — it writes the test, makes it pass, and stops.

Step three: handle the inevitable blocker

In a realistic run, one agent hits something the spec did not anticipate. Here, the export-logic agent discovers that getInvoices returns timestamps in UTC while the rest of the app displays local time, and it is not sure which to put in the CSV. A well-behaved agent does not guess and barrel ahead — it surfaces the blocker and pauses.

This is where the human earns their keep. You make a product call — export in UTC with an explicit column header — and feed it back as one line. The agent resumes. Crucially, the other three agents never stopped; the blocker was contained to one stream. That containment is the whole reason parallel beats serial: a stall in one lane does not freeze the highway.

The lesson worth internalizing is that good specs reduce blockers but never eliminate them. Your job is to keep blocker resolution fast — a quick decision, one line back — so a stuck agent costs minutes, not the afternoon.

Step four: verify in parallel, review what matters

When the agents finish, you do not read four diffs cover to cover. You let the test suite run across all four worktrees first; that is the fast, parallel verification pass. Three agents come back green. The frontend agent's tests pass but you scan its diff anyway because UI download flows have browser quirks that unit tests miss — and indeed it forgot to revoke the object URL after download, a small leak you flag and it fixes in one turn.

This is the verification discipline that makes parallel agents pay off: trust automated signals for the routine, reserve human attention for the genuinely risky surfaces. Reading all four diffs with equal care would make you the serial bottleneck and erase the time the parallelism bought.

Before merging, one more step that teams skip at their peril: an integration test that exercises the whole export path end to end. Four green unit suites prove each piece works in isolation; they do not prove the pieces fit together. In this run, the integration test caught a real mismatch — the backend agent set the HTTP response content type to text/csv, but the frontend agent's download flow expected application/octet-stream to force a download rather than render in-browser. Each agent was individually correct against its own spec; the seam between them was wrong. That is the classic parallel-agent failure, and only a test that crosses the seam finds it. The fix was one line, but without the integration test it would have shipped and surfaced as a confusing bug report from a real user.

Common pitfalls in an end-to-end run

• Skipping the contract. Without the written interface, the backend and export agents each invent a different function signature and you spend the merge reconciling them. Write the contract first, always.
• Overlapping file ownership. If two agents can edit the same module, you will get a conflict. Make ownership disjoint even if it means a slightly awkward seam.
• Letting a blocker stall everything. Resolve blockers fast and keep them contained to one agent. Do not pause the whole run to think about one lane's question.
• Uniform review. Reading every diff with maximum care defeats the purpose. Triage: deep review for risky surfaces, trust tests for the rest.
• No integration test. Four green unit suites do not prove the pieces fit. Add one end-to-end test that exercises the full export path before merging.

Run your own feature in five steps

1. Spend ten minutes decomposing the feature into surfaces that touch mostly separate files.
2. Write the interface contract for any seam where two agents meet.
3. Launch one agent per surface with a scoped spec naming owned and forbidden files.
4. Resolve blockers fast and keep them contained to the affected agent.
5. Verify with tests in parallel, deep-review only the risky diffs, add one integration test, then merge.

Serial versus parallel on this feature

Frequently asked questions

How do you decide where to split a feature?

Split along surfaces that touch separate files — backend, frontend, data logic, docs. The goal is disjoint file ownership so agents never edit the same line. Where two surfaces meet, write an interface contract instead of merging their work.

What happens when one agent gets stuck?

It should surface the blocker and pause rather than guess. You make the call and feed it back in one line. Because each agent runs in its own lane, the others keep working, so a single blocker costs minutes rather than freezing the whole run.

Do you review every agent's output equally?

No. Let tests verify all worktrees in parallel, then deep-review only the genuinely risky diffs, like UI flows or anything touching money or auth. Reviewing everything with equal care would make you the serial bottleneck.

How long does a feature like this take?

The implementation runs concurrently, so wall-clock time is closer to the longest single piece than the sum of all pieces. Most of the human's time goes to the upfront decomposition and the final review, with very little spent typing code.

From shipped features to answered calls

The same decompose-contract-verify loop that ships a feature can run your front line. CallSphere applies these agentic patterns to voice and chat, with coordinated agents that handle every call and message and book real work. See it at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.