Why Small Teams Outpace Large Ones

Three reasons that have nothing to do with AI

When people explain why a small team is faster than a large one, they usually stop at one line: fewer people means less bureaucracy. True, but too vague to be actionable. There are actually three distinct reasons, and they operate at different levels.

The first is coordination overhead. On a three-person team, a decision gets made in one short chat conversation. On a fifteen-person team, the same decision goes through several meetings and a chain of people who formally need to sign off, and by the time everyone agrees, the context has already partly gone stale. It's not that people on a larger team are worse. It's that the number of connections between people grows faster than the team itself, and every extra connection is a spot where a decision can get stuck.

The second reason operates independently of formal sign-off: the raw speed of decisions. Even without a required approval step, the more people are tied to a given piece of the system, the more carefully you have to move. Any change potentially steps on someone else's area of ownership, and that slows things down on its own, with no formal review process involved. On a small team, where one person actually holds the entire system in their head, not just their own corner of it, a decision gets made on the spot, because there's no need to check whether it'll break something in a part someone else owns.

The third reason is less obvious: the architecture stays simple for longer. A large team has to lay down clear boundaries between modules from the start, simply because several people are working in different parts of the system at once and can't step on each other's toes. That's a reasonable safeguard, but it adds overhead: interfaces, contracts, coordinating changes at the seams. On a small team, where one person holds the whole picture in their head, those boundaries get drawn as they're actually needed, not preemptively just in case.

None of these three reasons has anything to do with AI. They were just as true in the nineties, and I covered in more depth what's actually changing in engineering work with the arrival of AI tools in the general piece on AI for developers. What used to cap a small team was simply the volume of work a couple of pairs of hands can physically do, and that's the ceiling AI is genuinely changing.

What changes once an agent joins the team

AI doesn't create these three advantages from scratch. It removes the ceiling a small team used to run into. A small team used to be fast but limited in volume, while a large team was slow but able to cover more work in parallel. An agent that absorbs a significant chunk of the routine volume shifts that balance: three people each working with an agent can now cover the volume that used to genuinely require about ten people.

It's worth naming what an agent doesn't solve. It doesn't turn one person into several specialists with different areas of expertise. A task that needs an engineer, client negotiations, and someone with domain knowledge all at once won't be covered by three agents standing in for three different people. The issue isn't the volume of routine work. It's a difference in expertise that an agent simply doesn't pick up just because it was assigned the task. AI amplifies exactly the advantage a small team already had going for it: speed on a uniform volume of engineering work. Wherever the bottleneck is fundamentally different kinds of expertise, not the volume of code, an agent doesn't make up for missing hands.

A personal case: Cruxly and Planio

I currently run two products, both of which I actually build alone, and both are a decent illustration of where this advantage genuinely holds and where it doesn't. With Cruxly, almost all of the product's value is tied to the quality of its AI functionality, and the agent literally writes a significant share of the code while I define the tasks and review. A feature that would've taken a dedicated backend developer a couple of weeks to hire for, I ship myself in a few days, because the entire scope is purely engineering and well specified.

Planio is a different situation. There, the difficulty isn't in the code. The product for the Russian market of field service techs, plumbers and electricians working on-site, has to fit a specific workflow, and most of the decisions come down not to the volume of code but to how well the interface and logic actually match how someone with no technical background works in the field between jobs. Here the agent speeds up the implementation itself, but it doesn't replace the time that still goes into talking to real technicians and checking that I actually understood their process correctly. The code gets written faster. Understanding what needs to be written in the first place doesn't get any faster.

Where the advantage stops working

Beyond the difference in the type of expertise needed, there's a less obvious cost to a small team working with an agent: it loses the built-in check that a team provides just by having other people around. On a three-person team, a strange decision usually gets caught on a call before it settles into the project. One person working with an agent can spend weeks moving in a direction the team would've stopped at the first discussion, simply because an agent defaults to going along with how the task was framed rather than pushing back on it.

The practical takeaway from all of this: a small team with AI doesn't win universally. It wins on a specific type of task, where the volume of engineering routine is large and the number of different kinds of expertise needed at once is small. It's worth estimating those two parameters at the start. Once a plan has already stalled, figuring out why costs more.

A sensible habit that partly compensates for the missing check: periodically show your decisions to someone outside the project, or directly ask the agent to poke holes in your own plan instead of just executing it, rather than counting on team size alone to guarantee good decisions.