Published 2026-04-19, About 11 minute read.

I revere The Mythical Man Month. The author Frederick P. Brooks, Jr. was 50 years ahead of his time. He concretely pointed out the difficulty of organizing coders into teams and the issues with creating larger organizations of engineers.

Just take a gander at this quote:

The dilemma is a cruel one. For efficiency and conceptual integrity, one prefers a few good minds doing design and construction. Yet for large systems one wants a way to bring considerable manpower to bear, so that the product can make a timely appearance. How can these two needs be reconciled?

- "Mythical Man Month", Essay "The Surgical Team", page 31

Like it could be written yesterday, no?

AI workflows have mushroomed on social media and at work, and I've been trying to cope and adapt by experimenting with agents in my workflows. As I did this, I was reminded of Brooks' idea of a surgical team, and I found that the engineering team model described by Brooks (and Harlan Mills who first proposed the model) at scale works really well with coding agents.

Let's visit what Brooks proposed in his essay, consider how this dovetails nicely with AI agents, and what this means as far as AI adoption, human presence, and quality assurance.

The Surgical Team Model 📎

Giving proper credit where it is due, we must acknowledge that Brooks borrows the surgical team from Harlan Mills, an IBM research fellow and a literal "super-programmer."

But the main thrust of the surgical team argument is that a hierarchy should be adopted so that each teammate understands their role and can focus on excellence in their area. Additionally, the "chief programmer" or the "surgeon" can work without the hindrance of too many cooks in the kitchen.

Here's the diagram that Brooks provides:

The model includes a "co-pilot," who works alongside the chief programmer. How is this different than a traditional team of two developers working together? Brooks argues two points.

First, in traditional teams, the idea is that the JIRA tickets could be split up amongst many engineers, so the many split up their work and work in different spaces with different problems and different code. The pilot/co-pilot model means that both developers (and by extension everyone in the team) are devoted to the same problem, same code, in the same context, and at the same time. This sounds an awful lot like pair coding, which, to me, is actually the reason why pair coding is so successful. Two humans sharing the work space leads to "more than the sum of its parts" work!

Second, the decision hierarchy is hard to practice if you just have a gaggle of engineers. If someone is the decision maker- the pilot- the chain of command is much easier to work within. But not only that, everyone has distinct roles to specialize in. Brooks pushes this analogy far, talking about anesthesiologists and nurses. He suggests roles that cover administration, documentation, testing, computer language review, and tooling. When I read his example, it doesn't seem to be limited to just these roles.

Where does AI come in? 📎

When I use agents, I'm in the driver seat as the pilot. The AI can be many roles just by the nature of what it can do. It handles docs and claude files, if I ask it to attend to that role. It will vet the algorithms that I include or be able to address language specifics with the seeming knowledge of a javascript/css/html expert. It can handle JIRA tickets, MR/PR descriptions, test plans, and git commits. It can help me tweak config in my project or monorepo, and can also edit configuration files for itself or neovim. It can also write tests pretty well based on the guidance I give it.

Sometimes, when I describe the task I want Claude to do, Claude will spin off parallel tasks with special roles: researching, writing, vetting architectural ideas in a specific language.

I find that the surgical team emerges while I work. Claude fulfills the roles, sometimes in parallel as if there were multiple people filling each role of the hierarchy.

This seems to be the sweet spot in using AI. At work, there seems to be a consensus that the engineer is becoming more of the code architect, directing the agents to do the implementations and instantiation of our ideas.

Note that in this the human is in the loop and overseeing. The human does not walk away to get coffee (mostly). I strongly believe the human needs to be watching and understanding the flow of what the agents are doing and assembling, so the human can reality check, correct, and ultimately take responsibility for the code and the API.

I hear talk from other companies where AI is mandated and the employees are evaluated on how many tokens they use, and they're being coerced into creating large teams of "orchestrated" agents doing one-shot "full round trip" features. I hear them mandating that while one task is being run by a group of agents, the developer should be queuing up other tasks.

This is disastrous and irresponsible, recklessly YOLOing code into CI. The architect needs to oversee and have visibility on what LLMs are doing. The leader needs to make decisions and course correct along the way. You could try to argue that this is the surgical team model to its logical extension. I argue it's "hope coding"- not sustainable, and not based in reality.

