exe.dev argues for running fewer coding agents, not more
The exe.dev team says spawning parallel agents to hide latency hurts focus, and shares experiments for working well with fewer agents.
In a post on the exe.dev blog dated October 1, the team argues that the task-management layers in many "software factory" demos exist to hide agent latency. Their target is the habit of starting a new agent every time you're blocked. The post calls concurrency "really rough on humans," saying it trashes flow state, and calls task management "a band-aid." If you juggle several coding agents at once, this is a case for fewer agents and better feedback loops with each one.
The first experiment is one you can try with your own setup. Start a task with a powerful model, then hand all human conversation to a fast model the post calls Luna 6. That model gets no coding tools and a deliberately short context. When it runs out of ready information, the stronger model takes back over with your feedback. The post doesn't say exactly how that handoff is wired. The authors say it "works reasonably well" but found chat too narrow a pipe.
That led to other experiments:
- Shipped: a screen-and-audio recording feature in their agent, Shelley.
- Not shipped: an HTML artifact that tracks what you view, scroll and click while you talk.
- Still experimental: streaming partial feedback to the agent while you're still recording.
The limits are stated plainly. The author says they don't yet get the same throughput from one or two agents as from many, and the post includes no measured productivity data.
Dex Horthy framed it as an old lesson: XP and Lean practitioners have said "limit work in progress" for decades, and he says it still holds for agent workflows.