In 1975, IBM veteran Fred Brooks published a book about a project he had personally run and watched fall behind schedule -- and instead of blaming the people on it, he named the actual mathematics of why adding more of them had made it worse, not better. "Adding manpower to a late software project makes it later" became known as Brooks's Law, and it still gets cited by name in engineering management fifty years on.[1]
Brooks gave three real reasons a bigger team doesn't produce proportionally more output: new people need real ramp-up time before they're productive, some tasks genuinely can't be split among more hands no matter how badly you want them to, and -- the part with an actual formula behind it -- every added person increases the number of communication channels the team has to maintain.[2] The number of channels grows by n(n-1)/2, where n is the team size: a team of 6 has 15 channels to manage. A team of 12 has 66. A team of 50 has 1,225.[2] Output scales roughly with the number of people. Coordination cost scales with the square of it. Past a certain size, the second number eats the first.
Brooks named a second, quieter constraint in the same volume: on a genuinely novel piece of software, the team building the first version almost never knows enough yet to build the right one. His actual advice, radical for a 1975 engineering culture built around detailed upfront specification: "plan to throw one away; you will, anyhow." Build a version specifically to learn from, expecting to discard it, rather than pretending the first attempt could be the last one.[1] Both constraints in the same book trace to the same root: you cannot buy your way past not knowing what to build, whether the missing knowledge is "how these people talk to each other" or "what this software actually needs to do."
What has actually changed since 1975 isn't either law -- it's the cost of obeying the second one, and that turns out to quietly defuse the first one too. Throwing away a working version used to mean months of engineer-hours, real enough that most teams did it once, reluctantly, and then stopped. AI-assisted building makes a real, working prototype -- something you can click through and immediately know is wrong -- achievable in an evening instead of a quarter. A recent newsletter piece put the same discipline plainly, from inside the practice of it: "the code can be disposable. the understanding carries forward."[3] That directly answers Brooks's second law: the cost of "plan to throw one away" collapsed. But it also answers the first law, from a different angle entirely: if one person, or a very small team, can build and discard fast enough to learn what to build, the team never has to grow past the size where n(n-1)/2 starts eating the gains. The modern fix isn't a better way to manage a large team's communication overhead. It's not needing the large team in the first place.
Why does this matter? Brooks wrote both laws from the losing side of a real, expensive failure, and fifty years of software management have mostly treated them as two separate lessons -- one about team size, one about specification discipline. They were never separate. Both describe the same underlying limit: knowledge that can only be produced by doing the work, not bought by adding more people or more planning in advance. The limit hasn't moved. What moved is how cheap it now is to hit it, learn from it, and start over -- cheap enough that a single person can run the loop Brooks once needed a whole failed team to teach him.
Companion pieces on this outlet: "Same AI Model, Same Question, Three Different Scaffolds..." and "Researchers Found 34 Million Distinct Concepts Wired Into One AI Model..."