Multi-agent orchestration is the hot topic of 2026. Introduced in February, Agent HQ from GitHub allows developers to concurrently use Claude, Codex, and Copilot to solve a problem, with each having a different perspective on trade-offs or details. Between Q1 2024 and Q2 2025, Gartner experienced a 1,445% increase in inquiries about multi-agent systems. Steve Yegge, a very experienced engineer at Amazon and Google, has discussed his work on orchestrated agents and producing 12,000 lines of code per day. Even more impressively, Cursor's team programmed an entire browser over a thousand files and a million lines of code in just one week by using hierarchical orchestration rather than having a single agent perform all the tasks sequentially, though multiple reviewers reported the code didn't compile at announcement, and Cursor's own CEO described the result as merely "kind of works".
The part nobody's celebrating
The only news to this is Google's 2025 DORA report. It determined that for a 90% increase in AI adoption, bug rates climbed 9%, code review time rose 91%, and average PR size grew 154%. When read as a single group, that pattern emerges instantly: teams are shipping more code, more quickly, and it's measurably more difficult to review, and measurably more buggy once it is shipped. No, multi-agent setups don't help with this; they exacerbate it. You're not just reading one model's decisions now; you're reading several.
Engineers who interact with such systems refer to a particular type of failure: architectural drift, in which each agent takes an action that is locally optimal but inconsistent with the actions taken by the other agents five minutes ago. One agent selects one pattern to use for errors, another agent selects another pattern for a neighboring module, and nobody realizes until anybody attempts to extend the feature, and the codebase spits. Then there is the issue of "lost in the middle," as it's called, and how much information that is in the middle of the long context window becomes lost and essentially forgotten by the agent, so it seems like it doesn't know about it.
The naive version of this doesn't work very well, as Cursor's own account of constructing that browser admits. The first tried to treat all agents the same and, to avoid collisions, used file locking, but this didn't work: agents were holding locks too long, and twenty agents were operating at the throughput of two or three. Their second attempt was optimistic concurrency control, not locks, and that didn't work out quite right; the agents became more of a risk taker and began to avoid anything that resembled a hard task. What really worked was a hierarchical structure as opposed to agents being free to improvise in parallel: Planner agents that continuously explored the codebase and created tasks, Worker agents that executed assigned tasks without coordinating with each other, and Judge agents that determined whether to continue at each cycle's end, rather than a bunch of agents improvising freely in parallel with no one peeking at each other's work.
Why this becomes a review nightmare
In response, automated PR review tools have scaled, and teams managing multiple agent review fleets see real improvements: 30–60% faster review cycle times and, in the best cases, 25–35% fewer production defects. But even the researchers developing these systems are straightforward about the problem: AI reviewers are good at spotting issues in the code, and they're not so good at understanding what you were trying to accomplish, and why you were making the decision. What you get is a ton of automated "this could be improved" comments, yet not much of "this doesn't fit how the rest of the system thinks.
In a piece about orchestrated coding, Addy Osmani stated it quite simply: "With an orchestrated army of agents, there's no natural bottleneck. Small harmless mistakes — a code smell here, a duplication there, an unnecessary abstraction — compound at a rate that's unsustainable." These are no longer being created by a single human who was used to writing the code manually and would have noticed any errors or bugs; now they are just being created by many humans who are not involved in the code change, so the errors just accumulate. There is no crash reported. It turns up when someone tries to add a feature to it, and finds the architecture won't support it, and the tests that the agents also wrote are no more reliable than the code they were supposed to be checking.
What this actually means for teams adopting this now
None of this is a reason to not use multi-agent coding. The productivity narrative is true, and it will keep going. But it is the teams who are designing plan-approval steps, token budgets, verifier agents, human review gates, and so on into their orchestration, rather than eliminating themselves from the equation and hoping that the agents will get it and do this well. These teams will not realise the cost right away if they do not do that. They will see it in 6 months when the two-line feature request becomes a two-week rewrite, and no one, human or agent, understands the system's structure and why.
There was never a problem with speed. It was inevitable that coordination would be difficult. But it was not until now that we needed to solve it.
Top comments (0)