The Mythical Man-Month: chapters 1-6

Question: once agents can write code, is The Mythical Man-Month still worth reading?

My answer: yes, probably more than before. Brooks was not only talking about the cost of writing code. He was talking about the cost of making software coherent, testable, documented, integrated, and owned by a group of people over time.

The short version

Agent coding lowers the cost of producing a local patch. It does not lower, and often raises, the cost of deciding whether that patch belongs in the system.

That is why the first six chapters still feel alive. Brooks keeps returning to a distinction that modern tooling can blur:

program             -> something that runs
programming product -> something other people can use
programming system  -> something that composes with other parts
systems product     -> all of the above, maintained over time

Agents are very good at helping with the first box. The rest still requires interfaces, tests, review, conventions, release discipline, and someone who can say no.

1. The tar pit

The tar pit is not “programming is hard.” It is that useful software accumulates obligations.

A script that reads a CSV, calls an API, and draws a chart can be generated quickly. A team data pipeline has to validate inputs, handle retries, log failures, respect permissions, document assumptions, survive schema drift, and avoid silently poisoning downstream consumers.

That is the part agent coding does not make disappear. It moves the bottleneck from “can I produce code?” to “can I tell whether this code should enter a durable system?”

The useful agent workflow is therefore not “write more code faster.” It is:

draft -> test -> document -> integrate -> observe -> revise

The tar is in the arrows.

2. The mythical man-month

Brooks’s famous warning is that effort and schedule are not interchangeable. A late project does not become early just because more people arrive.

The agent-era version is the agent-call myth:

more agents != shorter delivery time
more branches != more coherent system
more generated code != more integrated value

Parallelism helps when boundaries are stable. It hurts when the work is conceptually entangled.

Five agents editing the same service can easily produce five naming schemes, five partial abstractions, and one miserable merge bottleneck. The real question is not “how many agents can I spawn?” It is “which parts of this problem are separable enough to give to independent workers?“

3. The surgical team

The surgical-team chapter is easy to misread as nostalgia for hierarchy. I read it as a design pattern for responsibility.

Large systems need many hands, but conceptual integrity needs a small number of final design voices. In an agent workflow, that suggests a structure like this:

Role	Job
Owner	Holds the design intent and final diff
Researcher	Finds source context and constraints
Implementer	Produces candidate patches
Tester	Adds regression coverage and runs checks
Reviewer	Looks for boundary mistakes
Editor	Updates docs, changelogs, and examples

The point is not to make every agent equal. The point is to make each role useful without letting all of them compete for architecture authority.

4. Conceptual integrity

Brooks’s phrase “conceptual integrity” is still the center of the book for me.

A CLI can be implemented by many contributors and still feel like one tool. Or it can feel like a pile of unrelated commands:

--file
--path
inputPath
source
target_file

Every local choice can be defensible and still damage the whole. Agent-generated code makes this easier to do at scale because each patch is locally plausible.

So agent coding needs a stronger separation:

architecture contract -> few voices, explicit rules
implementation search -> many workers, broad exploration

Names, API semantics, error handling, configuration shape, backwards compatibility, and user-visible behavior should not be re-invented in each branch.

5. The second-system effect

The second system is dangerous because the designer finally has confidence and a backlog of ideas. In an agent project, this gets worse because every feature feels cheap:

add memory
add planner
add browser
add self-evolution
add marketplace
add policy engine
add visual debugger

Each feature can be generated. That does not mean the system can absorb it.

The countermeasure is to price every feature in operational terms:

Feature cost	Question
Latency	Does the loop still feel fast?
State	What new state can go stale?
Failure modes	How will this break?
Observability	Can we debug it after it breaks?
Evaluation	What proves that it helped?
Maintenance	Who owns it after the demo?

AI reduces the marginal cost of code generation. It does not reduce the marginal cost of complexity.

6. Passing the word

Architecture decisions do not propagate just because someone wrote them down once.

Brooks talks about manuals, meetings, phone logs, formal definitions, and tests. In agent work, I would compress that into one rule:

A rule has not entered the system until an agent can retrieve it, CI can check part of it, and review can point to it.

This is why executable specifications matter. The same decision should show up in several forms:

• prose, so humans know the intent;
• types or schemas, so tools can enforce shape;
• tests, so regressions are caught;
• examples, so agents have patterns to imitate;
• traces or changelogs, so future debugging has memory.

Docs that are not connected to execution become atmosphere. Agents need operating context.

What I am taking from the first six chapters

Brooks’s organizational details are dated. The structural warnings are not.

programmer coordination -> agent orchestration
manual review           -> tests, evals, traces
architecture handbook   -> executable specification
late manpower           -> late agent swarm
second-system effect    -> prompt-away feature creep

The lesson is not “agents are bad.” I want agents in the workflow. The lesson is that speed makes architecture discipline more valuable, not less.

If local implementation becomes cheap, the scarce work shifts toward boundaries: what should exist, what should compose, what must be tested, what can be deleted, and who is allowed to change the shape of the system.