This model hits its apex with two humans in the loop 📎

The other reason I would say we can never enter the "legions of agent orchestrations" world is that I believe there is still tangible and multiplicative benefit from pair coding in this model. If the co-pilot is a human, and the two humans are running AI teams, the results are optimal.

You get the benefit of the experience of the other engineer. The engineers can both listen to their "guts" and be able to guide the overall approach and usability of what they're building. They can share in the responsibility of speaking for the code and integrating the code with other systems.

I think most importantly, this answers the question that many are asking: what about the junior engineers? If working with an AI is like working with a highly skilled junior (a framing I've heard a lot), companies are going to stop investing in the junior developers. In an effort to remove the human cost, C-level bosses will think they're saving money by axing lower level engineers.

But really, these are the kind of insane decisions that cut companies off at the knees. The question remains after an AI-motivated layoff: who will you level up if you don't keep a healthy succession and development plan in place? If you have no junior developers to train and invest in, what will happen when your senior and staff engineers aren't there?

Part of the answer is that the co-pilot could be the junior developer. Not only are they providing the second human reality check, they're also working closely with a senior/staff developer and gaining experience in their craft.

Some rebuttals... 📎

Here are some potential questions I think I can answer.

If you're thinking this, you're probably touching on a point that's very true: AI is not fundamental to good coding work. People are.

What's nice about Brooks' team model is that it's a clean way to set expectations and process for a team when using AI. The fact that AI can fill many of the roles under the captain is incidental and an interesting support for the surgical team model.

Also, you can argue a co-pilot is not strictly necessary. It's my preference, though, and I think it produces objectively better work. Still, I think Brooks' model is a great way for individuals to structure their work with agents.

How do you keep a human in the loop when there are so many agents, and the agents can work in parallel? 📎

It's entirely possible to retain control and keep agents accountable. I use Claude quite a bit at work, and when I ask agents to "spin off" and do some work I am very explicit about checkpoints and artifacts that they should provide me. The fact that a few agents might be working together or in parallel is not really a concern. I'm also assuming in this post that teams don't balloon past seven or eight, and that includes agents. If you're spawning dozens and dozens of agents, I have nothing to say. You probably don't agree with much I'm saying. I probably can't help you.

Often, I ask the agent or agents to formulate a plan.md that I can read over and correct/improve. I ask for explicit coding samples of the types of code they want to suggest. I don't let Claude commit until I'm happy with code, and sometimes I don't let Claude commit at all.

If you can't handle orchestrating large amounts of agents, isn't this just a skill problem, not a fundamental problem? 📎

Naw, definitely fundamental. This is not a problem that is unique to AI. This is a human systems problem.

We are finite. We can only meaningfully supervise so much. No amount of artifact wrangling, summarizing, or tricks to speed up review are going to help you past a certain number of agents. You can probably over time increase how many contexts you switch between, but you are still a mere mortal, my friend.

As Addy Osmani observes, there's a ceiling to how many agents you can reasonably work with and switch between:

The conversation about AI coding agents is almost entirely about what agents can do. It needs to also be about what humans can sustain. The ceiling isn’t a personal failure.

I'm still hesitant about AI and its place in engineering 📎

I think it's super interesting that AI seems to fit very well into the surgical team model. This is how I would prefer to work with my teams at work, and it seems to work really well with humans that can vouch for work and help vet and review pull requests where AI was involved. But I'm still not AI-pilled.

I'm seeing an explosion of merge/pull requests at work, and the fact that people can't vet the amount of code AI is generating is a huge portent to me. I worry about comprehension debt. I really worry that even with pair coding junior developers will not have the same experience and trials that shaped the expertise of their predecessors.

The nice thing about the surgical team model with human pilots and copilots is that there are human touchpoints built in. I feel much more at ease with a sane integration of AIs as a tool, not as the engine of development.

But I'm open, and still learning. I might have to eat my words in a year, who knows? From my limited experience, the wisdom of Brooks' surgical team works and seems to align with what we hear about across the dev world.

Find me on Bluesky or Mastodon. I also have an RSS feed here