AI coding agents make modularity worth designing for, a blog post argues

A blog post argues that AI coding agents have changed what counts as a small software team, and that the deep codebase modularity long associated with giant, service-heavy companies is becoming a practical necessity rather than an extreme choice.

For decades, the post says, a small team of 5 or 10 people writing code at the same time never needed to think about this: on a busy day such a team might generate around 50 commits, 20 pushes and 10 pull requests. A small team today, running 20 to 100 AI coding agents in parallel, might instead generate around 500 commits, 200 pushes and 100 pull requests on a busy day, a tenfold jump across all three figures. The post presents these numbers as an illustrative example of what a team might produce, not measured data from any specific team.

The post's central comparison is Uber, which it says runs thousands of microservices, a structure it traces to hundreds of engineers wanting to deploy on their own schedule with clear ownership of their own code rather than queue behind one shared merge process. Uber's degree of modularity, the post argues, may have looked extreme when the company adopted it, but could become the new normal now that a team's real unit of work is dozens of parallel coding agents rather than a handful of people. Its reasoning: in a large monolithic service where every change has to be coordinated carefully, two significant pieces of work stand a good chance of colliding, forcing merge-conflict resolution and rework. Split into thousands of independent services the way Uber's are, the same work becomes what the post calls an 'embarrassingly parallel' way of working: a team can point one coding agent at each service, tell it to improve performance, and stand a good chance of shipping improvements across all of them at once.

The post argues modularity used to be expensive because every additional service meant more boilerplate, plumbing and CI configuration to maintain by hand. Coding agents now write that scaffolding themselves, it says, so the overhead of splitting code into more, smaller pieces matters much less than it used to. Agents are also described as extremely limited by their context window, so a module, whether a service or a library, that is small enough to fit inside that window is said to dramatically improve how well a coding agent performs on it.

The post cautions that the approach only pays off if the agents can actually work independently: 100 or more coding agents running in parallel that instead spend their time resolving merge conflicts, fixing broken builds and untangling deployment problems can leave a team with net-negative productivity. Its conclusion is that a codebase's modularity now sets a ceiling on how many coding agents a team can run effectively in parallel, which is why it says modularity is worth designing for from a project's very beginning rather than adding it later.

Key facts

For decades, a small team of 5 or 10 people writing code at the same time might generate around 50 commits, 20 pushes and 10 pull requests on a busy day, per the post's own illustrative figures.
A similarly sized team running 20 to 100 AI coding agents in parallel could instead generate around 500 commits, 200 pushes and 100 pull requests on a busy day, a tenfold jump across all three figures, in the post's illustrative estimate.
Uber is cited as running thousands of microservices, a structure the post traces to hundreds of engineers wanting to deploy on their own schedule with clear ownership of their own code rather than share one merge queue.
The post argues splitting code into small, independent services lets more coding agents run usefully at once, since a large monolithic service instead makes it likely that two significant pieces of agent work will collide and force merge-conflict resolution and rework.
Coding agents are said to now write the boilerplate, plumbing and CI configuration that used to make splitting code into more services expensive, but the post warns that 100 or more agents running in parallel must work independently or a team risks net-negative productivity from merge conflicts, broken builds and deployment problems.

Why it matters

AI coding agents are inflating how much code one team can touch at once, and the post's core claim is that this breaks the old assumption that a handful of people editing one file at a time is the default way software gets built. If a team of 5 or 10 engineers can effectively field 20 to 100 parallel coding agents, its real unit of work starts to look like the sprawling, many-service organizations that Uber represents, rather than a small team in the old sense. That reframes a once-extreme architectural choice, deep modularity in the style of Uber's thousands of microservices, as something the post argues ordinary teams may now need to adopt just to keep many agents from tripping over each other.

Who it affects

The argument is aimed at small engineering teams and technical leads who are already running, or considering running, many AI coding agents at once, and at anyone deciding how to structure a codebase before writing it. The post explicitly contrasts two situations: a team with one large, monolithic service, where careful coordination means two significant pieces of agent work stand a good chance of colliding and forcing merge conflicts and rework, versus a team with something like Uber's thousands of independent microservices, where a coding agent can be set loose on each one separately. Teams that already have a large monolith are the ones the post says face the most friction from adding parallel agents.

How to use it

The practical takeaway is to design a codebase's boundaries around what a coding agent can usefully own: split it into services or libraries small enough to fit inside an agent's context window. The post's own example is one coding agent per service, the way it describes firing up an agent for each of many microservices, rather than routing several agents through one large, shared service. It argues this kind of splitting used to be too costly to justify, since every extra service meant hand-written boilerplate, plumbing and CI configuration, but coding agents can now write that scaffolding themselves, so the up-front cost of splitting a codebase is much lower than it used to be. The post's conclusion is that this modularity is worth designing in from a project's start rather than retrofitted once a monolith is already large.

How solid is it

This is a single blog post making an argument by analogy, not a study, survey or benchmark. It names no specific coding-agent product or vendor anywhere: 'coding agents' and 'agents' stay generic terms throughout. Beyond citing Uber's well-known microservices setup as a comparison, no team, company or case study is named as having actually run 20 to 100, or 100-plus, coding agents in parallel. Its central commit, push and pull-request figures, 50/20/10 for a small team without agents versus 500/200/100 for one running 20 to 100 agents, are explicitly the author's illustrative estimate of what a team 'might generate,' not measured data collected from a real team or deployment. The piece had drawn 44 points and 81 comments on Hacker News, which reflects reader interest but is not evidence for the claims themselves.

Risks and caveats

The post's own caveat is that the payoff depends entirely on the agents working well independently: it says 100 or more coding agents running in parallel that instead spend their time resolving merge conflicts, fixing broken builds and untangling deployment problems can leave a team with net-negative productivity, the opposite of the intended effect. It does not put a number on how much a small, context-sized module improves agent performance, or on how bad net-negative productivity can get in practice: both the benefit and the risk are argued qualitatively rather than measured. The Uber comparison anchors the argument in one well-known company's existing setup rather than in a case of a team that adopted deep modularity specifically to run many coding agents.

“So Uber’s approach to modularity may have seemed extreme at the time, but it could become the new normal.”

— the post