In the Age of AI, the Bottleneck Isn't the Code—It's the Review Process

You must automate what you cannot afford to miss.

Fred Brooks published The Mythical Man-Month in 1975, and every working engineer has absorbed its central lesson whether they’ve read it or not: adding people to a late software project makes it later. The reason is communication. Each new engineer multiplies the number of conversations the team has to hold in its collective head, and at some point the conversations cost more than the code they produce. Fifty years later we quote Brooks like scripture and build as if he were wrong.

The trap only springs on the projects that work. Software that fails never has this problem. The moment you have revenue, you have users, and users hand you feature requests and bug reports and a competitor shipping something you don’t have yet. Any company worth running takes on technical debt on purpose, as a bet, because the alternative is losing. So success is what generates the demands that wear down the thing that made you successful.

You don’t get to opt out. The bill arrives precisely because you won.

What you’re paying down, as the code grows, is cohesion. Early on a system has a few authors who share an unspoken model of how things should work: where logic belongs, what the error-handling convention is, which abstractions are sacred and which are throwaway. None of it is written down because none of it needs to be. The architecture lives in three or four people’s heads, and those heads talk every day.

Then you hire, because the feature requests don’t stop, and each new contributor shows up without the shared model. They write reasonable code in a slightly different dialect. The seniors review what they can, but review is a bottleneck and the queue grows faster than the reviewers do. Standards that were obvious become standards that are merely documented, and a documented standard is one that gets skipped at 11pm the night before a release. Give it a few years and the codebase no longer expresses one point of view. It expresses the running average of everyone who ever touched it, which is to say it expresses almost nothing.

We’ve spent decades calling this a people problem and throwing people-shaped fixes at it. Style guides. Onboarding decks. Architecture review boards. The staff engineer who personally reads every pull request until the week they quit. All of these help a little, and all of them share one flaw: they need a human holding the standard in mind at the exact moment the standard is at risk. We’re bad at that. We get tired, we get rushed, we want to be agreeable to the colleague whose code we’re reviewing at 11pm. The standard doesn’t collapse because someone decided to abandon it. It just erodes, one reasonable exception at a time, because no single decision was ever made to hold the line.

Now the same dynamic is arriving faster than anything we’ve had to absorb before. Agents write code, and they write a lot of it, fast. Whatever drift you used to get from a new hire over six months you can now get from an agent over an afternoon. The agent has no model of your system. It has a general model of all systems, which is worse, because its output is plausible. It will hand you code that looks like it belongs and quietly breaks the convention you’ve protected for three years. Put a handful of agents behind every engineer on the team and the old review bottleneck doesn’t just strain, it gives.

Declarative enforcement changes the shape of the problem. The idea predates AI and it’s simpler than it sounds. The people responsible for the system, the architects and senior engineers, write down the constraints that must hold across the codebase, and the machine enforces them instead of human memory. Not as a guideline anyone can talk their way past, but as a rule the build itself checks. The architect’s judgment stops living only in a head and starts living in a form the system can apply on its own.

What matters is when the check fires. A rule that only runs in review runs too late: the code’s written, the author’s moved on, the reviewer is the bottleneck all over again. A rule that runs inside the editor, while the code is being typed, changes the whole economy of the thing. The constraint becomes a wall you hit in the moment instead of a verdict you get back a day later. And it doesn’t care who’s writing. A human in the editor and an agent generating a thousand lines hit the same wall at the same place. You stop having to trust that the agent absorbed your conventions, because trust never enters into it. The code passes or it doesn’t. And that’s the part that takes a minute to sit with, because we’ve spent this whole transition asking how to make the model write code that meets our standards, as if the answer were somewhere inside the model. It isn’t, and it can’t be, because the model doesn’t know your standards and won’t ever know them in a way you can rely on. The answer sits outside the model, in the constraints you’ve made explicit enough for a machine to check. You stop trying to grow a better author and start defining what acceptable output looks like, then let anything that wants to contribute clear that bar or fail trying. The author gets interchangeable. The specification is the thing you actually maintain now.

For a big organization this reprices a kind of work that has always felt like dead weight. Compliance: the rules a regulated company has to hold on every line it ships, access controls, data-handling requirements, the audit trail. None of it ships a single feature to a single customer. It’s the work developers do so the company is allowed to keep operating, and for years it’s been enforced through documentation, training, and a quiet hope that everyone remembers the policy under deadline. Write it as constraints the editor checks, and that entire class of requirement stops being something people have to remember and becomes something the system won’t let them violate in the first place. The compliance rule and the architectural rule turn out to be the same kind of object. Both are intent, written down, made enforceable.

Brooks’s law was never really about headcount. It was about the cost of keeping many minds aligned around one design, and how that cost climbs faster than the team that’s paying it. For fifty years the only move we had was to align the minds: hire slowly, document everything, review until your eyes bled. That move is failing under a load it was never built for, because the new contributors aren’t minds and they show up by the thousand.

So you move the alignment out of the minds and into the system. Write the constraint once, where the judgment actually lives, and let it hold against every author the same way. The seniors don’t review more. They decide what’s allowed to be true, and the codebase keeps enforcing that decision at three in the morning when nobody’s awake to defend it. The cohesion tax doesn’t go away. You just stop paying it one tired reviewer at a time.