Running more agents in parallel does not make you faster if every agent needs your decisions. The way out is to make most of those decisions before the agent starts.
This week Adam Tornhill published Scaling Agentic Coding As If People Still Mattered. He reacts to a trend that many of us see: developers who run five to ten coding agents at the same time, each one in its own terminal tab. Tornhill expects this to become normal. And he warns about the cost for the people behind the terminals.
One line from his post stuck with me:
“With five parallel agents, you are not juggling five tasks. It’s more like 50.”
I agree. And I think this line explains very well why we need specifications in agentic development.
The bottleneck is not the agent
Tornhill makes a simple point: agents scale, human attention does not. What counts is not the number of agents, but the number of focus tasks. A focus task is work that needs your judgment and your sign-off.
Why is one agent task more than one task for you? Tornhill uses the idea of requirements explosion from Robert Glass. Each requirement in your input brings many hidden design decisions. How do we handle an empty list? What happens if the customer is blocked? Who may see this field? An agent cannot answer these questions alone. It either asks you, or it guesses.
Both options are bad when you run five agents:
- The agent asks. It stops at an unpredictable moment. You switch context, again and again. Tornhill describes the cost: attention residue, decision fatigue, stress, and less creativity.
- The agent guesses. It does not stop. But now the decision is hidden in the code, and nobody made it on purpose. You find it later in a review, a test, or in production.
So the problem is not how fast the agent writes code. The problem is where and when the decisions are made.
Make the 50 decisions once
You cannot remove the hidden decisions. But you can choose when you make them. In the AI Unified Process, we make them before implementation starts, in the specification, and not under pressure while five terminals wait for an answer.
Tornhill says the role of the engineer is shifting to two jobs: deciding what to build, and creating an environment that guides how it gets built. This is very close to the three layers of the AI Unified Process:
| Layer | What it holds | Who owns it |
|---|---|---|
| What | Requirements, use cases, business rules, entity model | People |
| Harness | Stack, architecture decisions, conventions, skills, tests | People |
| How | The code | The agent, guided by the two layers above |
In practice, the hidden decisions land in concrete places:
- Use case specifications describe the main scenario, the alternative flows, and the business rules. The empty list and the blocked customer are written down here.
- The entity model fixes data types, lengths, and validation rules.
- Architecture decision records capture the technical choices, so the agent does not make them again in every task.
- The open questions log collects what we don’t know yet. A gap is a question for a person, not a guess for the agent.
A use case goes to implementation only when it is approved. At that point, most of the 50 decisions are made. The agent still writes the code, but it has much less reason to stop and ask, and much less room to guess.
One focus task: the use case
Tornhill’s own rule is to run several agents but keep only one focus task at a time. The other agents do background work that he checks during breaks.
The AI Unified Process makes this rule easy to follow. We don’t split use cases into a list of small tasks. The use case is the unit of work. So your focus task has a clear name, a clear scope, and a clear end: UC-007 is implemented, tested, and covered.
The background work fits around it:
- Coverage checks that compare code and tests with a use case
- Spec reviews that look for gaps and contradictions
- Dependency upgrades and other maintenance
- Small fixes where the expected behavior is already specified
These tasks need little judgment while they run. You look at the result when you have time, not when the agent decides to interrupt you.
Thinking time is part of the process
The part of Tornhill’s post I liked most is about incubation. When a problem is complex, it helps to step away. Learn as much as you can about the problem, then go for a walk. Often the idea comes when you stop pushing. He is honest that the theory behind this is still debated, but many of us know the effect from experience.
Writing a good use case is exactly this kind of work. You talk to the business, you read old code, you find the alternative flows nobody mentioned. Then you need time before the answer is clear. This is not lost time. This is where the real design happens.
If we fill every pause with one more agent, we lose this time. Then the hard decisions are made in a hurry, or not at all. A spec-first process gives the thinking a place: the specification is the focus work, and the agent waits for it, not the other way around.
Conclusion: Keep IT simple
The number of agents is not a goal. Tornhill reminds us that busy is not the same as productive, and that the best code is often the code we don’t write.
The AI Unified Process does not help you juggle 50 tasks. It turns them into decisions you make once, written down where people and agents can find them. Then one focus task is enough, and the agents can do what they are good at.
Tornhill does not write about specifications or the AI Unified Process. But his findings support the same direction: protect human attention, and put it where it matters most, on what we build.
If you want to learn more, have a look at the AI Unified Process.
