Brooks's law prices coordination, and AI code generation moved the bill to review

In chapter 2 of The Mythical Man-Month, which Addison-Wesley published in 1975, Frederick Brooks works through a piece of arithmetic worth redoing. A task is estimated at 12 person-months and given to three people for four months, with a checkpoint at the end of each month. The first checkpoint is reached only after two months. The standard managerial reflex is to add people, so suppose two more join. Brooks counted what that costs. If an experienced person spends a month training the newcomers, that month plus the newcomers' own month adds up to three person-months spent on work that was not in the estimate. The task that had been split three ways must now be split five ways, and some finished work is lost in the repartitioning. By the end of the third month, he wrote, substantially more than seven person-months of work remain, and five trained people have one month left to do it. The project is late again, now with five people on it, and repeating the move, he added, is where madness lies.

The one-line summary, that adding manpower to a late software project makes it later, has been quoted for fifty years as if it were a prohibition. I think that reading is wrong, and Brooks supplied the correction himself in the sentence that introduces the law, which begins "Oversimplifying outrageously". The arithmetic itemizes a bill with two lines, ramp-up and communication, and lists the conditions under which that bill stays small. A manager who reads it as "never add people" will refuse a hire that would have paid for itself. A manager who ignores it keeps paying a bill nobody has itemized.

My argument has three parts. First, the n(n-1)/2 formula that everyone remembers counts possible pairs. The bill depends on how many of those pairs are active and what each active one costs. Second, AI code generation lowers the cost of writing code and leaves the cost per channel where it was, or raises it, because the busiest channel in a modern team now runs through a person who reads changes. The coordination did not go away; it moved to review and integration. Third, and this is the part a reasonable person could dispute, the team size that finishes a piece of work fastest gets smaller as writing gets cheaper relative to reviewing. I test that last claim with a toy model whose numbers I made up and with the telemetry that exists. The telemetry is mostly vendor data, and it leans one way without settling the matter.

The law prices two costs and names the case where neither applies

Brooks starts from the man-month as a unit of work and argues that it hides an assumption, that people and months trade evenly. They do so only when a task can be partitioned among many workers with no communication among them, and his examples are reaping wheat and picking cotton. When a task cannot be partitioned because of sequential constraints, extra people do nothing for the schedule, and he says many software tasks are like this because debugging is sequential. In between sits the case that matters: tasks that can be partitioned but whose parts must talk to each other. There the added effort has two components. Training is linear in the number of people, since each newcomer has to learn the technology, the goals, the strategy and the plan. Intercommunication grows as n(n-1)/2, so three workers need three times the pairwise communication of two, and four need six times. If the work also needs meetings of three or more people to settle things, he says, matters get worse yet.

Two limits in the same text are quoted less often than the law. The number of months a project takes depends on its sequential constraints, and the maximum useful number of people depends on the number of independent subtasks. Staffing also cannot grow at any speed: in his notes to the chapter Brooks cites V. A. Vyssotsky of Bell Telephone Laboratories, who estimated that a large project can sustain a manpower build-up of 30 percent a year, and that more than that strains the informal structure through which people find each other. Both limits depend on the shape of the work, whatever the headcount.

Later researchers turned the idea into a formula. Di Penta, Harman, Antoniol and Qureshi (2007) wrote completion time as t = e/n + ce × n(n-1)/2, where e is total effort, n is team size and ce is the average effort for one pair to coordinate. For a perfectly partitionable task the second term vanishes and Brooks's law does not apply. For a task that cannot be partitioned, nothing helps. Between the two the curve has a minimum, and beyond it every added person lengthens the schedule. Their analysis of two real maintenance projects led them to conclude that the effect is subtle and may be less harmful where team construction is flexible. Its one coordination parameter, ce, is what makes the model useful, because it turns the law into a question about where on a curve a team sits.

Possible pairs are not active channels, and the difference is design

The pair count grows quickly. Six people have 15 possible pairs, ten have 45 and fifteen have 105. In a 2009 Harvard Business Review interview with Diane Coutu, J. Richard Hackman said that he and a colleague had found the links among team members rising at an accelerating, almost exponential rate, that his rule of thumb is "no double digits", and that in his courses he never allows teams of more than six students. Pair counts grow quadratically, so "exponential" was a loose word in a spoken interview. The Scrum Guide of 2020 sets the size of a Scrum team at typically 10 or fewer people and states that smaller teams communicate better and are more productive, a claim the guide makes without data or a citation.

