There is now a widely held belief among managers that you can scale up your engineering team by simply adding more AI agents. They believe if they gave engineering team of 10 people each 20 agents, then suddenly their team of 10 people can now do the work of 200. There is this idea that agents are both like people but not people. That they are somehow maybe even super human in their engineering and coding ability. All the 10 real humans actually need to do is simply tell each of their 20 agents what to do and the speedup of that one person will be 20x. Jensen Huang believes Nvidia's workforce will nearly double from 42,000 to 75,000 people and that each of these people will have 100 AI agents working for them. So he is imagining his company will grow to 7.5 million "workers", a 200x increase from its current size.
I've been programming by hand for 30 years, but haven't written code by hand since December 2024. I have scaled to use about 4 agents at any given time, which seems small to the tokenmaxxing crowd. This gave me about an 8.5x speedup over my manual coding. I analyzed the data in my repositories before December 2024 and after and went from shipping about 14k lines of code per month to over 70k net new. So you would think if I doubled to using 8 agents I would produce 140k lines of code. Instead I would actually produce ** LESS** code, only about 67K per month!
How Can Adding More Make Less? #
How can adding more resources to a task slow it down? AI Agents in theory can work quickly and intelligently with less human input as the models get smarter. I mean, I've seen this with my own use of agents. In the beginning I would just use LLMs as a fancy auto complete. I then started having them write whole functions. Then whole files. I would have to manage the context myself before coding agents like Claude came on the scene. And even when Claude showed up, it didn't do a great job of context management. However as the models got better and the harnesses got better, I found myself letting them do more, for longer, without my interjections and input. I found myself reviewing less code and providing less guidance on algorithms. For anyone who saw this kind of progress, it's easy to believe you can just add a bunch of them and scale yourself up 10x, 20x, and (as Jensen believes) 100x!
To understand why adding more can make less, we need to understand the Gunther's Universal Scalability Law. However, before we explain the USL, let's look at a simpler model called Amdahl's Law.
There is a Maximum Speed Limit: Amdahl's Law #
In the 1960s, computers were incredibly expensive and large. They cost millions of dollars and were the size of refrigerators. Around 1967, Daniel Slotnick led the design of a supercomputer called the ILLIAC IV. This machine was massive at the time and had 64 separate computer processors. This was an exciting machine because people thought, if one processor is fast, then 64 processors working together will make everything 64 times faster.
Gene Amdahl was a legendary computer architect at IBM who designed the IBM System/360 mainframe. He realized that real-world programs don't actually scale that way. At the 1967 Spring Joint Computer Conference (AFIPS), Amdahl presented a paper titled "Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities". It's a very short paper where Amdahl showed a mathematical proof. Every program has a serial fraction (Sigma) which are steps that must happen after one another in order. He showed that there is a maximum amount you can speed up such a program with a very simple formula
Max Speedup = 1 / Sigma
In other words, let's say 5% of a task is serial, then the maximum speedup you can do for the overall task is 20 times (1 / 0.05 = 20).
Amdahl's law was an inconvenient truth. It showed the computer industry that throwing more hardware at a problem gives diminishing returns.
Let's first look at non-computing example. Imagine you are baking a batch of chocolate chip cookies. The whole job takes 20 minutes. About 10 minutes to mix the dough and shape the cookies. Another 10 minutes to bake them in the oven. Now imagine you invite 10 friends to help you. Making and shaping the cookies can easily be split up among the 10 people and it should take you only 1 minute instead of 10 to prepare them for baking. However, the cookies still have to sit in the oven for 10 minutes to bake. The whole job now takes 11 minutes instead of 20. So what if we invite 100 friends instead? Well, you can certainly shape more cookies in 1 minute but you cannot make the oven 10 times hotter without burning the cookies. So in this baking example, the best you could ever do is close to 10 minutes no matter how many people you invite. You can invite a million people and it will still take 10 minutes to bake.
Amdahl's law essentially means that no matter how many helpers you add, your total speed will always be limited to the part of the job that cannot be shared.
In our example, the time it took before we added more people to bake was 50% (10 minutes to shape and 10 minutes to bake). The only part we can optimize is the 10 minutes to shape. So we plug in 0.5 as sigma and get
Max Speedup = 1 / sigma = 1 / 0.5 = 2 So in our case, the most amount of speedup we can achieve in baking cookies over a single person is 2x better, no matter how many people we add.
We Can't Go Slower Right? #
Amdahl's law is admittedly a very simple model. It captures a maximum speed limit to any given task. However, this model doesn't explain why we can go slower by adding more helpers. To understand that we need a new model, a model that captures finer details about how tasks are done.
In the 1990s, engineers discovered something unexpected, as they added more CPUs to servers, throughput would peak and then drop off a cliff. This is unexpected because Amdahl's Law predicted they would get marginally faster, with diminishing returns. They didn't expect performance to degrade.
In the 90s, computer makers like Sun Microsystems and Silicon Graphics started building enterprise servers with multi processors. These machines had 16, 32, and even 64 processors that shared the same memory bus. Enterprises were running Oracle and wanted to speedup database processing. When companies started benchmarking these servers under heavy database load, they saw something surprising. Throughput would peak around 8 and 12 processors and then drop off a cliff. A 32-CPU machine was much slower than an 8-CPU server. Not a great result for these computer makers.
The Australian computer scientist Neil J. Gunther, who had worked at Xerox PARC and later Pyramid Technology, wanted to understand why. Gunther had realized that computer processors don't just do independent computation, they must also have cache coherence. When one processor changes data in memory, it must send a message to invalidate the cache over the shared bus to the other processors. The message was "I changed this part in memory, throw away your local copy". As more processors were added, the shared bus became jammed up, with CPUs sending messages back and forth just to keep the memory in sync.
Gunther would later formalize what he found in his 1998 book "The Practical Performance Analyst". He unified Amdahl's Law which modeled contention and added Alan Cobham's queuing theory of pairwise coherency into one formula.
C(N) = N / (1 + sigma * (N-1) + kappa * N(N-1)) This formula explains why additional workers could cause retrograde scaling. Where adding workers slows down the system. Sigma here is the same sigma in Amdahl's Law. Kappa is the percent time spent "stepping on each others toes". If you set Kappa to zero, you end up with Amdahl's Law. Kappa is the part that models "cross talk" which is how you get a slow down.
Let's go back to our cookie baking example. Remember, it takes you 10 minutes to make the dough and shape the cookies and 10 minutes to bake. No matter how many friends you invite, you can't shorten the 10 minute baking time. So the maximum speedup you can have is 2x.
Now imagine what happens in real life if you invite 50 friends into a tiny kitchen. Your friends will start bumping into each other (having some drop dough on the floor they have to clean up). They are all yelling over each other. Everyone spends more time talking, apologizing, and cleaning up spills than actually making dough.
If you have 4 friends, you can finish in 11 minutes (1 minute to make the dough, 10 to bake). If you invite 50 friends, it could take you 60 minutes instead (50 minutes to make the dough, 10 to bake). You end up being slower than if you just did it all yourself. That's what Kappa is capturing, it's capturing the interference each worker has on the other. You can summarize Gunther's Universal Scalability Law as:
When workers have to talk to each other and share space, adding too many workers doesn't just hit a ceiling like in Amdahl's Law, but it can actually make the whole team slower.
Why 8 Agents Would Slow Me Down #
The USL isn't just an abstract equation. Here is how it applies to my setup. I'm not making any claims the way I work is optimal. I have clearly optimized to reduce code coherency problems but cost myself context-switching overhead.
In my own workflow, I pair tightly with coding agents across about 4 different repositories. I run a baseline fleet of 4 concurrent agents, one per repository. I can consistently ship about 70k lines of tested production code per month.
Setup: Longitudinal dataset across 4 repositories multiplexed via tmux.Architecture: Independent repositories eliminate code collisions so Kappa is pure human cognitive context-switching. I set my Kappa at 3.2%. I calculated my Sigma at 12% based on real commits and agent history. This is the percent of time spent planning and reviewing.Manual Baseline & LOC Expansion: Analysis establishes that the ~8.5× overall velocity multiplier (and 4.8× net LOC expansion from ~14.7k to ~70.4k net LOC/month) is measured against a high full-time manual baseline (102.7 commits/month, 4.87 commits/active day across 2019–2021).USL Dynamics:- sigma = 0.12
- kappa = 0.032
- implies optimal N* approx 5.2..
- Multiplexing 3–4 sessions yields 2.36x speedup over single-agent.
So if I plugin this baseline into the USL equation I get
C(4) = 4 / (1 + 0.12*3 + 0.032 * 4 * 3) = 2.29x Now if I double the number of agents to 8 I get
C(8) = 8 / (1 + 0.12*7 + 0.032 * 8 * 7) = 2.20x In other words, simply doubling my agent count will slow me down with my current setup. The slowdown happens from my context switching costs. I would have to change my current setup to increase my agent capacity.
Is Your Agentic Team Slowing Down? #
You will be reading a lot of people claiming to use 40 agents, 100 agents, maybe even 1000 agents. When you hear this you need to ask yourself if they are getting the benefit they think they are. Maybe you are also using multiple agents, you might then wonder how many more can you add before you start slowing down.
There are 3 variables you need to know to figure this out.
- Productive Work (N): How many helpers are doing useful independent work?
- Waiting in Line (Contention or Sigma): Waiting over one shared resource. This is the serial bottleneck.
- Chattering and Bumping into Each Other (Coherency or Kappa): The time helpers spend keeping each other updated and fixing mistakes from others.
Let's go over these one by one with examples.
Productive Work (N)
You first need to understand if the work and tasks you have can be done independently. For example, let's say you have 5 features to implement, you might decide you can do this with 5 agents. Some people make the mistake of having a fixed amount of agents, but it should be clear by now it depends on the work you actually need done.
Waiting in Line (Contention or Sigma)
There are some tasks which need to wait for some shared resource. Often in agentic coding this is the person. For example, a person typically does planning before tasks are allocated. A person might do final review and testing. Agents might ask questions to the person to get unblocked. All of these are contention around a shared resource (you).
Chattering and Bumping into Each Other (Coherency or Kappa)
Let's say you have 2 features that need to be implemented. Both of those features might modify the same shared module. Agent A modifies the shared module one way, and Agent B modifies it another way. Changes from A cause problems for changes from B. The agents must negotiate with each other and figure out a solution that works for both of them. In other words, not all tasks are completely independent. If you have 10 agents that made 10 PRs, you will get merge conflicts in some places in the code that need to be resolved. It's this mess that causes the retrograde scaling.
Agent Scaling Calculator #
Now that you know why adding more agents can slow you down. I created a calculator you can use to figure out how many agents you can do until adding more slows you down. Figure out your contention (sigma) and coherency (kappa) and the calculator will give you the total number of agents you should be running. Maybe you are using too little or too many today!
12
Max's Agentic Engineering Guidelines #
Understanding the Universal Scalability Law isn't an argument against using AI agents. It's a framework for understanding how to optimize any workflow (agent or not). If you want to run more agents without hitting the USL wall, simply throwing more compute at the problem won't help. You have to re-architect your development environment and processes to drive down both contention and coherency. There is no free lunch however. You can only drive down these so far for a particular problem without serious quality problems.
To maximize fleet throughput, you have to actively manage three things.
Partition Boundaries
Coherency between workers explodes when they have to touch shared resources like files, state, and branches. If you have multiple agents working on a single repository, use worktrees to isolate workspace boundaries. Ensure the software architecture is sound. The architecture will dictate coherency. Decoupled components can be worked on in parallel. However you can't decouple everything otherwise you don't have a system, but a bunch of independent bits. If two agents require frequent cross-communication to complete a task, merge them into a single role or run them serially.
Don't Exceed the Concurrency Knee
Every architecture has a mathematically optimal concurrency limit. This is the speed limit of the project. Use the calculator to figure out what that could be. Operating beyond the speed limit will degrade your velocity and flood you with broken PRs and more junk to review.
Streamline the Serial Work
Even if you eliminate all coherency issues and Kappa is zero, serial work like planning, review, and test will limit your speedup. Understand the hot spots and critical parts of the system and only review PRs touching it. Don't worry about the PR that changes the color of a button. Create detailed plans where you have a strong opinion, point of view, and domain knowledge and expertise. Again, no need to have a detailed plan for a change to a button color. There is only so much you can streamline before you start losing a significant amount of quality.
Conclusion #
Agentic scaling (or any scaling for that matter) isn't just about tokenmaxing. It's about how cleanly your system allows those agents to work in isolation without stepping on each other all the time. This requires expertise in the problem domain, a keen eye for good architectural decisions, and measuring well. Coding is the easy part of writing software, it's everything else that takes the most amount of time.
Sources & References #
Amdahl, Gene M. (1967)."Validity of the single processor approach to achieving large scale computing capabilities."AFIPS Conference Proceedings, Vol. 30, pp. 483–485.Gunther, Neil J. (2007).* Guerrilla Capacity Planning: A Tactical Approach to Managing Systems for Optimum Performance*. Springer (Formulation of the Universal Scalability Law /The Practical Performance Analyst).Huang, Jensen (2026). Keynote & Interview on autonomous AI agent scaling in the enterprise workforce.Fortune(March 19, 2026).Benioff, Marc (2024). Keynote address on enterprise AI agents, Agentforce, and human-agent fleet dynamics.