A lot of engineers assume the next big jump in AI-assisted programming is going to come from a smarter model. I think it's more likely to come from getting many copies of the models we already have to work on a single problem at the same time. That's more or less how human organizations work, and organizations are the original form of superintelligence, since no single person at a big company understands the whole codebase and the company still manages to ship it every day. Agent swarms are the first way we've had to get that effect without spending years hiring.
We're already kind of doing this by running many isolated tasks in parallel, and so coding agents have already helped us horizontally scale our attention. Simon Willison called it the parallel coding agent lifestyle (opens in a new tab). On a normal day I have a few dozen things going at once this way, but they're isolated things and I'm the bottleneck, struggling to coordinate them. Getting many agents to work together on the same task is a different and much harder problem.
Organizations are the original superintelligence
Human organizations like corporations, governments and militaries enact a kind of superintelligence, in that they can do things no person inside them could do alone. Some of that is culture, which foundationally in anthropology is considered the total set of shared mental representations ("context") among a group, and it lets people who have never met make decisions that fit together without asking each other first. There's also a sort of superhuman memory that we call organizational memory -- everything that got written down or built into a process. And the work gets split up so that nobody has to hold all of it in their head.
An agent swarm is very similar in my eyes. The agents share a code repo or documents between them the way people share organizational memory, and there's often an orchestrator agent doing more or less what a manager does. The big difference is that an organization takes years to build, whereas you can start a swarm this afternoon.
Thinking longer takes too long
The usual way to get more out of a model is to let it think for longer, which people call test-time compute. As far as we know now it hasn't hit any kind of wall. The UK's AI Security Institute has a post on this (opens in a new tab) where they say "every time we double the token budget, we see about the same absolute increase in success rate", and that kept holding at budgets far bigger than evaluations normally use.
Obviously the problem is that you have to keep doubling it, and every doubling takes twice as long. Claude Opus 5.5 on max effort already takes close to half an hour on a task. Scaling that up by, say, a thousand times makes it take so much longer that it's impractical. Noam Brown of OpenAI put it this way on Dwarkesh's podcast (opens in a new tab): "You don't want to sit around for three years waiting for a response."
Scaling out instead of up
But scaling out horizontally by a thousand times is very practical, because the agents all run at the same time and you don't wait any longer. It's been made especially possible by sandbox providers becoming a commodity. A sandbox for an agent costs pennies an hour (opens in a new tab) now, and Modal wrote about running a million of them at once (opens in a new tab).
So the interesting question, I think, is: does the scaling you get from thinking longer also apply to horizontal scaling? If it does that's a very important result, and from what I can find it mostly does. Toby Ord has a post on swarm scaling (opens in a new tab) where he goes through the results OpenAI has published for small teams of agents, and adding agents gets you a bit more than half of what you'd get from letting one agent think longer on the same compute. That's a good trade to me, since you get the answer so much sooner.
In the system card for Opus 5.5 (opens in a new tab), Anthropic gave teams of up to a hundred agents one long math proof to work on. With a whole day, a small team did about as well as the biggest one, but with only a couple of hours the biggest team was way ahead.
It also turns out that some of the famous "thinking longer" results were already horizontal, which surprised me. The o3 result on ARC-AGI (opens in a new tab) is what got a lot of people excited about test-time compute in the first place, and the higher of its two scores came from giving the model far more attempts at each puzzle. OpenAI's own docs describe GPT-5.5 Pro (opens in a new tab) as "the same underlying model using a setting that makes use of parallel test time compute". So at least part of what you get from the Pro tier is many copies working at once.
Agents should carry less overhead than people
Brooks's law, from The Mythical Man-Month, is that "adding manpower to a late software project makes it later (opens in a new tab)". New people have to be brought up to speed by the people already working, and the communication a team needs grows a lot faster than the team does.
Whereas Brooks showed that scaling humans on a project might actually slow it down, I think we'll find that horizontally scaling agents doesn't carry the same amount of overhead. It probably carries some, but a lot less than humans do. An agent gets up to speed by reading the repo, which takes a few minutes and doesn't cost anybody else any time. Agents can also hand each other their whole context, where people have to summarize it in a meeting.
The measurements we have so far don't really show this yet, to be honest. In Ord's numbers, small teams of agents lose about as much to coordination as teams of people do, although the bigger experiments are more encouraging.
Microsoft Research had about a thousand agents rebuild pandoc from scratch (opens in a new tab) in a matter of hours with no agent in charge.pandoc is a big open-source document converter The full group got a good deal further than one agent did, and adding agents was still helping at the largest size they tried. OpenAI went even further than that and ran ten thousand agents on a Navier-Stokes problem, but nobody has repeated that at other sizes because it probably cost like $20 million (opens in a new tab) -- but at the current rate of 10x declining costs YoY (opens in a new tab), we're four years away from that costing $2,000!
So I'd expect the number of parallel, independent intelligences on a single programming task to get much, much higher than you could ever get with people.
It only works when the work can be split and checked
Swarms seem to often fail in roughly the same way human organizations do: in Cursor's first attempt (opens in a new tab) every agent coordinated through one shared file with locks on it, and the agents spent most of their time waiting on each other. They fixed it by organizing the agents into planners and workers. In Anthropic's biggest team the lead agent appointed its own sub-leads without being told to, which is sort of the same fix showing up by itself.
For me it's still rare that I actually go ahead and try this agent swarm approach right now and try to scale out a single job horizontally, because I've noticed the pieces need to be somewhat isolated for it to work. But recently I broke a job down into fifty Python data pipeline changes and had fifty agents do them, and they all came back really well. It was practical to coordinate them with a single orchestrator agent, which is what really turned me on to thinking about this.
The other thing is that you also need a way to check the answer. Every result I've mentioned comes from a problem with a test suite or a proof checker, which most real work doesn't have, and there's a paper called Large Language Monkeys (opens in a new tab) showing that without one, more attempts barely help. Even with one you can end up with something nobody understands: a month after OpenAI's swarm produced its machine-checked proof, Scientific American reported (opens in a new tab) that nobody fully understood it yet.
Engineering hasn't had its Navier-Stokes moment
I think we're already seeing this show up in lab research, but in practice swarms haven't been adopted for engineering broadly yet. Walden Yan at Cognition, the company that makes Devin, has a post from this year (opens in a new tab) saying that for swarms of agents writing code in parallel, "most of the sexy ideas in that space still don't see meaningful adoption".
The other thing that's missing is that the Navier-Stokes moment hasn't really happened for engineering yet. Mathematicians have written plenty of groundbreaking proofs, and what made this one a moment is that a swarm of agents did work at that level, on one of the most famous open problems in math, even if people are still working through what it shows. The engineering version would be a swarm building something that people actually depend on in production, and there isn't quite as good of an example of that yet. The closest are probably Cursor's web browser and Anthropic's C compiler (opens in a new tab), which are impressive, but nobody is relying on either of them.
Wrapping up
I want to build and rewrite very large software systems in days instead of years. If we can get to something like a billion tokens a second on a single task without it being a useless expense of tokens, you essentially have the cognitive output of hundreds of thousands of people collaborating on one thing.
I think the things in the way are probably cost, which at least keeps falling fast (opens in a new tab), and having a verifier. Past that it's mostly an organizational problem that nobody has really solved yet -- how to split up the work so that agents don't end up waiting on each other.