You don't need ten agents. You need two tracks.
Spend enough time on the internet, and you'll see someone showing off a terminal with ten coding agents running in parallel. The implied pro...
📝 摘要
作者 Hugo Barauna 以自己构建 Elixir Radar 新闻通讯后台系统的实践为例，提出了一种高效的 AI 编码智能体工作流：双轨工作流（Dual-Track Workflow）——只用两个并行 Agent，而非十个。第一轨（Spec Track）是高度依赖人类注意力的「规格定义」阶段：从功能需求头脑风暴 → 功能规格说明（PRD）→ 技术设计 → 实现计划；第二轨（Implementation Track）是 Agent 可自主运行的「代码实现」阶段：Agent 拿到完整的 spec 和 plan 后独立编码，人类利用等待时间开始下一个 spec。文章从三个维度论证了"两个而非十个"的合理性：spec 是真正的瓶颈（你一次只能写一个 spec）；编码完成 ≠ 工作完成（代码审查、功能测试、UI 打磨仍需人类参与）；UX 无法委托给 Agent（好产品是主观判断，来自你自己）。该工作流最适合同时掌握产品决策和代码的 builder（独立开发者、indie hacker、技术创始人），其理论根基来自约束理论（Theory of Constraints）、看板方法（Kanban）和 Marty Cagan 提出的双轨开发（Dual-Track Development）。
核心概念： AI 编码的真正瓶颈不是 Agent 的并行度，而是人类的注意力带宽——用"Spec 轨道"和"实现轨道"两条线交替推进，比堆叠十个 Agent 更高效。
关键技术栈 / 关键要点：
- Spec Track（规格定义轨道） — 需要持续人类参与：从模糊想法到 PRD → 技术设计 → 实现计划，Agent 充当协作思考者
- Implementation Track（实现轨道） — Agent 拿到完整输入后可自主编码，人类利用空闲时间推进下一个 spec
- 瓶颈在人不在机器 — 你一次只能写一个 spec，所以十个 Agent 没有意义；编码完成后还有 code review、功能测试、UI 迭代等人机交互环节
- UX 无法代理 — 好产品是主观的、有主见的，这部分决策必须来自人而非 Agent
- 理论根基 — 约束理论（瓶颈决定系统速度）、看板的"停止开始，完成在先"、Marty Cagan 的双轨开发模型
关键结论 / 实践建议： 对于独立开发者或技术创始人，两个并行 Agent（一个做 spec、一个写代码）已是最高效的节奏；对于有 PM 提供 spec 的团队，可以适当增加轨道但依然不可能到十个。一次性 throwaway 代码则直接 vibe coding 即可，无需这套流程。
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 testing, UI improvements.
Software development has different phases, like specification, implementation, and verification. Agents can perform autonomous work on implementation, but specification and verification still require a lot of human touch. You can't make this system go faster by parallelizing phases that aren't the bottleneck.
You can't delegate UX
When you're building customer-facing features and you want to build a great product, you can't delegate UX to an agent.
Yes, the agent can implement front-end code and wire it all up to your full stack. But once this part is done, you still need to iterate on the UI. Not because it has to be pixel-perfect, but because building a great product is subjective and opinionated, and that comes from you, not your agent.
Who is this for?
I believe this workflow is mostly valuable for builders. People who hold the product decisions and the code at the same time. Solo devs, indie hackers, technical founders.
That's not to say it's useless for developers. If a product manager hands you a fully decided spec, the functional requirements work is done, but you still need to turn that into a technical design and an implementation plan for your agent. And while the agent builds it, you can start the technical design for the next item in the product backlog. So maybe you can handle more than two tracks, but still, probably not ten.
All that said, there's a context where this workflow is not useful. Specs, plans, and code review only pay for themselves on code that's meant to live. For any kind of work that will be thrown away at the end, vibe coding is fine.
A working example
As I said, this isn't theory. It's how I built the software I use to run Elixir Radar. So I recorded a video to make it concrete: an unedited, end-to-end run of the two-track workflow being applied on a production app.
Besides showing the workflow in action, I also show the tools I use to implement it:
- Tidewave: the agentic dev environment for Phoenix and Rails
- Superpowers: agent skills for creating specs and implementation plans
Evolution, not disruption
After reflecting on why this workflow is working for me, I noticed it's not by accident. There's actually a lot of knowledge and practice in software engineering and systems thinking that led me to it.
For example, the fact that a system can only go as fast as its bottleneck is from the theory of constraints and queueing theory.
The idea of finishing and reviewing what you have before starting more in parallel comes from Kanban's "Stop starting, start finishing".
The "two tracks" name I got from "Dual-Track Development", which was popularized back then by Marty Cagan, from the product management community.
We need to remember that there's already a lot of established knowledge and theory we can leverage; we're not in completely uncharted territory. Yes, the new tools are remarkable, but the principles still apply. It's a matter of adapting them to an agentic development world.