More AI agents won't rescue a late project. They'll sharpen the wrong answer

On October 27, developer-blogger j11g published a one-line update to a 51-year-old rule of software management. Frederick P. Brooks Jr.'s 1975 law, drawn from running IBM's OS/360 project, says: "Adding manpower to a late software project makes it later." The post's 2026 revision: "Adding agents to a project with unclear requirements gets you the wrong answer faster."

It is one blogger's argument, not a study, and it offers no measurements. But it points at a shift that matters to anyone budgeting for AI coding tools: the bottleneck is moving, not vanishing.

Why Brooks's Law existed

Brooks's original logic rested on two costs. New people take time to get up to speed, and every added person adds communication overhead: stand-ups, handoffs, disagreements about who owns what. Past a point, the coordination cost of a larger team outweighs the extra hands.

The post's author notes that AI agents appear to remove both costs. An agent is, in the author's words, up to speed in milliseconds and needs no coffee break. If the law was about human friction, it should fade.

Where the friction went

The author argues it didn't fade; it mutated. Two parts of Brooks's thinking survive.

The first is what the post calls the "Baby Problem": nine agents still can't deliver a baby in one month. Some work is sequential. Step two needs the output of step one, and no amount of parallel labor changes that.

The second is that overhead shifted rather than disappeared. Instead of managing people, you manage agents. Someone must define what "done" means, review the code, catch hallucinations (confident output that is simply wrong), and stitch the pieces together. The post's blunt summary: "That someone is you."

The post also describes a failure mode with no clean human equivalent. Point nine autonomous agents at one codebase without clear orchestration, the author says, and they will happily rewrite each other's work in a high-speed loop. Human teams collide too, but slowly enough that someone notices. Agents can churn through the collision at machine speed.

The signal

Read as evidence, the post suggests that the scarce resource in AI-assisted development is shifting from typing code to specifying intent and verifying results. Throughput of generated code is cheap and getting cheaper. What stays expensive is a precise statement of what you want and a trustworthy check that you got it. That is the same bottleneck Brooks identified in a different costume: the hard part of software was never the keystrokes.

If that holds, the productivity story for agents depends less on how many you can run and more on the quality of the requirements you hand them. Unclear requirements are not a new problem. The change is that a vague spec now produces a large volume of plausible, wrong work very quickly, and reviewing it falls on the same few people who wrote the spec.

One caution: the post is an observation, not evidence from a controlled project. It cites no data on agent teams, and its claims about looping agents are the author's description, not a measured result.

Questions You Should Be Asking

• Can anyone on the team state, in one paragraph, what "done" means for this project, and would two people write the same paragraph?
• Which tasks in our plan are truly sequential, and are we paying for parallel agents on work that cannot be parallelized?
• Who reviews agent output, how many hours does that take per week, and is that cost counted in the productivity claim we are being sold?
• What stops two agents from overwriting each other's work, and how would we notice if they did?
• If the requirements are wrong, how long before we find out: after one agent's run, or after nine?

What To Watch Next

Watch whether vendors and engineering teams start reporting review time and rework alongside lines or features generated. If agent tooling ships with orchestration, specification and verification features as headline selling points, the industry is conceding the post's argument. If claims stay focused on raw output volume, expect the old law to keep asserting itself in late projects.