The Mythical Man-Month turns fifty this decade. Fred Brooks wrote it about a mainframe operating system project that went over schedule at IBM in the 1960s, and it has stayed in print because the mechanisms he described — adding people to a late project makes it later, the man-month is a unit of cost but not of progress — never stopped applying to human teams. This is the opening argument of a book that asks what happens to those mechanisms once one of the people on the team is a model.
The Tar Pit, Now with Gradient Descent
I have a colleague who runs a small consultancy that does data engineering for pharmaceutical companies. She told me, six months into adopting an agentic coding tool, that her team's velocity had roughly doubled. I was about to congratulate her when she added: “and our review queue has roughly tripled.”
Code that used to be read once, by the author, before being submitted, was now being generated by a machine, skimmed by the author, submitted, reviewed by a peer, returned with comments, regenerated by the machine, re-skimmed, re-submitted, and re-reviewed. The number of lines committed had risen. The number of lines understood had not, and may have fallen.
Brooks opened his book with the image of the tar pits of the Pleistocene. Great beasts thrashed there; the more they thrashed, the more deeply they sank. Programming, he wrote, is a tar pit, and the larger the system, the deeper the tar.
The metaphor was about cumulative friction. Not any one task, but the sum of small tasks: the library that didn't quite do what the documentation claimed, the colleague who left, the build system that worked on Tuesdays, the integration test that flaked once a week and that everyone had silently agreed to ignore. None of these would sink you alone. Together, they did.
The story since 2022 is that the generative machine has drained part of the pit. This is true. I am not going to spend pages denying it. The boilerplate that used to consume a morning is now produced in the time it takes to read it. Translations between languages, between formats, between framework versions, the kind of tedium that used to be billed at junior consultant rates, is now dispatched in seconds. A senior engineer with a good agent setup can get through a backlog of refactoring tickets in an afternoon that would have taken her team a week.
This is real productivity. It would be churlish to deny it.
What is also real, and what the vendor decks tend to elide, is that the tar has not disappeared. It has changed phase. Where it was once thick and slow, with typing, looking up syntax, configuring tools, etc. it is now thin and fast: judging whether the four candidate implementations the agent produced are correct, plausible-but-wrong, or correct-for-the-wrong-reason. The work of typing has been delegated. The work of trusting has not. And the work of trusting, it turns out, is the work that was always hard.
This is the new tar pit. Not slower, but stickier in a different way. The beasts in it are more numerous and harder to see. That is confident hallucinations, plausible-but-wrong abstractions, dependencies that were generated rather than chosen, security implications that nobody traced. The list goes on. They look like progress until they don't.
The lesson Brooks drew from his pit was that the difficulty of programming was never primarily the typing. The lesson the new pit teaches is the same, only louder: the difficulty was never primarily the typing, and now that the typing has been removed, the difficulty stands more visibly than ever.
If you take one thing from this chapter, take this: the productivity gain from generative tools is real but measurable only at the level of the system, not the keystroke. A team that ships twice as much code is not necessarily delivering twice as much value. It may be delivering the same value with twice as much surface area, which is to say twice as many places for things to go wrong over the next five years or less. The tar settles slowly.
The Mythical Token-Month
Brooks's central argument, the one his book is named for, was that the man-month is a useful unit of cost but a misleading unit of progress. We say a project requires twelve man-months and we imagine it can be done by twelve people in one month, or by one person in twelve. Both are usually false. Some tasks cannot be partitioned. Some can be partitioned only at a cost in coordination that grows quadratically with the number of partitioners. Nine women cannot produce a child in one month.
The fallacy was specific: treating an aggregate of human effort as fungible across people and time.
The fallacy of our era is structurally identical and superficially different. The unit is no longer the man-month. It is the token. The vendor's slide tells you the model produced N billion tokens of code, that M percent of suggestions were accepted, that the productivity uplift is some flattering multiple. The implication, never quite stated, is that tokens generated correlate with progress made.
They correlate, at best, with characters that compile. Software is not a collection of characters that compile. Software is a coherent answer to a set of requirements that the customer himself only half-understands and that change while you are answering them. The work of eliciting those requirements, choosing among contradictory ones, imagining the system five years from now when its present authors will have moved to other jobs. None of this work is measured in tokens. It is measured in hours of thought, in arguments held in conference rooms or Slack threads, in the slow internalization of a domain by a person who must hold the whole problem in mind at once.
Let us therefore name the new fallacy plainly. The Mythical Token-Month is the belief that generative throughput is interchangeable with engineering progress. It is not. Tokens are to software as bricks are to architecture: a necessary input, an inadequate measure, and when produced faster than they can be inspected, a hazard.
There is a further wrinkle that did not exist in Brooks's day. The vendor of the bricks now also vends, separately, a service that inspects the bricks. This service is itself a model. It produces tokens about the tokens. It is not free, and it is not infallible, and it does not, in any rigorous sense, understand the bricks it is inspecting; it produces plausible commentary about them. The economics of this loop deserve attention. We pay for the bricks. We pay for the inspection. We pay for the storage of both. And we pay, eventually, for the rework when the bricks turn out to be wrong in a way the inspection did not catch.
I want to be precise about what I am claiming and what I am not. I am not claiming that generative tools fail to produce value. They do produce value. The claim is narrower: the unit in which the vendor measures their value is not the unit in which you, as the buyer of software, should measure their value. Tokens generated, suggestions accepted, lines committed. These are vendor metrics. They are useful for the vendor. They tell you very little about whether your system is becoming more capable, more maintainable, or more aligned with what your customer actually needs.
The unit in which to measure software progress has not changed since Brooks's day. It is the delivered, understood, maintainable feature. It was hard to measure in 1975. It is hard to measure now. Anyone who tells you otherwise is selling something, usually tokens.