Five Parallel Coding Agents Won't Make You 5x Faster. You Are the Queue

Five coding agents were started simultaneously, with each tasked with working on a separate project. After 40 minutes, two agents had completed their work and awaited review, while another hit an error, another asked a question about the database schema, and the fifth was still actively working. The delay in the fourth agent's progress was due to the reporter's inability to promptly respond to its query, given the limited time they could dedicate to each agent's progress.

Claude Code's agent view, introduced in Cursor 2.0, allows developers to manage multiple agents across various projects from a single, centralized interface. The idea behind parallel coding agents is to enable developers to work with multiple codebases simultaneously, streamlining the research and proof-of-concept process. However, the reporter emphasizes that parallel agents do not replace the need for a developer to review and approve the output, as one reviewer is still required to handle all the output generated by the agents.

Queueing theory helps to understand the limitations of parallel coding agents. Little's law states that the average number of agents waiting in the system is equal to the arrival rate of agents multiplied by the average time each agent spends waiting for a response. As more agents are added, the arrival rate (λ) increases, leading to a higher number of idle agents (W) if the reviewer's response time (W) does not improve.

Kingman's formula suggests that the wait time increases significantly as the server (in this case, the reviewer) becomes busier. The formula indicates that the wait time grows rapidly as the busy factor (ρ) approaches 1, meaning the reviewer is consistently busy with multiple agents.

The reporter points out that each agent's question or request for information restarts the resumption cost, as the developer must rebuild their context and understanding of the codebase before addressing the new request. This increased context-switching cost adds up over time, especially when dealing with code written by other developers, which is typically more complex and difficult to understand.

Additionally, interruptions can lead to increased stress and frustration, further impacting the reviewer's performance and the overall quality of their code reviews.