Why more AI coding agents can make developers slower

Anthropic and Cognition caution that multi-agent coding brings higher token costs and coordination risks, making a single focused session the better default for most tasks.

The appeal of multiple AI coding agents is easy to understand. Several assistants working at once look efficient, but the visible output often hides the real costs: heavier token use, more coordination, and a greater chance of spending time untangling conflicting changes. The practical question is not how to add more agents, but whether a second one solves a problem that a single, well-directed session cannot.

That caution runs through recent guidance from Anthropic and from Cognition, the company behind Devin. Both argue that the default should be a single linear workflow, because a shared context is easier to manage than a set of partially informed parallel threads. Cognition has warned that actions imply decisions, and that separate agents without full visibility can make incompatible assumptions. Anthropic makes a similar point in its Claude Code documentation, saying that teams increase coordination overhead and consume more tokens than one session, especially when the task is sequential or tightly coupled to the same files.

The best reason to move beyond one agent is usually a ceiling that can be named clearly. One is a context ceiling, where logs, search results or long files crowd out the useful instructions. Another is a serialisation ceiling, where work could be split into independent pieces and done at the same time. The third is a specialisation ceiling, where different parts of a job need different tools, permissions or prompts. If a task does not hit one of those limits, the simpler setup is usually the better one.

For everyday coding, a single agent remains the most reliable choice. A bug fix, an endpoint change or a module refactor normally benefits from one continuous chain of reasoning, because every decision stays in the same transcript. Before adding another agent, it is often worth tightening the instruction file, writing a short plan first, or starting a fresh session when the new task is unrelated. Those small changes resolve many cases that first appear to require a multi-agent arrangement.

Subagents are the lightest form of delegation. In Claude Code, they are described as specialised assistants that run in their own context window, with their own prompt, tool access and permissions. They are most useful when a side task would clutter the main conversation with material that does not need to be preserved. Examples include scanning a repository for all uses of a deprecated API, running a test suite and summarising the failures, or reviewing a diff against project conventions without editing the code. Anthropic also notes that subagent descriptions should stay short, because those descriptions are loaded into every session and can themselves become a burden if they grow too large.

Agent teams go further still. Anthropic describes them as an experimental Claude Code feature, switched off by default and designed for cases where several workers need to operate in parallel and exchange findings. One session acts as the lead, assigns work and synthesises results, while other agents handle separate strands. The company says this can make sense for research, review and new feature development, particularly when different layers of the stack can be owned independently. It also warns that the extra token use rises with each active teammate, and that the feature still has limitations around coordination and session recovery.

That cost matters. In Anthropic’s own account of its multi-agent research system, agents used about four times as many tokens as chat interactions, while multi-agent systems used roughly 15 times as many. The same material says a lead agent with parallel subagents outperformed a single agent by 90.2% on an internal research evaluation, especially in tasks that rewarded breadth-first exploration. The lesson is not that more agents are automatically better, but that they are most valuable when the work is parallel, independent and high stakes enough to justify the overhead. When tasks are tightly interdependent, especially where several agents would touch the same files, the coordination tax can outweigh the gain.

A simple decision check helps. If a side task would flood the main context, use a subagent. If the work can be split into pieces that do not collide, parallel subagents or a team may be sensible. If the parts need to debate or validate each other, a team may be the right structure. If the task is not valuable enough to pay for several times the tokens, it is probably not worth the complexity. And if you cannot clearly tell which agent caused a failure, the system may already be too complicated for the job it is doing.

For developers evaluating Claude Code specifically, recent coverage from other publications has reinforced the same pattern: agent teams are useful for complex, multi-layer work, but they are still a specialist tool rather than a default mode of operation. The strongest cases are those where parallelism is real, dependencies are limited and the result is worth the extra spend. For routine coding, a single agent with good guidance remains the cleaner, cheaper and easier-to-debug choice. This article was written with the assistance of AI and reviewed by the author.