Those are rules of thumb built on a count of possible pairs. The count is the right order of magnitude for a group in which everyone must know what everyone else is doing and the wrong number for nearly any other group. The 2,134 developers who contributed to one Linux kernel release cycle, discussed below, make about 2.3 million possible pairs, and nobody would say the kernel runs on 2.3 million channels. Melvin Conway made the underlying point in 1968, in "How Do Committees Invent?" He noted that the possible paths among people grow as roughly half the square of their number, concluded that organizations must restrict communication, and observed that the restrictions are copied into the structure of the systems they design. The count is therefore a design variable. A team chooses which channels stay open and builds interfaces so that the rest can stay closed.

The pair count is also an imperfect bill in both directions. Brooks himself notes that meetings of three or more make things worse than pairs would. And coordination is not the only source of loss in a group: in the rope-pulling experiments of Ingham, Levinger, Graves and Peckham (1974), effort per person fell as groups grew. As secondary summaries describe the design, the drop also appeared in pseudo-groups, where the participant believed others were pulling alongside but did the pulling alone, so poor coordination cannot be the whole explanation. I have not read the full paper, and pulling a rope is a long way from writing software. Still, the result hints that a model counting coordination alone understates what a large group costs, while for modular work the pair count overstates the channels that matter. The true bill sits somewhere between the two.

Telemetry shows individuals speeding up and the queue behind them growing

Faros AI, a vendor of engineering analytics, published a study dated July 23, 2025 (its methodology note says the analysis reflects data as of June 2025), based on telemetry from more than 10,000 developers in 1,255 teams. It reported that developers on teams with high AI adoption completed 21% more tasks and merged 98% more pull requests, while pull request review time rose 91%, average pull request size rose 154% and bugs per developer rose 9%. It found no significant correlation between AI adoption and improvement at the company level. The method was Spearman rank correlation on metrics standardized within each company, with up to two years of quarterly data, and the per-team changes compare each team's two lowest-adoption quarters with its two highest, so the results are associations, and a seller of measurement chose what to measure. The page I read never defines review time and does not say whether it means the wall-clock wait per pull request or the total hours reviewers spend. That difference matters, because a rising wait points to a queue and rising hours point to effort.

In 2026 Faros followed with a report on 22,000 developers in 4,000 teams. A Faros web page that cites it says epics completed per developer rose 66% between each organization's lowest and highest periods of AI adoption, bugs per developer rose 54%, and the probability of a production incident per merged pull request more than tripled. I have not seen the report itself, so I treat these as a vendor's claims. They point the same way as the first study.

Sources with a different design agree on the direction and differ on the size. DORA, the research program at Google, reported in 2024 that a 25% increase in AI adoption was associated with an estimated 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability, alongside a 3.1% increase in reported code review speed. The authors wrote that the result ran contrary to their expectations, and offered a hypothesis: because AI lets people produce much more code in the same time, change lists are probably growing, and DORA has found for years that larger changes are slower and more prone to instability. In 2025, from a survey of nearly 5,000 professionals, DORA reported that AI adoption now improves delivery throughput but still increases instability, and it hypothesized that the instability is likely, in part, because larger batches of code are harder to review. It also found, with what it called a high degree of certainty, that teams working in small batches see AI's positive effect on product performance amplified. Both explanations are the authors' own readings of survey models. Neither is a measurement of review. A March 2026 DORA article, "Balancing AI tensions", goes further in words: it says that velocity gains for authors can translate into a significantly increased cognitive load for the reviewer, and it names small batches as a countermeasure. It reads as commentary from DORA's researchers, and I did not see a review measurement in the page I opened.

The best-known randomized trial is small and now dated. METR (Becker, Rush, Barnes and Rein, 2025) assigned 246 tasks from mature open-source repositories to 16 experienced developers, with AI tools allowed or disallowed at random, and found that allowing AI increased completion time by 19%. The developers had forecast a 24% reduction in time and, afterward, believed they had gained 20%. Those were early-2025 tools, so the result says little about today's. METR's own February 2026 update on a larger follow-up that began in late 2025 called its data an unreliable signal of the current effect, mainly because developers who expected large gains increasingly declined to work without AI, and METR said it believes developers are likely more sped up now than in early 2025 while calling its evidence for how much very weak. What survives from the 2025 trial is how far felt speed can sit from measured speed. That is a reason to measure the queue directly instead of asking people how fast things feel.

For the size of the queue, the best public baseline is older. Sadowski and colleagues studied code review at Google in a 2018 paper, covering about 9 million reviewed changes from January 2014 to July 2016. The median developer authored about 3 changes a week and reviewed 4, and spent a median of 2.6 hours a week reviewing. The median change touched 24 lines, first feedback on small changes came in under an hour at the median, and the median latency of the entire review was under four hours. Now apply Faros's high-adoption numbers as arithmetic. If a team's merged pull requests nearly double and each is two and a half times larger, the lines each reviewer must read grow about fivefold (1.98 × 2.54 is roughly 5), unless reviewers read less carefully. I am multiplying two averages that Faros reports separately, so it gives an order of magnitude and nothing firmer. The few hours a week that reviewers have must stretch, or the queue grows, and a queue is coordination cost in its plainest form: work waiting on one person's attention.

