> One-line thesis: **The curse of Brooks's *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 had, 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's Law.
2. The Eternal Curse of *The Mythical Man-Month*
2.1 Brooks's 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 over a thousand engineers, Brooks fell into the "tar pit" during integration — fixing one bug triggered more bugs.
Why does adding people slow things down?
1. Training cost: newcomers need onboarding time from the existing team 2. Exponential communication cost: an n-person team has n(n-1)/2 communication channels 3. Task sequencing constraints: many tasks cannot be parallelized
2.2 The Exponential Curse of Communication Cost
| Team size | Communication channels | Channels per person | |---|---|---| | 2 | 1 | 1 | | 3 | 3 | 2 | | 5 | 10 | 4 | | 10 | 45 | 9 | | 20 | 190 | 19 | | 50 | 1225 | 49 |
A 10-person team has 15x the communication complexity of a 3-person team. Not linear — exponential.
A persuasive case: Balatro's solo developer spent 30 months and sold over 5 million copies. Could 10 top programmers replicate it in 3 months? Answer: impossible.
Not because 10 programmers aren't skilled, but because Balatro's core asset isn't code — it's the coherence of thousands of design decisions. A single chess game played in one mind, split among 10 players, requires meetings, alignment, documentation, and reviews at every move. Code can be copied; a design's conceptual integrity cannot.
2.3 Conceptual Integrity: Brooks's 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 end up with redundant features, muddled logic, and ugly interfaces. Conceptual integrity decays sharply once a team exceeds ~5 people.
3. AI Changes Not "Writing Code" but "Making Large Teams Disappear"
3.1 From "Writing Faster" to "Needing Fewer People"
> AI doesn't change the world by writing code faster — it triggers a revolution by making large teams disappear.
When a 3-person squad armed with AI tools (Cursor, Claude Code, v0, Lovable) matches the output of a 10-person team, the communication topology changes fundamentally: not "10 people each 2x faster" but "3 people doing 10 people's work" — channels drop from 45 to 3.
3.2 Coding 1 Hour + 7 Hours Aligning → Coding 1 Hour + 2 Hours Aligning
| Activity | Traditional 10-person team | AI-enabled 3-person squad | |---|---|---| | Coding | 1 hour | 1 hour (AI-accelerated, but coding isn't the bottleneck) | | Communication & alignment | 7 hours | 2 hours | | Total | 8 hours | 3 hours | | Efficiency gain | baseline | ~230% |
The exact numbers are debatable, but the structural insight is sound: software development's dominant cost has never been coding — it's communication. IBM data shows programmers spend only ~50% of their time actually coding and debugging; the rest goes to meetings, docs, coordination, and waiting.
3.3 Why Small Teams Hold the Unfair Advantage
1. Feedback loop speed: hour-level "decision → code → user feedback" loops vs. scheduling/review/deploy pipelines. 2. Controllable cognitive load: Brooks's "surgical team" model taken to its extreme — one person with AI tools wields the power of surgeon + assistants + toolmith + documenter. 3. Conceptual integrity preserved: 3 people can share one unified mental model; 10 people's models inevitably fragment.
4. The Three Layers of the Future Software Industry
Layer 1: Product Squads (~3 people)
> They own an entire product or feature — from idea to revenue, end to end.
The AI era's minimal fighting unit: one product/design, one engineering, one growth/ops (or one person wearing multiple hats).
- End-to-end ownership: not "hand code to QA" but "responsible from idea to revenue"
- Fast loops: decision authority stays inside the squad
- Zero user distance: no "PM translates requirements" information loss
- API-first: they deliver service interfaces, not codebases
- Multi-tenant: one module serves many squads
- Self-operating: accountable for their own service quality
- Decentralized enablement: provide platform capability without controlling usage
- Security and compliance floor: data privacy, legal compliance, audits
- Cost optimization: centralized cloud procurement and utilization
- Product squads need loose coupling → they must be organizationally independent
- Squads and module teams need standardized interfaces → module teams must exist
- Everyone needs shared底层 capabilities (security, compliance, infrastructure) → infrastructure teams must exist
- Frederick Brooks, *The Mythical Man-Month* (1975)
- Melvin Conway, "How Do Committees Invent?" (1967, Conway's Law)
- Balatro: developed solo by LocalThunk, 5M+ copies sold in 2024
- Base44: 3-person team, acquired by Wix for $80M in 6 months
Real cases: Base44 — 3 founders, acquired by Wix for $80M in 6 months; countless AI-era indie developers where one person + AI = a former small studio.
Layer 2: Module Teams
> When multiple product squads need a shared capability — payments, login, recommendation algorithms — a dedicated module team provides it. Their users are other squads.
Internal infrastructure "arms suppliers" — not company-wide "middle platforms" (too centralized, slow to respond), but lean teams focused on specific capabilities.
| Dimension | Traditional middle platform | Module team | |---|---|---| | Size | Tens to hundreds | 3–8 | | Response time | Quarterly scheduling | Weekly or daily | | User distance | Distant (layers of requirement docs) | Direct (squads are the users) | | Goal | "Standardization" | "Solving specific problems" |
Layer 3: Infrastructure Teams
> They manage what everyone shares: servers, databases, compliance, security, deployment. They don't build products, but no product survives without them.
Like "air and water" — invisible until absent.
4.4 Why These Three Layers? Conway's Law in Reverse
Melvin Conway (1967): organizations design systems that mirror their communication structures.
Traditional software companies are tree-shaped (CEO → VP → director → manager → engineer), so their architectures are tree-shaped: monoliths, layers of encapsulation, department walls.
The three-layer model applies Conway's Law in reverse: design the desired system architecture first (small autonomous products + shared modules + unified infrastructure), then design the organization backward.
5. The Feynman View: A Counterintuitive Truth
> Brooks said in 1975 there's "no silver bullet" — no single technology yielding an order-of-magnitude productivity gain. > > 50 years later, AI arrived. Is it the silver bullet? > > No. But it enabled something more important: it gave small teams the firepower only large teams once had. > > The silver bullet question is about "doing faster." But software's real bottleneck was never "doing" — it's "communicating." AI doesn't repeal Brooks's Law; it changes the law's scope — you no longer need a large team to build a large product. Once you don't need large teams, the curse lifts automatically. > > This isn't technological progress — it's an organizational paradigm shift.
6. A Deeper Question: When Organization Becomes the Moat
When everyone writes code with AI, code itself is no longer the differentiator. Differentiation lies in:
1. Decision speed: 3-person squad aligns in 2 hours vs. 10-person team schedules in 2 weeks 2. Conceptual integrity: unified mental model vs. fractured 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.
The software companies of the future won't win by headcount, but by whether their organizational structure can support enough independent product squads — each one an end-to-end startup machine.