02. Why Small Teams Will Beat Large Teams in the AI Era

The Ancient Curse of “The Mythical Man-Month”

In the field of software engineering, there is a decades-old bible called “The Mythical Man-Month”. The author, Brooks, proposed the famous “Brooks’s Law”: Adding manpower to a late software project makes it later. Brooks was discussing “human engineers” back then. Today, we are facing “AI-amplified engineers”.

This used to be a warning; in the AI era, it has become an instant death curse.

In the past, managers had an excuse: “Although communication costs have increased, at least there are a few more pairs of hands moving bricks.” But now, AI has turned every pair of “brick-moving hands” into “excavators”. When 20 people in a team are all driving AI excavators to frantically churn out code, what you face is no longer a shortage of manpower, but congestion at the construction site.

Scene: The Code Review Disaster on Monday Morning

Let’s look at a typical management moment:

It’s Monday morning, and a 10-person R&D team is holding a stand-up meeting. Over the weekend, 3 junior engineers, assisted by AI, each generated code equivalent to what used to be a week’s workload. They excitedly submitted Pull Requests (PRs). The Tech Lead sitting in the corner looks at the dozens of pending files on the screen, his eyes filled with despair. He finds that the AI-generated code logic seems perfect, but when handling an edge authentication logic, different people used completely different approaches, causing the current state of the system to look like a tangled mess.

This is the new problem brought by AI: The “linear acceleration” of individual output leads to an “exponential explosion” of coordination costs.

Why Communication Has Become the Biggest Cost

In the “Linear Acceleration Illusion”, managers believe: Since AI saves time for everyone, everyone should be more relaxed.

The reality is quite the opposite. AI accelerates the production of information but does not accelerate the absorption of information.

1. Surge in Code Density: Previously, an engineer wrote 200 lines of code a day, and teammates only took 10 minutes to understand it. Now they can generate 2000 lines a day, and teammates need to spend 2 hours understanding whether this pile of logic has side effects.
2. Dilution of Context: The more people in a team, the more fragmented everyone’s understanding of the system as a whole becomes. AI can quickly fill in details, but it cannot perform “context synchronization” for humans.

I once experienced a project where, due to tight deadlines, management decided to temporarily bring in another team to assist with development.

The intention was “more hands make light work,” but it turned into a nightmare. Although the new members were equipped with the best AI tools, they lacked an understanding of the business context. Empowered by AI, they quickly submitted a large amount of code. However, the core team found that this code was either reinventing the wheel or ignoring certain hidden business rules (such as handling legacy dirty data).

In the end, the core team had to spend more time meeting to synchronize, explaining why things couldn’t be written that way, and even refactoring code that “runs but isn’t right”. The project progress was actually slower than the original plan.

In the AI era, every communication within an organization is a tax on speed.

Redefining: Judgment Density > Sum of Labor

In the AI era, the core reason small teams can defeat large teams lies in “Judgment Density”.

• Large Team Mode: Relies on process to slice tasks. Product Manager -> Interaction Designer -> Frontend -> Backend -> QA. Everyone is just a link in the assembly line. AI here merely speeds up “tightening screws”, but doesn’t reduce the wait for “passing the screws”.
• Small Team Mode: Relies on Full Context. A team of 5 people, where everyone has a complete understanding of the business and the system.

When a person can complete full-stack development using AI, they no longer need to ask the backend “Are the API fields defined?”, nor do they need to ask operations “Is the test environment deployed?”.

They can define the fields themselves and deploy the environment themselves. What they save is not the time writing code, but the time “waiting for others to respond”.

5-8 People: The Golden Ratio of the New Era

Amazon’s Jeff Bezos once proposed the “Two Pizza Rule” (a team should not be larger than what two pizzas can feed). In the AI era, this number might shrink further, or unleash improved energy at this size.

The elite teams of the future will likely present such a structure:

• 1 Architect/Tech Lead (Responsible for System integrity and technical decisions)
• 1 Product Engineer (Responsible for Product value and user experience)
• 2-3 Full Stack Developers (Responsible for high-density execution and implementation)

They don’t need complex documentation handovers, or even daily meetings. Because the team is small enough, “common sense” is automatically synchronized within the team.

Conclusion: The Courage to Subtract

For managers, this might be counter-intuitive advice: If you want to speed up using AI, do not hire more people; instead, reduce the dependencies of the team.

In this era, the most luxurious resource is not computing power, nor manpower, but lossless consensus.

AI cannot solve the problem of “too many cooks spoil the broth”; it only makes the cooks argue faster.

So, please remember this sentence that might change your hiring strategy: In the AI era, the real advantage of small teams is the reduced cost of “explaining what you are doing”.