Ambiguity Is the Bottleneck: What Software Teams Learn From Brooks's Law and AI Agents

When a release schedule becomes fragile, teams often look for extra capacity before examining the source of friction. They add reviewers, prompts, workflows, or agents. That response can help when the obstacle is simple throughput, but it can hurt when the obstacle is ambiguity. The engineering lesson is to separate work that needs more hands from work that needs a clearer target.

The point became visible through a tiny hardware incident. Last weekend, four people were trying to make a laptop and a display communicate. I watched with zero intent to intervene, until someone asked me to check the setup. My answer was a joke with a serious core: Haha sorry no! My experience is that adding more people will not solve this problem any quicker. The same logic applies to software development when requirements are fuzzy and dependencies are real.

The rule is associated with Frederick P. Brooks Jr., who in 1975 published The Mythical Man-Month after drawing on experience with IBM OS/360. His formulation states: Adding manpower to a late software project makes it later. The statement is not an insult to staff capability. It is a description of coordination cost and sequential constraints.

The Baby Problem remains a useful shorthand: nine agents cannot shorten work that inherently takes one month. A product decision, integration boundary, or acceptance criterion may need to be settled before additional agents add value.

How the bottleneck changes shape in agent-based delivery

AI agents and large language models can make old project delays appear weaker. An agent can become productive in milliseconds, skip routine status meetings, avoid political friction, and operate without breaks. Those properties can remove a category of human coordination overhead.

The overhead does not disappear. It moves to a different table: you are now managing agents. The human task shifts from assigning people to assigning instructions, inspecting output, and reconciling conflicts. Someone must still define done, review generated code, identify hallucinated content, and assemble parts into a coherent deliverable.

A possible 2026 restatement for software teams

Consider the failure mode when nine autonomous agents touch a single codebase and no explicit orchestration exists. They may overwrite, reinterpret, or contradict each other's changes at machine speed. The result can be worse than slow progress because the wrong direction is polished more quickly.

One concise 2026 restatement is: Adding agents to a project with unclear requirements gets you the wrong answer faster. The emphasis moves from manpower quantity to specification quality. In software development work, the limiting factor may be deciding what counts as correct, not generating more candidates.

Signals that the real problem is unclear work

A team should suspect ambiguity before adding agents if the following signals are present:

• Two stakeholders describe the accepted outcome differently.
• Developers disagree about which behavior is correct in a review.
• Tests are being written to match a moving expectation rather than a stable requirement.
• Generated patches keep changing the same interface because the boundary was never fixed.
• Review comments focus on intent rather than syntax.

None of these signals is solved by more contributors. They are solved by clearer decisions. Agents can execute those decisions, but they do not decide them.

Comparison: classic overhead versus agent-era overhead

Question for a team	Classic project concern	Agent-era concern
What is the bottleneck?	Too few people available to do work.	Requirements, acceptance, or integration boundaries remain unclear.
What must be added before output counts?	Coordination, communication, and review among people.	Orchestration, review, and stitching of generated outputs.
What still cannot be parallelized?	Tasks with real dependencies.	Tasks with real dependencies; agents do not dissolve sequence.
What can become more expensive?	Meetings and handoffs.	Definition work and review debt.

Step-by-step workflow for using agents without breaking delivery

The following workflow is a review discipline for agent-assisted software work.

1. Identify the sequence. Map the steps that must occur before the next step can be valid. If the task resembles the Baby Problem, resist the urge to multiply contributors.
2. State the completion test. Write what will be accepted, what will be rejected, and what evidence will be used. The word done must be concrete enough that two people can evaluate the same artifact against it.
3. Give each agent a bounded input. Instead of asking an agent to improve a feature, provide the target module, the behavior, the test condition, and the known constraint.
4. Inspect before trusting. Generated code, tests, and documentation are candidate outputs until reviewed. The review should look for contradictions, invented assumptions, and missing integration points.
5. Track who catches hallucinations. Make it explicit which human or pair is responsible for detecting unverified content. If nobody owns that step, more agents increase review noise.
6. Assemble the final result deliberately. Partial patches, summaries, and designs are not the deliverable until one coherent view exists. The stitcher should be able to explain why the finished output meets the completion test.
7. Pause agent expansion when conflicts loop. If outputs repeatedly conflict with one another, add clarity, not more agents.

Common misconceptions that make agent projects fragile

• Agents skip meetings, so they skip coordination. Coordination becomes instruction precision, acceptance review, and conflict resolution.
• More generated options equal more progress. Options multiply review load and can obscure the intended behavior.
• AI can infer what the team means. It can infer plausible continuations, but it does not automatically know the agreed boundary of a product, codebase, or release.
• A fast draft is a finished draft. Draft speed can make ambiguity more expensive because each draft must be compared, merged, or rejected.

FAQ: what the old law means for AI-assisted software delivery

Should a delayed project avoid AI agents altogether?

Not necessarily. The question to ask is what the agent will reduce. If the bottleneck is producing text for a clearly bounded and nonsequential task, agents may help. If the bottleneck is unclear acceptance, agents may create more interpretation to review.

Why does adding agents sometimes feel productive before becoming costly?

Early generated outputs are easy to consume. Cost appears when several outputs disagree, when an assumption is hallucinated, or when the definition done was never explicit.

How does the 2026 update differ from the original law?

The original law described manpower added to late software work. The updated sentence describes agents added to unclear requirements. In both cases, the core issue is coordination and decision quality rather than raw effort.

Can orchestration replace human review?

Orchestration reduces chaos, but it does not create acceptance. Someone must still state done, inspect the code, detect hallucinations, and assemble pieces.

Action recommendations for the next sprint

Before scaling agents in a software development workflow, apply a small checklist:

• Name the dependency order for the current change before adding parallel work.
• Write one sentence that answers: what does done mean for this ticket?
• Decide how generated code will be reviewed and by whom.
• Make the hallucination-check step visible in the board or pull request process.
• Stop adding agents if repeated rewrites indicate missing acceptance criteria.
• Use agents for bounded, clearly specified pieces, while keeping final judgment human.

The useful takeaway is narrower than a technology critique. More agents do not fix unclear work. They reveal how unclear the work was. A team that defines sequence, completion, review, and assembly first can add agents with a better chance of getting a correct answer sooner.