You don't need ten agents. You need two tracks.<br>- Tidewave

We can't find the internet

Attempting to reconnect

Something went wrong!

Hang in there, we will be right back

You don't need ten agents. You need two tracks.

Hugo Baraúna<br>June 18, 2026

essay

Spend enough time on the internet, and you’ll see someone showing off a terminal with ten coding agents running in parallel. The implied promise is simple: more agents, more productivity. Ship ten times faster! I don’t buy that.

Instead of ten, I run only two agents.

I use this workflow to build real software: the back-office system of the Elixir Radar newsletter, which I use to curate and assemble each issue, send it through my email platform, and let customers manage their own sponsorships.

Now, let me explain the workflow.

The two tracks

The workflow I use is composed of two tracks: the spec track and the implementation track.

The spec track

In the spec track, you start with a feature idea, maybe just a couple of sentences, and end up with a complete functional specification (spec) and a technical design (plan).

First, I ask the agent to help me brainstorm this feature idea. Along the way, the agent will ask me questions to help me clarify my thinking, read the codebase to understand what’s already there, and go through it with me step by step. At the end, we have a document outlining the functional requirements for this feature, or what product people call a PRD (product requirements document).

The second step is to ask the agent to create a technical design (architecture) based on the functional spec. Again, the agent will read the codebase, show me a technical design, and ask me questions before I approve it. At the end, the agent creates an implementation plan that includes both the technical design and the work broken down into “engineering tasks”.

Once both steps are complete, we have everything we need to start the second track.

The implementation track

Using the inputs from the spec track, we can start an implementation track. We say to the agent: “Here’s a spec and an implementation plan, please implement this”.

Unlike the first track, we don’t need to give the agent our full attention on this one, because the agent already has all the input it needs to work on its own for a while. You can decide to review the code as each task finishes or at the end. Either way, we now have time to do some parallel work.

As the agent implements the first feature, you start the next spec. Sometimes the implementation agent needs your attention here and there; you step in, give some feedback, and go back to the spec.

By the time you review and approve the implementation, chances are you’ve either finished the new spec or are close to it. Once it’s ready, you start another implementation agent and keep that cycle going.

Why only two agents?

There’s no perfect number of agents you can run in parallel. But as I used this workflow, I felt that a few things pushed me toward using two agents in parallel rather than ten.

Balancing two types of attention needs

In the spec track, the agent needs lots of my attention, while in the implementation track, it doesn’t. And because of that, it’s possible to work in those two tracks in parallel.

In the spec track, it’s not possible to just say to the agent, “hey, here’s the name of this feature I want to build, and here’s a couple of sentences, create a spec and an implementation plan”. This is not enough input for the agent; that’s why you should have it ask you lots of questions, answer, review… so that by the end, you have well-thought-out input for a more autonomous work.

Now, in the implementation track, you have input artifacts that enable the agent to work more autonomously. Yes, after it finishes generating code, you want to review it. But it will take time for the agent to implement and need feedback, and during that time, you can do something else: the next spec.

Now, contrast that with a scenario where you try to make two specs in parallel: that’s much harder to manage. Given that a spec track needs continuous attention, it’s hard to parallelize. Which leads us to the next reason to use two tracks instead of ten.

Specs are the first bottleneck

Let’s say you have ten implementation agents at your disposal. But there’s just one of you creating the specs for those agents. How fast do you think this system can go?

The implementation agents can only go as fast as you give them inputs. And you can only create one spec at a time, not ten.

Finishing the code isn’t finishing the work

Ok, now let’s say you got to this point where you were able to write ten (independent) feature specs, and you can now give each of your ten implementation agents one of them in parallel. As they work on that, you could work on another spec, and that cycle could go that way.

But there’s a problem. Once one of your implementation agents finishes work, you have human bottlenecks again. Code review, functional human...