For one week, The New York Times tested a piece of software it had not written. The piece kept the paper’s new online archive, the Information Bank, up to date: 12,029 lines of code, which the Times checked against 171 separate functions. IBM’s report on the project gave the result in one line. “No errors at all were detected.”
The team that built it was small and oddly shaped. One chief programmer designed the system and wrote its core. A backup worked beside the chief, a librarian kept every program and test run in order, and a few more programmers wrote the rest under close supervision. IBM described the arrangement as “similar in concept to a surgical team.” The full story is in the case.
One does the cutting
One person designs and writes the core; everyone else on the team supports them.
Fred Brooks, who had managed the software for IBM’s System/360, put the idea into The Mythical Man-Month in 1975, in a chapter called “The Surgical Team.” He started from a dilemma. Programmers differ enormously: in one study he cited, the best of a group of experienced programmers outperformed the worst by about 10 to 1 on average. And every extra mind adds communication. So for efficiency and what he called conceptual integrity, Brooks wrote, “one prefers a few good minds doing design and construction.” Yet a small team is too slow for a really big system. At its peak, more than 1,000 people worked on OS/360.
His way out came from Harlan Mills of IBM. Each segment of a large job would go to a team “organized like a surgical team rather than a hog-butchering team.” Instead of everyone cutting away at the problem, “one does the cutting and the others give him every support.”
Brooks then sketched the full team, about ten people:
- The surgeon, Mills’s chief programmer, who writes the specification, designs the program, codes it, tests it and writes its documentation.
- The copilot, who knows all the code, is the surgeon’s sounding board and insurance against disaster, but is responsible for no part of the code.
- An administrator and an editor, so the surgeon spends almost no time on money, people or polishing documents.
- A program clerk, who keeps every run and every version in a shared library.
- A toolsmith, a tester and a language lawyer, specialists the surgeon calls on.
Ten people work on the problem, but the system is, in Brooks’s words, “the product of one mind,” or at most two.
Why it can work
Brooks contrasted the surgeon and copilot with two programmers who split a job. The work isn’t divided: the surgeon and copilot each know all the design and all the code. And disagreements don’t have to be negotiated, because the surgeon settles them. The rest of the team are specialists, which, Brooks argued, makes the lines of communication far simpler. Most of them deal with the surgeon, not with each other.
Brooks called it “absolutely vital” to Mills’s concept that programming move “from private art to public practice,” with every run visible to the whole team and every program treated as team property. That was the clerk’s job; at the Times it was the librarian’s. The chief’s work never lived only in the chief’s head.
For bigger systems, Brooks’s plan was to divide the minds rather than the code. Put 200 people into surgical teams, and only 20 surgeons have to coordinate, with one architect designing the whole.
Where it breaks
The model stands or falls with the surgeon. Terry Baker, who reported on the Times project, said plainly that the team “was a relatively experienced one” and “performed at an above-average level.” Brooks called it “a single, small-scale test.” Years later, Mills wrote that when the idea spread, chief programmers appeared “from prima donnas” to “clerical administrators,” chosen in ways that ignored the “creativity and intellectual control” the idea depended on. “Small wonder” that such teams “did not always work out well, and some led to real disaster.”
Imagine a three-person design studio where the founder approves every layout and writes every client email, while two juniors fetch files and resize images. The founder’s taste may hold the work together. But if the founder is out for a week, little may ship, and the juniors may never learn to run a project. A surgical team without a real copilot, and without a shared library anyone can read, carries that risk.
The surgical team in the age of AI
Coding agents have arrived at a similar shape. In Claude Code, a main agent can hand side tasks to subagents. Each “runs in its own context window” and returns only a summary, so the main conversation doesn’t fill up with search results and logs. That resembles Brooks’s support staff: the tester, the toolsmith, the clerk, doing work the surgeon needs done but doesn’t need to hold.
The cautions carry over too. Anthropic, describing its multi-agent research system, reported that such systems used about 15 times as many tokens as chats, and that “most coding tasks involve fewer truly parallelizable tasks than research.” Cognition, the company behind the coding agent Devin, argued in 2025 that “actions carry implicit decisions, and conflicting decisions carry bad results,” and recommended by default a single agent that holds the whole context. Its example was Claude Code, whose subagent, as of June 2025, was “usually only tasked with answering a question, not writing any code.”
On that reading, the design still wants one mind holding the whole, now often a model, with helpers who search, test and summarize. Whether that mind is good enough is the question Mills faced in the 1970s.
At the Times, the programs written by the chief and the backup, by Baker’s count, “had about one error per year of effort.” Two people kept the whole system in view, and the rest of the team made that possible.