A toy model: cheaper writing and costlier review shrink the best team

Take the Di Penta form and put numbers on it, with the warning that every number here is invented for illustration. A feature needs 120 person-days when one person does it. Each pair of people loses half a day coordinating, so days to finish = 120/n + 0.5 × n(n-1)/2. Now two scenarios for AI. In scenario B, code generation halves the effort to 60 person-days and leaves the cost per pair alone. In scenario C the effort halves too, but the cost per pair doubles to a full day, as a stand-in for output that arrives in larger changes that take more review and integration. Days to finish, by team size:

Team size	Baseline	B: effort halves	C: effort halves, pair cost doubles
1	120	60	60
3	41.5	21.5	23
4	33	18	21
5	29	17	22
6	27.5	17.5	25
8	29	21.5	35.5
10	34.5	28.5	51

The baseline is fastest at six people. In B the best size is five. In C it is four, and a team of ten, at 51 days, beats one person working alone at 60 by only nine days. Writing cost halved in both scenarios, and in C the best team still finishes in 21 days against 27.5, so AI helps. What changes is how many people can be added before they start costing time, and the answer falls from six to four. The model also says what to measure. Its parameter ce is the average cost of one active channel, and on a team that generates code with AI, the largest part of it is time in the review queue.

The toy ignores training, sequential limits and the fact that review load scales with the volume of change and not with the number of pairs. It shows a direction and says nothing about magnitude. The scenario C assumption, that the cost per pair doubles, is the weakest link, and the Faros and DORA data are the only reason I think it points the right way.

Large teams work, and the ones that do are trees of small teams

The strongest objection is that big groups plainly succeed. Linux is the standard example. In the 6.18 cycle, which closed in late 2025, Jonathan Corbet of LWN counted 13,710 commits from 2,134 developers, the highest developer count in the kernel's history. If coordination costs punished large groups, this should be impossible, and large product organizations with hundreds of engineers add more evidence. If a modular architecture isolates the work, the objection goes on, AI changes little, since each team simply generates faster inside its own module.

I accept most of this, and the evidence on how those groups work supports the structural reading. Mockus, Fielding and Herbsleb (2002) studied Apache and Mozilla. In Apache almost 400 people contributed code, and the top 15 developers contributed more than 83% of the changes and 88% of the added lines. The authors hypothesized that a core coordinating informally stays at 10 to 15 people, and that a project needing more must add explicit process, code ownership or required inspections; Mozilla, whose module core groups ran from 22 to 36 people, bore that out. Mozilla did that: patches passed first through module owners and then through a smaller group of super-reviewers, and for half of the fixed bug reports, 43% or more of the resolution time fell between the fix and its verification, which led the authors to say that mandatory inspection almost doubled the resolution interval. Linux has the same shape. In 6.18, 53.6% of commits carried a Reviewed-by tag, and Corbet reports that just over half of mainline patches pass through maintainers at five companies.

The large teams that work are trees of small ones. Small groups own an area, and a review step sits at every boundary. The pair count that matters is the size of the group sharing a code area, which is where Brooks's formula applies, and the review queue is the channel between groups. Nothing in these examples refutes the law. They match Brooks's limit that useful headcount is bounded by the number of independent subtasks, with architecture and review process making the subtasks independent.

The objection still has force in one respect: a cleanly modular system can absorb people, and Brooks says as much. But that modularity is paid for before the project is late, in interfaces, owners and inspection rules, and a late project is usually one where the decomposition did not hold, which is why adding people to it fails. The examples also show that reviewer and maintainer time is the scarce input at scale. If AI raises the supply of patches without raising the supply of reviewer attention, the tree's boundaries are where the extra volume will wait. That last step is my inference from the pattern, and nobody has measured it.

Before adding anyone to a late project, find the interfaces and gauge the review queue

Split along interfaces before adding anyone. Count the independent subtasks first, as Brooks's bound implies, and name for each an owner and an interface that can be tested without the rest. If you cannot name the interface, the new person joins the shared pool, and the shared pool is where the bill accrues. Conway's observation helps, since the boundaries of teams become the seams of the system; draw them where you want the seams.

Add people early, if at all. Brooks's own numbers show why. In his example the two newcomers produce nothing in the third month while the trainer loses a month, and in the fourth month they deliver two person-months, so at best they net one person-month before the repartitioning and extra system testing he also counted. Had the same two joined at the start of the four-month project, the same arithmetic gives six person-months of productive work against the one-month loss to the trainer. That is my recalculation from his setup, and he does not state the figure. The training cost is the same whenever people join, but the schedule left to repay it shrinks every week. When too little schedule remains, Brooks lists the alternatives: reschedule once and generously, or trim the task.

