Okay, riddle me this. We've been using AI to assist us for nearly a year now, right? So do we feel like we're moving faster? Are we shipping code to our users — our consumers and customers — at a faster rate?
Because that's usually what organizational leaders want, correct? Drive value, drive conversion, and do it faster. What I'm observing happening though — and what I suspect my peers are seeing also — is that we're producing a lot more code but not actually releasing those features faster.
If you're new here, this blog is just a lot of my musings around engineering management and tech in general. I'm currently rereading some classic engineering management books and seeing how they hold up in the AI era. My team recently hypothesized to me that when it comes to building software, there are no new problems. Even before AI, if someone could have waved a magic wand and made code production 10x itself, I have a feeling we'd be seeing some of the same problems. So in theory, if there are no new problems… I want to look at some old ones. First up: The Mythical Man-Month by Fred Brooks, anniversary edition.
Optimists with a deadline
Let's start with how we got here. Organizations have always wanted us to ship faster. That isn't new, and it isn't unreasonable — faster means value in customers' hands sooner, and a better shot at beating the competition to it.
Engineers have always wanted the same thing, and I have always appreciated the can-do attitude when it comes to getting the thing done. Brooks writes that “All programmers are optimists,” and I think that's the kindest possible read on a low estimate. We're not sandbagging or guessing wildly. We're picturing the version of the project where the API behaves, the design holds still, and the tests pass the first time — and we believe in it. We want to be helpful. We want our work in production, in front of real people, as soon as possible. So we say yes to the hopeful timeline, and then someone asks, “Can you do it in half the time?” And a lot of us, wanting to help, try to find a way.
The estimates come out off every time. Not because anyone is bad at their job, but because we estimate the perfect version of the work, and the real version… has a lot of other people in it.
No signatures, no problem
Quick poll: how many layers of validation does your code go through before it hits production? A code review on the PR. QA. VQA. Design review, product review, maybe a feature release review on top of that. Or maybe you're one of the lucky ones, and you push straight to main. (Or the really lucky ones, where your robots push straight to main.)
Brooks leans on a familiar picture here: two people in a garage, building software faster than any big, established company. Nobody's surprised by that. Nobody in a garage has to explain themselves to anyone. There's no review board, no release schedule, no one else's roadmap to line up with. If it works, it ships.
What I like is that Brooks doesn't stop at “they're scrappy.” He explains what actually changes as software grows up. What those two people are building is a program: it does one job, and its authors know exactly how it behaves. The moment it has to work with other programs and interfaces, it becomes a system, which Brooks puts at roughly three times the effort. The moment other people depend on it — with testing, documentation, and a promise to maintain it — it becomes a product, and that's roughly three times again. A real company has to be both, so the effort doesn't add up. It multiplies.
Now look back at that list of layers: the reviews, the testing, the sign-offs. That's where the multiples live, and almost none of it is typing code. It's people coordinating with other people. So faster code would send the garage into orbit. But the company would speed up the one part that was never its actual bottleneck.
The handoff is where it breaks
So where does the time actually go? Brooks describes an inevitable moment that every project faces:
“In most computer projects there comes a day when it is discovered that the machine and the manual don't agree.”
Same story in 2026. The software doesn't match the spec — or the spec doesn't match what the product owner pictured. Even if you're being Agile about it, there is always something about the end result that isn't quite what was asked for (and we're fairly waterfall these days, if you look at how agents work, but that could be an entire subject on its own). Brooks calls the independent testing that catches it a project manager's best friend and daily adversary, and I really, truly understand that sentiment.
We try so hard to prevent it! The spec. The Jira ticket. The Figma mock. The acceptance criteria. Somehow, someone still assumes something different about how a feature should work, and we find out in validation testing, after the work is done.
Here's what AI did to that problem: it made it bigger. An engineer can spin up ten agents and get ten features built, which sounds amazing until you realize a human missed a requirement. Now we're holding ten finished things that don't match what the business needed, and a person has to sort through all ten. That bottleneck was always there, but it previously felt more aligned with a natural development timeline. Now the gap is obvious.
Hurry up and wait
There's a phrase my team says a lot: “hurry up and wait.” The project is behind, so we rush to add people, and then everything stalls. Someone is waiting on a design. Someone is waiting on an API. Maybe the feature is even completely ready to go and is just waiting for a feature flag to be flipped to turn it on… and someone just forgets to do it, with everything else going on.
Brooks calls the thinking behind the rush a myth, and it's the one in the book's title. His whole argument hangs on a single condition:
“Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.”
Translation: more people only help if they can work without talking to each other. When has that ever been true in software? (Hurry up and wait, remember?)
For smaller projects, Brooks's answer was the “surgical team” — about ten people with specialized roles and one lead doing the cutting. It works because everyone has a defined job and the team stays small enough to communicate. But even Brooks says it doesn't scale. If a project takes 5,000 man-years, you can't get there by multiplying the surgical team by 50.
Now swap the people for agents. You could argue that today most of those surgical-team roles could be agents, with one or two humans orchestrating the rest, which I find a fascinating idea. But the same math applies the moment we try to scale it, because every agent is still attached to a person, and those people still have to coordinate. On my remote team, that looks like a relay race: the engineer builds on what their agent made from the designs the designer's agent made, which build on the spec the product manager's agent wrote. Every handoff is a message, a doc, or a call — and every one of them is a chance to add scope or time.
Where the joy went
Here's the part that gets me. When Brooks describes the joys of the craft, it comes down to two things: making something, and then watching people use it. There's real delight in fitting the puzzle pieces together, in continuous learning, and in creating something from nothing. But the bigger joy is the second half — the moment someone uses what you built.
Engineers are drained right now, and I think it's because both halves are under pressure. The artisan part of the job — the creative freedom to think through a hard problem and the satisfaction of seeing your solution reach production — has been quietly removed. What's left for a lot of people is reviewing line after line of generated code, and it's not even always making it to production. The reward at the end keeps getting pushed further out.
Brooks asks whether the architect gets all the fun while the implementer just takes orders. These days we tell engineers they get to be the architects, since the agent can do the implementing, but to say the quiet part out loud, there is just not as much fun involved when most of your day goes to reviewing generated code.
The code was never the slow part
So, back to the riddle: are we shipping faster? My answer, for now: we're producing faster. Shipping still depends on the same things it always has — the layers of review and testing, how well context survives a handoff, how many people have to coordinate, and whether leaders are aligned. Which is a little awkward, since leaders are the ones asking for the speed.
Brooks wrote his book in 1975. Estimates were optimistic then. Adding people to projects stalled projects then. And the code was never the slow part then, either. The tools have changed a lot. The problems haven't. AI didn't create them — it just turned the lights on.