> One-line thesis: The curse of Brooks' *The Mythical Man-Month* still holds in the AI era, but AI has changed one key variable—it gives small teams the firepower that once only large teams possessed, fundamentally shaking the organizational logic of the software industry.
1. Core Claim: When 'Writing Code' Is No Longer the Bottleneck
> AI won't replace programmers, but organizational structure will.
To understand this, you must first understand software engineering's most famous curse: Brooks' Law.
2. The Eternal Curse of *The Mythical Man-Month*
2.1 Brooks' Law: Adding People to a Late Project Makes It Later
In 1975, Frederick Brooks wrote:
> "Adding manpower to a late software project makes it later."
Leading IBM's OS/360 project with thousands of engineers, Brooks fell into the "tar pit"—fixing one bug spawned more bugs. Why does adding people slow things down?
1. Training cost: newcomers need onboarding, pulling time from the existing team 2. Exponentially growing communication cost: an n-person team has n(n−1)/2 communication interfaces 3. Task sequencing constraints: many tasks cannot be parallelized
2.2 The Exponential Curse of Communication Cost
| Team size | Communication interfaces | Interfaces per person | |---|---|---| | 2 | 1 | 1 | | 3 | 3 | 2 | | 5 | 10 | 4 | | 10 | 45 | 9 | | 20 | 190 | 19 | | 50 | 1225 | 49 |
A 10-person team's communication complexity is 15× that of a 3-person team—not linear growth, exponential explosion.
Case in point: Balatro was built by a solo developer over 30 months and sold 5 million+ copies. Could 10 top programmers replicate it in 3 months? Impossible. Balatro's core asset is not code but the coherence of thousands of design decisions. Split one person's complete mental model across 10 people, and every move requires meetings, alignment, documentation, review—code can be copied, but conceptual integrity cannot.
2.3 Conceptual Integrity: Brooks' 50-Year-Old Prophecy
> Great designs come from great designers, not great committees.
A system's architecture must be led by one or a few people with a clear vision. Committee-designed systems inevitably produce redundant features, confused logic, and ugly interfaces.
3. AI's Real Change: Not 'Faster Coding,' But 'Making Big Teams Disappear'
> AI doesn't change the world by writing code faster, but by making large teams obsolete.
When a 3-person squad armed with AI tools (Cursor, Claude Code, v0, Lovable) matches a 10-person team's output, communication interfaces drop from 45 to 3.
| Activity | Traditional 10-person team | AI-empowered 3-person squad | |---|---|---| | Coding | 1 hour | 1 hour (coding was never the bottleneck) | | Communication/alignment | 7 hours | 2 hours | | Total | 8 hours | 3 hours |
The exact numbers may be debatable, but the structural insight holds: software's dominant cost is communication, not coding. IBM data shows programmers spend only ~50% of their time actually coding and debugging.
Why do small teams have an unfair advantage?
1. Feedback loop speed: decision → code → user feedback within hours 2. Manageable cognitive load: one person + AI can play the roles of Brooks' "surgical team"—chief surgeon, assistants, and toolmakers combined 3. Preserved conceptual integrity: 3 people can share one mental model; beyond ~5 people, it rapidly fragments
4. The Three-Layer Anatomy of Future Software Companies
Layer 1: Product Squads (~3 people)
Owning an entire product or feature end-to-end—from ideation to revenue. Characteristics: full ownership, fast closed loops, zero distance from users.
Real examples: Base44 (3 founders, acquired by Wix for $80M in 6 months); countless AI-era indie developers where one person + AI equals a former small studio.
Layer 2: Module Teams
When multiple squads need shared capabilities (payments, auth, recommendations), dedicated 3–8 person teams provide them via APIs. Unlike the heavily centralized "middle platform" (中台), module teams are agile internal arms dealers:
| Dimension | Traditional middle platform | Module team | |---|---|---| | Size | Dozens to hundreds | 3–8 | | Response speed | Quarterly scheduling | Weekly or daily | | User distance | Distant (layered requirement docs) | Direct (product squads are the users) | | Goal | "Unified standards" | "Solve specific problems" |
Layer 3: Infrastructure Teams
Servers, databases, compliance, security, deployment—the "air and water" layer. Decentralized enablement, security/compliance guardianship, cost optimization.
Why These Three Layers? Conway's Law in Reverse
Melvin Conway (1967): organizations design systems that mirror their communication structures. Traditional tree-shaped org charts produce monolithic, siloed architectures. The three-layer model applies Conway's Law in reverse: design the desired system architecture first, then build the organization to match—loosely coupled product squads, standardized API contracts to module teams, shared infrastructure underneath.
5. The Feynman Lens: A Counterintuitive Truth
Brooks said in 1975 there is "no silver bullet." Is AI the silver bullet?
No. But it enables something more important: small teams now have the firepower once reserved for big teams. The silver bullet question is "how to do things faster"; software's real bottleneck was never "doing" but "communicating." AI doesn't repeal Brooks' Law—it changes its scope of application. Since you no longer need big teams, the curse dissolves automatically. This is not technological progress; it is an organizational paradigm shift.
6. The Deeper Question: Organizational Structure as a Competitive Moat
When everyone writes code with AI, code itself stops being the differentiator. Differentiation lies in:
1. Decision speed: 2-hour alignment vs. 2-week scheduling 2. Conceptual integrity: unified mental model vs. committee design 3. User distance: direct feedback vs. filtered requirement documents 4. Experiment density: 3 iterations a day vs. 1 release a week
Organizational structure is shifting from a cost center to a competitive moat. Future software companies will be judged not by engineer headcount but by whether their structure can support many independent, end-to-end product squads—each one a startup machine.
References
- Frederick Brooks, *The Mythical Man-Month* (1975)
- Melvin Conway, "How Do Committees Invent?" (1967, Conway's Law)
- Balatro: solo-developed by LocalThunk, 5M+ copies sold in 2024
- Base44: 3-person team, acquired by Wix for $80M in 6 months