Brooks's Law: More AI Agents, Faster Wrong Answers
Brooks's Law says that adding people to a late project makes it later. Its mutation in the AI era is sharper: adding agents to a project with unclear requirements doesn't just make it slower — it gets you to the wrong answer faster. That's the pain. You have a project whose requirements were never pinned down, and someone decides to solve it by spinning up several agents. Each agent produces at machine speed, so you don't wait longer for a correct answer: you wait less time for a confident, coherent, completely wrong one.
In classic development, confusion is a bottleneck. A human team can only move at a certain speed, and its misunderstandings take time to surface. With AI agents, the bottleneck disappears, but the confusion stays. Each agent finishes its part in minutes, and because the requirements were unclear, each part carries the same ambiguity in a different way. Integrating those parts multiplies mistakes instead of correcting them.
Day to day, this looks like a sprint to nowhere. You ask an agent to generate a feature, and it hands you code that looks plausible. You ask another to review it, and it approves because it shares the same wrong mental model. You add a third to write tests, and the tests pass against the incorrect behavior. The whole cycle feels productive until someone reads the requirements — or what's left of them.
The root of the problem isn't the agents. It's that nothing forces the output to be compared with something stable. When requirements are fuzzy, agents fill the gaps with assumptions. More agents means more assumptions, and every assumption looks like a decision to the next agent.
The pattern that breaks this cycle is making the AI review itself. In practice, it means introducing a moment in the flow where the agent's output turns back on itself: it states the requirements it inferred, lists the assumptions it made, and checks whether its answer actually satisfies them. A second pass, a different prompt, or a deliberate self-assessment catches the gap before it travels further.
Verification has to be concrete. Asking 'are you sure?' isn't enough. The agent needs to compare its answer with the original request, expose contradictions, and point out the missing details. When requirements are unclear, the most important verification is the first one: 'What exactly did you assume about what I asked you?' That question forces the agent to put the hidden requirements on the table.
Once you apply that pattern, the mutation of the law loses its teeth. You can still add agents, but they're no longer free to produce output without review. Each agent has a mandatory checkpoint where it examines its own reasoning. That changes the dynamic: instead of accelerating toward the wrong answer, agents start converging on a corrected common understanding.
The practical effect is that the project gets slower in the first minutes and faster afterward. The slowest step is the one where the agent stops and reviews its own work. That step is exactly what keeps the cascade of plausible misunderstandings from becoming the final deliverable.
You'll be tempted to skip the review because it feels like wasted time. The agent already gave you an answer, and it sounds convincing. But if requirements aren't clear, every answer is a timestamped assumption. Review isn't a formality; it's the only way to turn agents into detectors of confusion instead of multipliers of it. The pattern is simple enough to use today: make the AI review itself. Don't trust the first output, don't add more agents hoping one gets lucky; make self-verification a mandatory step in every agent's loop. That's the way through the pain. It doesn't magically define the missing requirements; it exposes them and gives you the chance to correct them before the wrong answer becomes the deliverable.