Zombie Coders: Why 100 Claude Code Subagents Are Worse Than 5

Justin Rich

Justin Rich

— 13 min read
Zombie Coders: Why 100 Claude Code Subagents Are Worse Than 5
In a world of code generated by AI sometimes 5 is more powerful than 50.

The Call is Coming from Inside the Codebase

Darkness falls across the land—well, more like a crisp October evening in Salt Lake City. The kind of night where the air feels charged, like the city itself knows something you don't. I'm sitting in a coffee shop that charges seven dollars for oat milk lattes—because apparently regular milk is for people who hate the planet—when it happens.

Across the room, my friend leans forward, eyes wide, pupils glowing with the manic light of obsession. The kind you only see in startup founders and people who believe they've "cracked AGI." He slides his laptop across the table like he's revealing a dead body.

"Check this out," he says. His voice trembles with excitement and caffeine. "I've got Claude Code running with fifty agents now… but I'm architecting it to scale to a hundred. Maybe a hundred fifty."

And that's when it hits me. That feeling. That slow, creeping dread that starts in the gut and crawls up the spine. The same one you get when the babysitter says, "I'll be right back," before walking into the dark basement.

Because I've seen this before.

Not once. Not twice. But enough times to know how it ends. The enthusiasm, the overclocked servers, the "don't worry, I've sandboxed it" reassurance that always precedes disaster. There's a pattern to it—a curse, maybe. The same haunted look. The same doomed confidence. The same end.

The agents whisper. The logs fill. The CPU trembles under the weight of ambition.

And somewhere, deep in the code, something begins to wake up.

You can almost hear it. A soft hum. The chorus of threads syncing in the dark.

The realization that no mere mortal can resist... the scaling of the Claude Code.

"Integration's going great," they add, a little too casually.

It isn't. It never is.

And that's how it starts.

The Curse of Past Failures (Or: The Ghost of Reorgs Past)

Here's what's wild—and by wild, I mean mathematically predictable and backed by 50 years of research—we already KNOW this doesn't work. Not like "we suspect" or "we think maybe." We KNOW. With numbers. From actual scientists who studied actual teams doing actual work.

