Uber (in)famously runs thousands of microservices. They ended up there because hundreds of engineers wanted to deploy on their own schedule, with clear ownership over their own code, instead of waiting in one giant merge queue.
For decades a small team had 5 or 10 people writing code at the same time and needed none of that. On a busy day that’s maybe 50 commits/20 pushes/10 PRs. The same team can now run 20 to 100+ agents in parallel, and that day looks more like 500 commits/200 pushes/100 PRs. Uber’s approach seemed extreme but it could become the new normal.
One developer coding in a “single-threaded” way, editing one file at a time:
[
](/images/theres-no-such-thing-as-a-small-software-team-vscode.webp)
One developer coding in a “multi-threaded” way, using coding agents in parallel:
Codebase modularity is the limit on parallel work 100+ coding agents running in parallel have to be able to work well independently. If they spend all their time trampling on each other’s work, resolving constant merge conflicts, fixing broken builds, and creating deployment nightmares, then you can even end up with net-negative productivity.
Splitting things up used to be very expensive, since every service meant more boilerplate, plumbing, and CI config. Agents write all of that now, so the overhead matters a lot less than it used to.
Agents are also extremely context limited. A module (whether it’s a service or a library) that’s small enough to fit in the context window dramatically improves coding agent performance.
The modularity of your codebase determines how many coding agents you can run in parallel effectively, so now it’s worth designing for this from the very beginning.