The hard part was never the typing.

The planning spreadsheet for next year has a new column. Beside each team's engineers it lists coding agents, and at the bottom a formula adds them up: twelve engineers plus sixty agents, expressed as "capacity," with a roadmap sized to match. The spreadsheet is invented for this essay, but the arithmetic is common this autumn, as budgets for 2027 are set. It treats an agent the way managers once treated a new hire, as a unit of work that can be added to a plan. In 1975, Fred Brooks published a book about why that unit does not exist.

The Mythical Man-Month drew on Brooks's experience managing the software for IBM's System/360. Its title names the error: the belief that people and months are interchangeable, so that a task needing twelve person-months could be done by twelve people in one. Brooks's answer was that this holds only for work that can be divided among people who never need to talk to one another, and software is not that kind of work.¹ Agents have revived the error in a new form, because they make one part of the work enormously cheaper and invite us to treat that part as the whole.

My argument is that agents attack the part of software that Brooks considered the smaller one. Writing the code, the labor of turning a design into a working program, is now cheaper than it has ever been. Deciding what to build, the work of settling exactly what the system should do and how its parts fit, is not, and Brooks thought it was always the harder part. Agents are worth having; this is not an argument for slowing their use. It is an argument for budgeting, organizing and measuring as if the scarce input were the design, because increasingly it is.

More code, modestly more software

The largest study yet of what coding agents do to shipped software appeared on September 6. Mert Demirer of MIT, Leon Musolff of Wharton and Liyuan Yang of Boston University matched more than 500,000 GitHub developers with telemetry on their use of three generations of tools: autocomplete, agents that work alongside a developer, and agents that work on their own until a task is done.³ Each generation raised coding activity. Measured in commits, the cumulative effects were 30, 180 and 240 percent. But the gains shrank at every step toward a finished product. The 240 percent rise in commits became 80 percent more projects and 30 percent more releases.

The authors looked at why, and the most interesting answer is not that the extra code piles up waiting for someone. It is that much of it was never going to ship. Developers using agents that work alongside them added seven times as many lines of code but deleted twelve times as many. They created 79 percent more branches. The share of new repositories that saw no further activity after their first month rose from 60 percent in 2021 to 69 percent. The paper calls this experimentation: more trying, at the stage where the tools are strongest, with most of the attempts discarded. In four large app marketplaces, monthly launches of new apps roughly doubled on average after early 2025, while total use of new apps did not increase in any of them.³

None of this says agents are unproductive. It says that code was easy to multiply and finished software was not. Last year's DORA research reported something similar from a survey of nearly 5,000 technology professionals: AI adoption went with higher delivery throughput but lower delivery stability, which DORA read as AI amplifying whatever a team already was.⁴

Essence and accident

Brooks gave the cleanest explanation in 1986, in an essay called "No Silver Bullet," later added to the anniversary edition of the book. Following Aristotle, he divided the difficulties of software into two kinds. The essence is the conceptual construct itself: the data, the relationships among them, the algorithms, the interfaces, all specified precisely. The accidents are the difficulties of representing that construct in a programming language and getting it to run. Brooks believed the hard part was the specification, design and testing of the construct, not the labor of representing it. The hardest single part of all, he wrote, is "deciding precisely what to build."²

That is why he predicted no single development would deliver even a tenfold gain in productivity within a decade. Most of the big gains of the past, high-level languages above all, had come from removing accidental difficulty, and there was only so much of it left. Coding agents are the most powerful attack on accidental difficulty anyone has built. They write, refactor and translate code at a speed Brooks could not have imagined. What they do not do on their own is settle what the system should be.

Brooks's arithmetic

In a 1995 follow-up, "'No Silver Bullet' Refired," Brooks answered critics with a piece of arithmetic.¹ If the accidental part of the work is less than nine-tenths of the total, then even removing it completely cannot make the whole job ten times faster. He added that he thought the accidental part was about half or less, and was careful to call that an opinion. Figure 2 lets you vary both numbers.

The model is crude, and the shares are anyone's guess. But it makes one point that no estimate can escape. When one part of a job becomes nearly free, the time that remains belongs to the other part. A team that once spent half its effort writing code and half working out what to write will, with excellent agents, spend almost all of its effort working out what to write. Its leaders should plan for that.

Brooks's law, minus the training