Keep the group that shares a review queue small. Hackman's six and the Scrum Guide's ten are upper bounds from experience. The toy model says the right number falls when review is the expensive channel, and DORA's findings favor small batches. Small changes are also the cheapest lever, and the Google study notes that its short review times may owe something to the small size of changes.

Measure the review queue, since that is where the model puts the cost. Five numbers are enough to start with:

1. Median and 90th-percentile time from opening a pull request to its first human review.
2. Median and 90th-percentile lines changed per pull request, against a baseline from before AI tools arrived.
3. Pull requests authored and pull requests reviewed per person per week, so that a widening gap shows where attention is going.
4. Hours per week each person spends reviewing, taken from tool data.
5. Change fail rate and rework rate, the two instability measures in DORA's 2025 report, read together with the first four.

A concrete first step is to pull the last two quarters of merged pull requests and compute the first three numbers per team. If the median wait for a first review has grown at the pace of pull requests per author, the team is already on the right-hand side of the curve in the model, and the next hire should be questioned before it is made. Whether AI-assisted review flattens that queue or adds a second one that someone must supervise is a question I cannot settle. The data I found measure authoring far better than they measure reviewing.

Sources

1. Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering, chapter 2, "The Mythical Man-Month". Addison-Wesley. Chapter text read in a reading PDF hosted by Duke University (courses.cs.duke.edu/compsci408/fall16/readings/mythical_man_month.pdf); the note on Vyssotsky is read in the text of the 1995 anniversary edition on the Internet Archive.
2. Di Penta, M., Harman, M., Antoniol, G., Qureshi, F. (2007). The Effect of Communication Overhead on Software Maintenance Project Staffing: a Search-Based Approach. IEEE International Conference on Software Maintenance (ICSM 2007), Paris. Read from a copy hosted at www2.csc.liv.ac.uk (University of Liverpool course page).
3. Coutu, D. (May 2009). Why Teams Don't Work (interview with J. Richard Hackman). Harvard Business Review. hbr.org/2009/05/why-teams-dont-work.
4. Schwaber, K., Sutherland, J. (November 2020). The Scrum Guide. scrumguides.org.
5. Conway, M. E. (April 1968). How Do Committees Invent? Datamation 14(4), 28-31. melconway.com/Home/Committees_Paper.html.
6. Ingham, A. G., Levinger, G., Graves, J., Peckham, V. (1974). The Ringelmann effect: Studies of group size and group performance. Journal of Experimental Social Psychology 10(4), 371-384. Described here only from secondary summaries; the full paper was not read.
7. Faros AI (23 July 2025). The AI Productivity Paradox Report 2025. faros.ai/blog/ai-software-engineering. A vendor report based on telemetry.
8. Faros AI (2026). AI Engineering Report 2026, with figures as cited on faros.ai/comparison/github-copilot-vs-codeium and scope as stated on faros.ai/research. The report itself was not read.
9. DORA, Google Cloud (2024). Accelerate State of DevOps Report 2024, section "Exploring the downstream impact of AI". services.google.com/fh/files/misc/2024_final_dora_report.pdf.
10. DORA, Google Cloud (2025). State of AI-assisted Software Development, executive summary and the AI capabilities model chapter. services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf. Also DORA (10 March 2026), Balancing AI tensions: Moving from AI adoption to effective SDLC use, dora.dev/insights/balancing-ai-tensions/.
11. Becker, J., Rush, N., Barnes, E., Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. Also METR (February 2026), update on its late-2025 developer productivity experiment, metr.org/blog/2026-02-24-uplift-update/.
12. Sadowski, C., Soderberg, E., Church, L., Sipko, M., Bacchelli, A. (2018). Modern Code Review: A Case Study at Google. ICSE-SEIP 2018, doi.org/10.1145/3183519.3183525.
13. Mockus, A., Fielding, R. T., Herbsleb, J. D. (2002). Two case studies of open source software development: Apache and Mozilla. ACM Transactions on Software Engineering and Methodology 11(3). Figures read in the author's pre-publication draft at mockus.org/papers/mozilla.pdf.
14. Corbet, J. (1 December 2025). Some 6.18 development statistics. LWN.net, lwn.net/Articles/1046966.
15. Illustrative team-time model: 120 person-days of effort, half a day per pair (one day in scenario C), effort halved in scenarios B and C, as stated in the text. Parameters are invented; only the functional form comes from item 2.
16. Illustrative arithmetic: the recalculation of Brooks's four-month example and the product 1.98 × 2.54 of two separately reported Faros averages, as stated in the text.