MyTechDailyNews Explains: Why Throwing More AI Agents at a Vague Project Makes It Worse

By Sarah Chen · Tech Daily · General desk · tips and questions: hello@techdaily.com

Extra hands are not the same thing as extra progress

Almost everyone shares one reflex. When a task slips, reach for more people: it feels decisive, it feels generous, and it usually makes the deadline worse. I was reminded of this while standing beside a meeting-room table with my arms folded, deliberately doing nothing useful.

Last weekend, four people were crowded around a laptop and a screen, trying to get the two of them to cooperate. I watched with zero intent of volunteering, until one of them finally gestured me over and asked for a second look.

What came out was half laugh: "Haha sorry no! My experience is that adding more people will not solve this problem any quicker". A tiny, ordinary moment, with a very old idea sitting behind it.

Where the rule came from

The observation hiding behind that joke is Brooks's Law, formulated by computer scientist Frederick P. Brooks Jr. in his 1975 book The Mythical Man-Month, drawn from his experience managing the IBM OS/360 project. Its own wording is blunt: "Adding manpower to a late software project makes it later."

Decades later the sentence still lands, because the expense it describes was never really about effort. It is about communication. Every additional participant adds channels that must be synchronised, decisions that must be re-explained, and edges of the work that suddenly have to be joined up again. A bigger group does not divide the task; it divides its attention.

What AI agents appeared to break

At first glance, AI agents and large language models look as if they delete exactly the friction Brooks was describing. On paper, an agent:

• is productive within milliseconds of being started, rather than waiting through onboarding,
• has never sat through a status meeting,
• plays no organisational power games,
• does not pause for caffeine,
• and needs no persuasion to pick up a half-finished piece of someone else's work.

If the only real cost of a helper were ramp-up time and meetings, then endless helpers should mean endless speed. That is the promise — and the part worth re-examining.

What actually changed: the overhead moved to a different counter

Look closer and the law has not vanished. It has changed shape. The coordination bill is still being paid. The manager's job did not disappear; only its object changed — you are herding agents now. Yet somebody still has to spell out what done means, read the generated code, spot the hallucinations, and weld the fragments into one result. Nobody volunteers for that seat, so the seat is yours.

Where the work stalls	Classic team version	Agent-heavy version
Getting started	Slow onboarding, documents, introductions	Instant startup, but no shared context
Staying aligned	Stand-ups, status threads, hallway conversations	Prompting, orchestration rules, sequencing
Protecting quality	Peer review and testing	Hunting for hallucinations and confident wrong turns
Joining the parts	Merging branches, resolving conflicts	Weaving parallel outputs into one story
Deciding what "done" means	Written by a human, argued about in a meeting	Still written by a human, still argued about

The Baby Problem never got an upgrade

The classic illustration is the Baby Problem: nine agents cannot deliver a baby in one month. Some work is simply not divisible. Sequence is built into it — a decision has to exist before the build, the build before the verification, the verification before the release. Work that has to happen in order still happens in order, whoever or whatever is doing it.

When you slice a task that has no natural seams, you are not running pieces side by side. You are multiplying handoffs, and every handoff is a place where intent leaks out.

The 2026 restatement

Point nine autonomous agents at a single codebase and refuse to give them an unambiguous plan for who does what, and the likely outcome is not acceleration: it is a rapid loop in which each run cheerfully overwrites the last one's work, every pass confident and every pass slightly off-course.

A 2026 update to Brooks's Law might read: "Adding agents to a project with unclear requirements gets you the wrong answer faster."

That is the twist ordinary readers should care about. The technology has become far better at producing output, while most of our failures are still failures of input: what we asked for, and how clearly we knew it ourselves.

Common misconceptions

• "Agents scale the way storage scales." Buying more capacity is cheap; adding more participants to one tangled task is not, because the cost lives in coordination.
• "More output equals more progress." Volume of produced code, text or slides is not the same as movement toward a finished, agreed outcome.
• "The bottleneck is typing speed." Removing the slowest typist from the loop achieves nothing if the goal is still ambiguous.
• "Automation will eventually decide what done means." It will not. That definition is a judgement about purpose, users and acceptable risk, and it stays with people.
• "Vague briefs are fine, the agent can guess." Confident guessing is precisely the failure mode — now delivered faster and in parallel.

Before you add another agent, run this checklist

1. Can you describe what done looks like in one sentence, without waving your hands?
2. Does the task split along real seams, or would every piece have to talk to every other piece?
3. Is there a named owner for review, and a stated standard they apply?
4. What breaks the tie when two agents produce conflicting results — a rule, or a coin flip?
5. Would one focused person with one agent beat five agents with no plan in this case?
6. Which step must finish before the next can even begin, and is that order respected?

FAQ: the questions this keeps raising

Is Brooks's Law obsolete now that helpers cost almost nothing to start?

No. The 1975 statement assumed expensive people; the constraint underneath it was communication, not payroll. Near-instant helpers can add communication paths faster than costly colleagues ever did, which is why a fuzzy project often looks more chaotic after automation, not less.

Does that mean teams should stop using AI agents?

Not at all. The useful move is to narrow the assignment and make the expectation explicit before delegating anything. Agents reward clarity and punish ambiguity at machine speed.

Why does my agent pile keep rewriting the same file?

Because unclear requirements let each run interpret the goal a little differently. With nine autonomous agents and no orchestration, those small differences compound into a loop where each new pass undoes the previous one.

Is a meeting-room cable problem really the same shape as a delayed project?

It is the same pattern at a much smaller scale: a sequential task, unclear ownership, and a crowd that adds attention rather than progress.

What is the one-line takeaway for a non-technical reader?

Adding agents to a project with unclear requirements gets you the wrong answer faster. Clarity, not capacity, is the scarce resource now.

Action suggestions

• Write the outcome first. Put the definition of done in a short paragraph before opening any tool, then measure every agent against that paragraph.
• Give each agent one seam. Draw a boundary it may not cross and name where its output hands over.
• Book review as real work. Reading, checking for hallucinations and stitching results together is the new production effort, so schedule it like one.
• Keep the sequence visible. Mark which steps genuinely wait on others so nobody, human or agent, tries to run them side by side.
• Cut the crowd, not the spec. Before adding a participant, ask whether what is missing is information, a decision, or an owner.

Bottom line

The lesson from four people, a laptop and a stubborn screen is not that help is useless. It is that help without clarity is only more traffic. Decades of software experience first made this visible in boardrooms; the agent era makes it visible to anyone with a subscription and a vague brief. Next time a project slips, resist the obvious instinct. Describe the finish line properly, then decide whether you need another pair of hands — human or digital — or simply a better question.

Filed under General on MyTechDailyNews, edited by Tech Daily. Have a counter-example or a story tip? Write to Sarah Chen at hello@techdaily.com.