J. Richard Hackman, the Harvard researcher who literally wrote the book on teams (it's called Leading Teams, very creative title), discovered something remarkable. In his foundational 1970 study published in Sociometry, Hackman and Neil Vidmar tested teams of 2-7 people on multiple tasks and found that optimal team size was 4.6 members (typically rounded to 5). By the time he published Leading Teams in 2002, he had refined this to a firm recommendation of 6 people and was so confident in this finding that he never allowed teams larger than 6 in his Harvard classes because he observed performance decline so consistently it might as well have been a law of physics.

And it gets better—or worse, depending on whether you enjoy watching preventable disasters unfold. Hackman found that for every person you add beyond seven members, you reduce decision effectiveness by approximately 10%. So by the time you hit a team of 17 people, your decision-making effectiveness is... let me do the math here... oh right, ZERO. Negative, actually. You're making negative decisions. You're un-deciding things that were already decided.

But surely that research is old, right? From back when we had to fight dinosaurs on our way to work?

Nope. QSM (Quantitative Software Management) analyzed 491 medium-sized information systems projects and found that teams of 5-7 people exhibited the best schedule performance with significantly less variation than larger teams. Not 50-70. Not 500-700. Five to seven. Individual humans.

The Marshmallow Challenge—a design exercise developed by Peter Skillman and popularized at Stanford, UC Berkeley, and other universities—demonstrated that coordination overhead kills performance. Teams of 4 people had to build the tallest freestanding structure using spaghetti, tape, string, and a marshmallow. Business school students spent their time on status management and planning. Kindergarteners just started building. The kindergarteners won. The math isn't mathing the way we want it to math.

And Lawrence Putnam's research, developed through his work at Quantitative Software Management and detailed in books like Measures for Excellence and Five Core Metrics, revealed that teams of 20+ people use 5 times more effort than teams of 5 or fewer for similar output. Not 20% more. Not double. FIVE TIMES MORE EFFORT.

This is like discovering that trying to put out a fire with gasoline makes it worse, writing detailed papers about it, teaching it in universities, and then watching people pour gasoline on fires while saying, "But this time it'll be different because I'm using premium gasoline."

The Math That Should Terrify You (The Exorcist, but It's Your Sprint Planning)

Let me hit you with some numbers that should make you wake up screaming in the middle of the night.

Communication paths in a team follow the formula n(n-1)/2. This isn't negotiable. It's not a guideline. It's math. Math doesn't care about your feelings or your ambitious architecture or that Medium article you read about "scaling DevOps."

Here's what this looks like in practice:

  • A team of 6 has 15 communication paths
  • A team of 12 has 66 communication paths—that's a 350% increase for doubling the team size
  • A team of 100 has 4,950 communication paths

Let that sink in for a moment. Four thousand, nine hundred, and fifty ways for information to flow, get lost, get misinterpreted, get duplicated, get contradicted, or get ignored entirely.

Each one of those paths is a place where an agent needs to understand what another agent is doing, maintain consistency with it, not contradict it, not duplicate it, and somehow integrate with it. Every single agent needs context about what every other agent is doing. And unlike humans, who can just forget about most of their coworkers (which is honestly a survival mechanism), AI agents keep trying to maintain consistency across the entire context.

Anthropic's research on multi-agent systems shows a 15× token increase for coordination overhead. That's not a typo. Fifteen times. Your coordination costs are eating you alive, and you're paying per token to be slowly consumed.

Jeff Bezos, who built Amazon into a company worth more than some countries' GDP, famously declared at a late-1990s management offsite that "communication is terrible." He wasn't trying to improve communication. He was trying to reduce it. Because Bezos understood something fundamental: communication overhead scales quadratically while productivity scales logarithmically at best.

Bezos introduced the Two-Pizza Team rule—no team should be larger than what two pizzas can feed, typically 6-8 people. And yes, before you ask, he meant American pizzas, not Finnish pizzas, because otherwise, you'd have teams of 2-4 people, which... actually might not be a bad idea.

But here's the kicker: In their book Working Backwards, former Amazon executives Colin Bryar and Bill Carr revealed that "despite the approach's initial success, few people inside Amazon actually talk about two-pizza teams." You know why? Because size alone doesn't guarantee success. They found that "the biggest predictor of a team's success wasn't whether it was small but whether it had a leader with the appropriate skills, authority, and experience to staff and manage a team whose sole focus was to get the job done."

So even Amazon, the company that pioneered this approach, discovered it's not just about having fewer people—it's about having the RIGHT number of people doing ONE focused thing. Which brings us to the existential question: what exactly are your 100 agents all focused on? And if the answer is "the same thing," congratulations, you've just invented the world's most expensive way to write spaghetti code.

The Industry Horror Show (Or: Every Company That Tried This and Lived to Tell the Tale)

Let's take a little field trip through Silicon Valley's organizational graveyard, shall we?

Google: Maintains an average team size of 7 across the company. Not 70. Not 700. Seven. Their Site Reliability Engineering teams require a minimum of 8 engineers for sustainable on-call rotations—that's the FLOOR for operational sustainability, not a suggestion to just keep adding people.

Spotify: Their famous squad model specified 6-12 people per squad, though typically less than 8. Henrik Kniberg's influential 2014 documentation emphasized that "alignment enables autonomy."

But here's the fun part: Jeremiah Lee, a former Spotify product manager, later revealed that "the famed squad model was only ever aspirational and never fully implemented," with coordination challenges increasing at scale. That's right—even Spotify's famous model that everyone copies DIDN'T ACTUALLY WORK AT SPOTIFY.

It's like if everybody started organizing their closets based on Marie Kondo's method, except Marie Kondo's own closet was just a pile of clothes with a motivational poster on top saying "These spark joy, probably."

Netflix: Champions the "Hackman max" of 10 engineers with extreme emphasis on seniority. Their infrastructure team maintained 10 very senior engineers (averaging 11 years of industry experience) under a single manager. Matt Marenghi scaled Netflix from 15 million to 220 million subscribers while maintaining small team structures.

Microsoft: The company that runs Windows, Office, Azure, and roughly half the enterprise software on the planet manages 100,000+ software engineers through standardized tooling while maintaining small team units. They figured out how to coordinate massive scale without massive teams. It's almost like they learned something from their research.

Apple: Engineering managers typically manage 3-5 full-time employees plus contractors. Their philosophy: "If every contractor left tomorrow, the core team must still ship." Products like the iPhone require 40+ specialist teams collaborating, but each core team remains deliberately small.

Notice a pattern here? The most successful tech companies in the history of capitalism—companies that have collectively created trillions of dollars in value—all converged on the same answer: 3-8 people per team. This isn't a coincidence. This isn't culture. This is math expressing itself through organizational structure.

Conway's Law for AI (The Entity in the Architecture)

Here's where it gets really spooky: Conway's Law.

Melvin Conway observed in 1967 that "organizations design systems that mirror their communication structure." This isn't a suggestion or a tendency—it's basically inevitable. Your org chart becomes your architecture.

So if you have 100 agents, you're going to get a 100-component architecture. Regardless of whether that's the RIGHT architecture. Your code will look like your agent team structure because that's how information flows.

And here's the thing about 100-component architectures: they're called "distributed monoliths," and they're what happens when someone reads a blog post about microservices after three beers and decides to apply it to everything. The industry spent the entire 2010s learning this lesson. We have the scars. We have the therapy bills.

The microservices movement promised us infinite scalability and organizational flexibility. What it delivered was YAML files, Kubernetes configs nobody understands, and 3 AM pages because Service #47 can't talk to Service #48, and nobody knows why because the engineer who wrote that integration quit six months ago to join a crypto startup.

Each of your 100 agents is going to write code in its own style, with its own error-handling patterns, its own logging approach, its own assumptions about data formats. Integration is where you'll die. Death by a thousand merge conflicts.

Brooks' Law states: "Adding more people to a late project makes it later." This happens because of the communication overhead we already discussed. But there's a corollary that nobody talks about: adding more agents to a complex system makes it more complex, not more capable. You're adding entropy. You're adding surface area for bugs. You're adding integration points that all need to be tested, maintained, and debugged.

And unlike humans, who eventually just stop talking to each other (blessed, blessed organizational dysfunction), AI agents keep trying. They keep attempting to maintain consistency. They keep processing context. They keep burning through your token budget like it's VC money in 2021.

"But we have the compute, we can afford to throw 100 agents on a task."

You can also afford to solve a nail problem with a wrecking ball. The question isn't whether you can—it's whether you should. Because what you're actually affording is 15× token overhead for coordination, merge conflicts that would make Git weep, and the special joy of debugging integration failures at 2 AM when you discover that Agent #73 has been hallucinating data consistency since Tuesday. Compute is cheap. Fixing a 100-agent coordination disaster is not.

The Agent Team Death Spiral (Choose Your Own Disaster)

Let me walk you through how this plays out in practice, because I've now watched this movie enough times that I can predict the plot beats:

Month 1: The Honeymoon Phase

  • "Look at all these agents working in parallel!"
  • "We're generating code faster than any human team could!"
  • "This is the future of software development!"
  • Narrator: It was not the future. It was the past, with more API calls.

Month 2: The First Cracks

  • "Why do we have three different error-handling patterns?"
  • "Which agent is responsible for the authentication flow?"
  • "Why is the API endpoint expecting JSON but the frontend is sending XML?"
  • The Slack channel goes quiet. This is not a good sign.

Month 3: Integration Hell

  • "We need an integration team to coordinate the agents"
  • "We need more agents to manage the agents"
  • You have accidentally recreated middle management, but with worse documentation
  • Someone suggests a "coordination agent." You realize you've just invented a bureaucracy.

Month 4: The Pivot

  • "Maybe we need to simplify the architecture"
  • "What if we reduced to 20 agents?"
  • "What if we reduced to 8 agents?"
  • "What if we just... wrote it ourselves?"
  • You have learned the lesson, but at what cost?

The research is unambiguous here. Teams above 10 members experience coordination overhead exceeding productivity benefits. This isn't opinion. This isn't preference. This is empirical observation across thousands of teams over decades of research.

Bernerth et al.'s 2023 meta-analysis examined 208 studies with 21,435 teams and found that team size showed a relationship of ρ̂ = .10 with task performance—barely positive—and ρ̂ = .20 with counterproductive work behaviors. Translation: larger teams don't work better; they work worse in more creative ways.

The Correct Answer (That Everyone Ignores Until They Learn It the Hard Way)

Okay, so you're convinced. Or at least, you're scared. Good. Fear is healthy. Fear keeps you from petting strange dogs and architecting 100-agent systems.

Here's the decision tree:

Single Agent (1 agent)

  • Well-defined, bounded tasks
  • You know exactly what you want
  • Example: "Write a function that validates email addresses according to RFC 5322"
  • This works great for isolated problems

Small Agent Team (3-5 agents)

Medium Agent Team (6-8 agents)

Large Agent Team (9+)

  • Red flag territory
  • This is where you should hear horror movie music
  • If you think you need this, you probably need to rethink your problem decomposition
  • The question isn't "how do I manage 50 agents?" it's "why am I trying to build one thing with 50 agents?"

The "100 Agent" Trap

  • Congratulations, you don't have a software problem
  • You have an architecture problem
  • You need to decompose your problem into smaller problems
  • Build 10 things with teams of 5, not 1 thing with a team of 50

The math is unforgiving. Lawrence Putnam's research showed that teams of 20+ people use 5 times more effort than teams of 5 or fewer for similar output. FIVE TIMES. That's not rounding error. That's not margin of error. That's "you're doing the wrong thing" error.

The Real-World Body Count (Actual Examples That Actually Happened)

Case Study 1: The Solo Founder Who Kept It Simple

My buddy Alex—real person, real project, currently in production—is building a SaaS app with Claude Code. His team:

  • 1 architect agent (designs the approach, makes high-level decisions)
  • 1 implementation agent (writes the actual code)
  • 1 test/debug agent (catches problems, writes tests)

Total: 3 agents. That's it.

Result: Shipped MVP in 2 weeks. The code is coherent. It's maintainable. It actually works. When something breaks, he knows exactly which agent was responsible because there are only three of them. Code reviews are possible because the surface area is manageable. The agents aren't spending half their context window trying to figure out what 97 other agents are doing.

Most importantly: the integration overhead is 3 communication paths (agent A to B, B to C, A to C). That's it. He can hold the entire system in his head.

Case Study 2: The Startup That Learned About Gravity by Jumping Off a Building

Different friend, ambitious AI-native company. They architected an elaborate 50+ agent system. Each agent owns a "microservice" in their distributed architecture. They had agents for:

  • User authentication
  • User authorization
  • User profile management
  • Password reset flows
  • Email verification
  • Session management
  • Token refresh
  • [... 43 more services ...]

Three months in: Integration hell. Nobody knows what anyone else is doing. Code reviews are impossible—there's too much surface area. Every change breaks something in an unexpected place. They have merge conflicts that would make Tolstoy say, "Okay, that's too long."

They spent 90% of their time coordinating agents and 10% actually building features. This is the exact inverse of what you want.

Six months in: They reverted to a 5-agent core team focused on a monolithic architecture. Within two weeks, they shipped more features than the previous two months combined.

The coordination tax always comes due. Always.

The Platform Approach (Or: How to Not Repeat Everyone Else's Mistakes)

Here's the secret that successful companies figured out: you don't build one 100-agent team. You build 10 teams of 5 agents, with clear interfaces between them.

Apple does this with the iPhone: 40+ specialist teams collaborating on shared purpose, each maintaining core teams of 3-5 people. They don't have a 200-person iPhone team. They have 40 small teams that coordinate through well-defined interfaces.

Each team ships a complete, working module. Integration is deliberate, not emergent chaos. You can reason about the system because it's actually designed, not accidental.

The decision framework:

  1. Can the problem be clearly decomposed into independent parts? → Multiple small agent teams working on separate modules
  2. Is it genuinely indivisible and requires tight integration? → Single small agent team of 3-8 agents
  3. Are you planning 100+ agents? → You haven't decomposed the problem enough; back to step 1

Think platforms, not armies. Think modules, not monoliths. Think focused teams, not coordination overhead.

Wu et al.'s Nature research demonstrates that disruptive innovation requires small teams, while established idea development can benefit from larger teams. Translation: small teams (3-6 agents) for building new things, slightly larger teams (8-12 agents) for scaling things that already work, and platform teams providing shared services to reduce coordination needs.

The Horror Movie Ending (Spoiler: The Call Was Coming from Inside the Architecture)

Look, I get it. The promise of 100 agents all working in perfect harmony is seductive. It's like that scene in every horror movie where the teenagers decide to split up to cover more ground. Technically, it's logical. Practically, it's how people die.

The math doesn't lie:

  • Communication paths grow as n(n-1)/2
  • Coordination costs grow quadratically while productivity grows logarithmically
  • Every person (or agent) beyond 7 reduces decision effectiveness by 10%
  • Teams of 20+ people use 5 times more effort than teams of 5 or fewer

Your 100-agent coding army will fail for the same reasons every large team fails: coordination costs compound faster than productivity scales. This isn't a people problem. This isn't a tool problem. This is a math problem, and math is undefeated.

The good news? You can learn from fifty years of organizational research and a decade of microservices disasters. You can choose to start small. You can choose focused teams over sprawling armies. You can choose working software over architectural complexity.

Or you can plan for 100+ agents and learn the hard way. Either way, you'll end up at 3-8 eventually. Might as well start there and save yourself the therapy bills.

The call was coming from inside the codebase all along. The monster wasn't the technology—it was the coordination overhead. And unlike horror movie monsters, coordination overhead can't be defeated with a well-placed chainsaw. Only with better architecture.

Start small. Stay small. Ship fast.

Or don't. Your 4,950 communication paths and I will be here when you're ready to talk.

Happy Halloween. Try not to scare yourself with your own org chart.

Read more