Deep Dive: The Multi-Agent Loop

The Core Idea: Separating Thinking from Building

What Serial Development Looks Like

In a serial workflow, one agent handles everything in sequence: you think through a feature, hand it to Claude Code, wait for implementation, review the output, then move on to the next thing. That's how I've been working, and it's a natural starting point.

What I've noticed though is that it has a built-in idle problem: while Claude Code is implementing, I'm essentially waiting as a strategist. And when I'm thinking through the next feature, the building side is sitting unused. It's single-threaded not just technically but cognitively.

What Parallel Development Looks Like

The basic idea with multi-agent development is to decouple thinking from building -- running different kinds of work simultaneously rather than waiting on each one to finish before starting the next. The most natural first version of this, and the one I stumbled into with Qupi, is a simple two-agent split:

Why the Split Seems to Work

My sense is that these two kinds of work have different context needs and different rhythms. Mixing them in a single agent means constantly switching between 'should I build this?' and 'how do I build this?' -- which creates a kind of overhead that slows things down even if you can't always put your finger on why.

Keeping them separate lets each agent stay in its lane. The thinking agent holds product context -- what I've tried, what I've decided against, where the priorities are. The building agent stays focused on the codebase without being pulled into strategic questions it doesn't have enough context to answer well anyway.

There's also a practical upside I didn't anticipate: when Claude Code is off implementing something, there's natural downtime. That used to be dead time -- maybe I'd sneak in a Wordle -- but with the product advisor open in another window, that downtime becomes useful. By the time Code is done, I've already been thinking through what comes next.

A Real Example: How This Works with Qupi

The Setup

I have a Claude project configured as a product advisor for Qupi. It holds context about what the app does, who it is for, what has been built, and what the current open questions are. When I'm trying to figure out what to work on next, I go there first.

Claude Code handles implementation. It knows the codebase, can run tests, and works through features iteratively. It doesn't really need to know why I'm building something -- just what to build and how.

What the Loop Actually Looks Like

In practice, a development session tends to flow something like this:

• Product advisor session: Work through the next feature or decision. What problem does it solve? What's the simplest version worth building? What should be deferred? I try to come out of this with a clear, scoped brief rather than a vague idea.
• Claude Code session: Hand the brief to Claude Code and implement. Because the decisions are already made, the agent can focus on execution rather than figuring out what I actually want. In my experience this produces cleaner results with less back and forth.
• Review and integrate: Review the output. If something surfaces a new question or decision, I take that back to the product advisor rather than trying to resolve it in the middle of a Code session.
• Loop: While Code is implementing, I use the product advisor to think ahead to the next feature. By the time implementation is done, the next brief is roughly ready.

The real gain: That last step -- thinking ahead while building is happening -- is where the parallelism starts to feel meaningful. You stop waiting and start pipelining.

Scaling Further: More Agents, More Parallelism

Parallel Implementation Streams

Beyond the thinking/building split, the next logical step would be running multiple Claude Code sessions simultaneously -- each working on a different part of the codebase at the same time. I haven't done this yet, but the concept is straightforward: assign each agent a clearly bounded piece of work that doesn't overlap with what the others are doing, and run them in parallel.

The key prerequisite is genuine independence. If two agents are both touching the same files, you'll end up with conflicts that cost more time to resolve than you saved by running them simultaneously. So the first question before spinning up multiple Code sessions is: can these workstreams actually run without stepping on each other?

When the answer is yes, something like this could theoretically run at the same time:

There are tools that make this cleaner from a Git perspective -- ways to isolate each agent's working environment so they're not literally editing the same files -- but that's a technical detail worth exploring once the basic pattern makes sense. The principle comes first: define the boundaries, minimize overlap, integrate when each stream is done.

Orchestration: The Frontier

The more sophisticated version of multi-agent development -- where a manager agent breaks down a large task and coordinates sub-agents on pieces of it -- is something companies like Cognition are building toward. It's an interesting area to follow, but for a solo developer today it's probably more complexity than the gains justify.

The practical version for now is manual orchestration: you're the manager, you decide what runs in parallel, and you do the integration work yourself.

A Spectrum of Parallelism

It helps me to think about this as a spectrum rather than an on/off switch -- levels of parallelism you can move into gradually rather than all at once:

What This Changes About How You Work

You Become the Integration Layer

The most significant shift I notice with multi-agent development is in my own role. In serial development, I'm mostly a director -- I decide what to build and the agent builds it. With multiple agents running, I'm adding a second function: integrator. Reading outputs from multiple streams, connecting them, resolving conflicts, keeping the whole thing coherent.

It's a different mode of working -- less heads-down in the details, more focused on how the pieces fit together. Whether that suits you probably depends on what you enjoy about building.

The New Bottleneck

In serial development, the bottleneck tends to be waiting for the agent to finish. With multiple agents running, that bottleneck largely disappears -- but a different one appears. Your own review and integration capacity becomes the constraint. You can only absorb and make sense of so many outputs before quality starts to slip.

I don't think that's a reason to avoid parallelism -- but it does suggest being honest about how much you can actually run in parallel and still review well. More agents isn't automatically better. The right number is probably however many you can integrate thoughtfully, not however many you can spin up.

Strategic Coherence Matters More, Not Less

When you're working serially, coherence is somewhat built in -- you're thinking through one thing at a time and the decisions stack naturally. When multiple streams are running simultaneously, there's more risk of drift: two agents solving the same problem differently, or building toward things that don't fit together cleanly when integrated.

This is part of why the product advisor setup feels important beyond just efficiency. It becomes a coherence anchor -- the place where strategic questions get resolved before they turn into implementation conflicts. The more you parallelize, the more valuable that anchor becomes.

What to Watch Out For

Multi-agent development seems to add real leverage, but it also adds real complexity. A few things I'd flag as worth thinking about before going all in:

• Independence is the prerequisite. Parallel streams only work cleanly when the work is genuinely independent. If two agents are touching overlapping parts of the codebase, you'll likely spend the time you saved on merge conflicts and integration debugging. Worth asking honestly whether the streams are truly independent before running them in parallel.
• More agents means more review. Each agent output needs your eyes before it goes into the codebase. Spinning up three Code sessions doesn't give you three times the output if you don't have the capacity to review three times as much. The bottleneck moves, it doesn't disappear.
• Serial isn't a consolation prize. The serial approach -- one feature at a time, full focus -- is genuinely well-suited to solo development where you're the only reviewer. Multi-agent isn't an upgrade from serial; it's a different mode that suits different situations. Part of the skill is probably knowing which one to use when.