The book's best-known sentence is a rule of thumb: adding people to a software project that is already late makes it later. Brooks named three costs behind it. New people must be trained. The work must be divided again so they have something to do. And every added worker adds lines of communication, which grow much faster than the number of workers.¹

Agents remove the first cost almost entirely. An agent needs no months of ramp-up. The other two costs remain. Someone still has to divide the work so that sixty parallel efforts produce parts that fit, and every agent session still needs to know what the others have decided. Spotify's engineering team described exactly this in August, introducing a tool for managing dozens of parallel agent sessions. As usage grew, the company wrote, pull requests increased, but so did rework, inconsistency and wasted computing. Agents in one session spent effort "rediscovering what another session had already resolved," and engineers spent as much effort reconstructing context as building.⁵ That is Brooks's communication cost, borne by software instead of people.

Salesforce gave a similar account in September of spreading agent use across 15,000 engineers. It reported work items completed per developer up 90.5 percent year over year in July, pull requests merged up 88.1 percent, and its own machine-learning measure of output up 200 percent. It also set teams a 90-day target of exponential productivity, and wrote that teams falling short revealed cross-functional dependencies, approval chains and process overhead.⁶ Those figures are the company's own, measured its own way. The lesson it drew is the one Brooks would have: the work between people did not shrink when the typing did.

One mind on the design

Brooks's remedy was not more people but fewer minds. He argued that conceptual integrity, a system that reflects one coherent set of design ideas rather than many good but uncoordinated ones, is the most important consideration in system design.¹ To get it on large projects, he endorsed a proposal by Harlan Mills: organize programming like a surgical team, in which one chief programmer designs and writes the critical parts and a team of specialists supports that person, rather than ten peers each cutting a piece.

For most of fifty years the surgical team was hard to staff. Supporting specialists were expensive, and the model looked like a luxury. Agents change that. A capable designer can now direct a team of tireless assistants that draft, test, document and translate. But the model only works if there is a surgeon: a person, or two working as one, who holds the design and decides what the system is. Without that person, sixty agents are not a surgical team. They are sixty peers, each producing locally sensible code for a system no one has defined.

This is a claim about design authority, about who decides what the system should be. It is different from the question of how an organization checks the work agents produce, which deserves its own treatment. A perfectly checked set of parts can still fail to make a coherent whole.

Brooks revised Brooks

Brooks was unusually willing to correct himself. In the 1995 edition he withdrew one of his own famous recommendations, to plan on building a first version and throwing it away, calling it too simplistic, and argued instead for growing a system incrementally, release by release. He kept the law about late projects, describing it as a first approximation rather than a precise truth.¹ That is the spirit in which to use him now. His shares and rules are not physics. They are a way of seeing which part of the work a new tool changes and which part it leaves alone.

Cheap code makes incremental building easier, not harder. A team can try three versions of a feature in the time one used to take, and the experimentation in the Demirer data is partly that. But trying is not deciding. Each version still has to be judged against a clear idea of what the system is for, and someone has to say which one ships.

Objections, considered

Agents will soon do the design too. Some design work, perhaps a growing share. But deciding precisely what to build includes deciding what the business needs, which trade-offs it accepts and which promises it makes to customers. However capable the tools become, someone in the organization is accountable for those choices, and the arithmetic of Figure 2 applies to whatever remains.

The release gains are early, and will grow. They may. The paper's estimates cover tools still spreading. But a plan for 2027 should be built on the evidence available, which shows code multiplying several times faster than shipped software.

More experiments are good. They are, when they answer a question. The rising share of abandoned repositories suggests that much of the new activity is trying without a hypothesis. That is cheaper than it was, not free: someone still has to read, judge and discard it.

Cheaper code does not make it cheaper to know what to build.

Before the 2027 engineering budget

• What does the plan measure? Ask whether success is counted in commits and pull requests or in releases that people use.
• Who holds each system's design? Ask for the name of the person who decides what each major system is, and whether that person has time to do it.
• How is the work divided? Ask how parallel agent efforts are partitioned so the parts fit, and how each one learns what the others decided.
• Where did the capacity go? If writing code takes a fraction of the time, ask whether requirements, interfaces and architecture got the effort it freed.

Back to the spreadsheet. The column of agents stays; they are real capacity for writing code. But the formula that adds them to the engineers comes out. In its place goes a row that was never there before: for each system, the name of the person who decides what it is, and the hours set aside for that work. The roadmap gets shorter. The part of it that ships gets longer.