Adding Agents to a Late Project Makes It Later: Brooks's Law in the Age of AI Coding
A 1975 book about IBM's OS/360 hit the top of Hacker News again this week. AI agents removed the ramp-up cost Brooks warned about, but the coordination and review costs did not go away. They moved. Here is what that means for team size, late projects and how you staff engineering work in 2026.
Why Is a 51-Year-Old Book Trending on Hacker News Again?
On 27 October 2026, Jan van den Berg published a short essay called The Mythical Man-Month in the Age of AI. Within a day the Hacker News thread had passed 400 points and 300 comments, which is a lot of attention for a post about a book published in 1975. His argument is simple: Brooks's Law did not disappear when AI agents arrived. It mutated. His 2026 version reads: "Adding agents to a project with unclear requirements gets you the wrong answer faster."
He is not alone. Wes McKinney, the creator of pandas, has been giving a talk called The Mythical Agent-Month at AI Council 2026. Mike Carlisle wrote an essay with the same title in August. Distributed systems researcher Murat Demirbas argued in January that multi-agent systems do not escape Brooks's Law, they just hit the coordination wall faster than human teams do.
The reason the topic keeps coming back is practical, not academic. In 2026 many engineering leaders face a situation Brooks would recognise: a project is late, the board wants it faster, and there is a new way to add capacity. In 1975 the answer was more programmers. Today it is more agents, more seats or more parallel agent sessions. The question is the same one Brooks asked: does more capacity actually shorten the schedule?
The short answer, from both the essays and the delivery data, is that it depends almost entirely on what is making the project late. If the bottleneck is typing, agents help a lot. If the bottleneck is unclear requirements, design decisions, integration or review, extra capacity makes things worse. Most late projects are late for the second set of reasons.
Key Takeaways
- The essay The Mythical Man-Month in the Age of AI passed 400 points on Hacker News in late October 2026
- Several 2026 essays reach the same conclusion: Brooks's Law changed form but still applies
- Whether agents speed up a late project depends on what is actually causing the delay
What Did Brooks Actually Say?
Fred Brooks drew his law from managing IBM's OS/360, one of the largest software projects of the 1960s, and published it in The Mythical Man-Month: "Adding manpower to a late software project makes it later." It is often quoted as a joke about bureaucracy. It is actually a claim about three specific costs.
The first is ramp-up. A new engineer has to learn the codebase, the domain and the team's conventions, and the people teaching them stop doing their own work while they do it. The second is communication. As Carlisle points out in his essay, a team of n people has n(n-1)/2 communication paths: 45 for a team of ten, and 19,900 for a team of 200. Each path is a place where intent can be lost or misread. The third is that some work cannot be split. Brooks's famous example is that nine women cannot make a baby in one month.
There is a fourth idea in the book that gets less attention but matters more now: the gap between a program that runs and a product people can rely on. In a conversation with Joe Reis in April 2026, McKinney pointed out that Brooks estimated this gap at roughly 9x. Getting something to work is the cheap part. Testing it, documenting it, integrating it with other systems and keeping it working is where most of the effort goes.
Brooks also argued for conceptual integrity: a system should look like it was designed by one mind, even if many people built it. His answer was the surgical team, where one senior person owns the design and others support them. That idea, written for a world of punch cards, turns out to describe the best way to run AI coding agents surprisingly well.
Agents Removed One of Brooks's Costs. The Other Three Are Still There.
The case for agents beating Brooks's Law rests on ramp-up. An agent can read a repository in seconds. It needs no onboarding, no stand-ups and no time off. Van den Berg acknowledges this before taking it apart: agents are "up to speed in milliseconds", but loading code is not the same as understanding it.
Demirbas makes the same point from a distributed systems angle. In his critique of the Self-Defining Systems position paper, he argues that context is not common knowledge. An agent can see every file and still miss how a change in one service ripples through three others, because that knowledge lives in the heads of people who were there when the decisions were made. He calls the coordination cost "a mathematical law, not a sociological suggestion."
The communication cost did not disappear either. It changed shape. Agents do not talk to each other in meetings, but their work collides in the codebase. Two agents asked to improve the same module will make conflicting assumptions, and without careful orchestration, as van den Berg puts it, they "rewrite each other's work in a high-speed loop." We covered the mechanics of this in our piece on what a fleet of coding agents actually costs to run: writing code got cheap, landing it did not.
And the indivisible work is still indivisible. Database migrations have an order. A payment integration cannot be tested before the provider's sandbox account exists. A design decision that three teams depend on has to be made before any of them can start. Adding agents does nothing for the critical path, because the critical path was never limited by how fast code gets typed.
Key Takeaways
- Ramp-up cost: largely removed by agents that can read a codebase instantly
- Communication cost: moved from meetings into merge conflicts and contradictory changes
- Indivisible work: unchanged, because the critical path was never about typing speed
- Product gap: still there, and agents make the gap between working code and a reliable product wider, not narrower
Where Did the Overhead Go? Into Review.
If Brooks's Law still holds, you would expect to see it in delivery data: more output, but not proportionally more delivered value, and more cost downstream. That is what the telemetry shows. The Faros AI Engineering Report 2026, based on two years of telemetry from 22,000 developers across more than 4,000 teams, found task throughput per developer up 33.7% under high AI adoption. In the same period, median time in code review rose 441.5%, the incidents-to-pull-request ratio rose 242.7% and bugs per developer rose 54%.
That is Brooks's Law in modern clothing. The extra capacity is real, but it creates coordination work that lands on a small number of people, usually the most senior engineers, who now spend their days reading code they did not write. Faros calls this the senior engineer tax. The same report found pull requests merged without any review, human or automated, up 31.3%, which is what happens when a team cannot keep up and starts skipping the check altogether.
Google's research team found a similar pattern from a different angle. The 2025 DORA report found that around 90% of technology professionals now use AI at work, and described AI as an amplifier: it magnifies the strengths of well-run teams and the dysfunctions of struggling ones. Teams with clear ownership and good tests got faster. Teams with unclear requirements got more code and more instability.
The individual-level evidence is also less clear than the marketing suggests. In METR's 2025 randomized trial, 16 experienced open-source developers working on 246 tasks in repositories they knew well took about 19% longer when AI was allowed, while believing it had made them 20% faster. Tools have improved since then, but the perception gap is the warning: teams often feel faster before they are faster.
| Brooks's cost | With human hires (1975) | With AI agents (2026) |
|---|---|---|
| Ramp-up | Weeks or months per new engineer | Seconds to load the repository, but no shared history of why decisions were made |
| Communication paths | n(n-1)/2 conversations to keep aligned | Conflicting changes, merge collisions and duplicated work in the codebase |
| Indivisible work | Critical path cannot be split across people | Critical path cannot be split across agents either |
| Program vs product gap | Testing, integration and documentation dominate effort | More code to test, integrate and review, concentrated on senior reviewers |
Intent Does Not Scale
Carlisle's essay has the clearest reformulation of the problem. He argues that Brooks's Law was never really about people. It was about "sources of intent." Every person on a team has their own picture of what the system should do and their own territory in the code. The coordination cost comes from reconciling those pictures. In his words: "Agents scale execution. Intent doesn't scale."
This explains something many teams have noticed. A single strong engineer directing several agents can be remarkably productive, because there is only one source of intent and the agents carry it out. Add a second and third engineer, each directing their own agents, and the old problems return quickly, only faster. Now there are three pictures of the system being implemented in parallel at machine speed.
It also explains why Brooks's surgical team is relevant again. His model put one senior designer at the centre, with others in supporting roles. In 2026 that maps neatly onto a small team where a senior engineer or tech lead owns the architecture, agents do much of the implementation, and the other engineers focus on review, testing, integration and domain knowledge. The team is small because intent has to stay coherent, not because the work is small.
A post on bencoding.com put it bluntly in an August essay: "adding ungoverned agents to a late software project makes it later, noisier, and harder to trust." The bottleneck, he argues, "moves from writing code to curating intent." Conceptual integrity used to be a nice-to-have for architects. It is now the thing that decides whether more AI capacity helps or hurts.
Key Takeaways
- Coordination cost comes from multiple sources of intent, not from headcount as such
- One engineer directing several agents scales well; several engineers each running their own agents do not
- The surgical team model, with one design owner and supporting roles, fits agent-assisted work closely
What Should You Do When a Project Is Late in 2026?
The tempting response to a late project is to add capacity: more agent seats, more parallel sessions, or a contractor or two who will "just use AI" to catch up. Based on everything above, that is usually the wrong first move. Before adding anything, find out what is actually slowing the project down.
If the delay comes from unclear or shifting requirements, more capacity produces more of the wrong thing. The fix is a decision, not a person: freeze the scope for the next milestone, write acceptance criteria that an agent and a reviewer can both check, and cut features that are not needed for launch. Brooks's own advice for late projects was to reschedule honestly or trim the task, and it still holds.
If the delay comes from review and integration, which is increasingly common, then adding code generation makes it worse. What helps is review capacity and verification: senior engineers who know the system, better automated tests, smaller pull requests and clearer ownership of each area of the code. We wrote about this shift in our article on the verification capacity gap, and about the related problem of agents waiting on human decisions.
If you genuinely do need more people, add them in a way that keeps intent coherent. That means adding a whole small team with its own clearly separated area of the system, not scattering individuals across the existing codebase. It means giving the new team a design owner from day one. And it means accepting that the first two weeks will be spent understanding the system, not producing code, even if their agents can produce code on day one.
Key Takeaways
- Diagnose first: requirements, review, integration or genuine implementation capacity
- For unclear requirements, cut scope and write checkable acceptance criteria instead of adding capacity
- For review bottlenecks, add senior reviewers and verification, not more code generation
- When adding people, add a self-contained team with a clear area of ownership and a design lead
What This Means for Team Size and Outsourcing
For a decade, outsourcing was often sold on volume: more developers for the same budget. In an agent-assisted world, volume is cheap and mostly not the constraint. Faros makes the point directly in its 2026 report, arguing against cutting engineers based on AI output gains alone, because the work needed to keep that output safe, correct and maintainable has grown. The same logic applies to buying capacity. What you need from an external team is judgment, review discipline and the ability to share your intent, not a larger number of people generating code.
That changes what a good engagement looks like. A small, senior dedicated development team that owns a clearly defined part of your product will usually beat a larger, cheaper team spread across the whole codebase. The smaller team has fewer communication paths, one design owner, and the context to review agent output properly. It also stays with your product long enough to build the shared history that agents cannot provide.
Time zones matter more than they did, not less. Intent gets shared through conversations: clarifying an edge case, pushing back on a requirement, agreeing on how a module should behave. If your external team is eight or nine hours away, those conversations happen once a day at best, and agents fill the gaps with guesses. A nearshore team working in or close to your time zone can resolve those questions in the same afternoon, which keeps the source of intent single and current.
This is how we structure work at Stepto. Our engineers in Serbia work within one or two hours of Central European time and overlap with US East Coast mornings. Each team has a technical lead responsible for design consistency, works in small pull requests, and treats review as core work rather than overhead. We use AI agents heavily, but we size teams for coherence and review capacity, not for how much code they can generate. If you are considering staff augmentation to rescue a late project, we will first help you work out whether more people is actually the answer.
A Brooks-Aware Checklist for Engineering Leaders
Before you approve more agent seats, parallel sessions or headcount for a late project, ask these questions. They are a 2026 translation of the advice Brooks gave in 1975, and they take less than an hour to answer honestly.
First, what is on the critical path, and can any of it actually be parallelised? If the next milestone depends on a sequence of decisions and integrations, more capacity will not move it. Second, are the requirements for the next milestone written down clearly enough that an agent and a reviewer would agree on whether a task is done? If not, fix that before anything else.
Third, where is review time going? Look at the age of open pull requests, who is reviewing them and how much time your senior engineers spend reading code versus designing. If review is the bottleneck, adding generation capacity will make it worse. Fourth, who owns the design of each part of the system? If the answer is "everyone" or "the agents", conceptual integrity is already slipping.
Finally, if you do add people, are you adding a coherent team with its own area and its own lead, or scattering individuals across the codebase? The first scales. The second recreates the OS/360 problem at machine speed. These questions do not depend on which model or tool you use, and they will still be relevant when the current generation of agents has been replaced by the next one.
More Capacity Is Not the Same as More Progress
Brooks's Law survived the arrival of AI agents because it was never really about how fast people type. It was about ramp-up, coordination, indivisible work and the gap between working code and a reliable product. Agents removed the first cost and made the others more visible, moving the overhead into review, integration and keeping one coherent picture of the system. The teams that benefit most from AI in 2026 are the ones that keep intent in a few experienced hands and invest in review as seriously as in generation. If your project is late and you want a small, senior team that can take ownership of part of the system without adding coordination chaos, talk to us about a dedicated nearshore team from Stepto.
Building a team in Eastern Europe?
StepTo builds dedicated nearshore engineering teams in Belgrade, Serbia. Engineers start in 2-4 weeks, with a two-week paid trial and from $4,500 per developer per month.
