The first time you can spin up more agents than your team can review, you start to believe the old laws of software no longer apply.
Why worry about staffing when the staff is elastic? Why wait for an engineer to pick up a ticket when an agent can start immediately? Why sequence work carefully when you can run every idea at once?
This is the seductive part of agentic software development: it makes labor feel infinite.
But infinite labor does not produce infinite progress. It often produces infinite unfinished work.
Fred Brooks gave software one of its durable warnings in _The Mythical Man-Month_: adding people to a late software project can make it later. Martin Fowler recently revisited the book and pulled out the lesson that still matters most: communication overhead and conceptual integrity do not disappear just because you add more hands.
Agents change the economics. They do not repeal the systems problem.
Code gets cheaper faster than coordination gets better.
That is the agent-era version of Brooks's law. The mythical agent month is the assumption that agent-hours convert linearly into engineering progress. They do not. The exchange rate is set by the surrounding delivery system: context, review, validation, integration, release, and learning.
The unit of scarcity moved from code production to coherent absorption.
The future is not asking an agent to write a bit of code. The future is building a factory where agents can move work across the entire software delivery system, and the system knows when to stop them.
The Monday Morning Problem
Imagine a team gives everyone access to cheap coding agents on Friday afternoon.
The instruction is simple: pick useful work, run agents in parallel, and come back Monday with progress.
By Monday, the team has eighteen pull requests. Three touch the same state management layer. Five are probably good but nobody has reviewed them. Four are blocked on the same failing CI job. One migration works locally but nobody knows whether it is safe for production. Several agent transcripts contain useful investigation notes that never made it into the PR descriptions.
The dashboard looks productive. The system is jammed.
Most agent demos optimize for the wrong thing: how fast code appears. The demo ends when the agent edits files, runs tests, and opens a pull request because that is the magical part.
But real software does not end when code appears. Someone has to understand the change, compare it to product intent, verify the tests, integrate it with the rest of the system, release it, watch production, and absorb the lesson into the next run.
If those steps are slow, weak, or missing, faster code generation makes the organization worse.
The team did not gain eighteen units of progress. It gained eighteen units of inventory.
Inventory is any generated work the system has not yet understood, validated, integrated, or learned from.
And inventory hides problems.
Inventory Is Not Flow
The useful lens is not code-generation speed. It is flow.
By factory, I do not mean a room full of agents kept busy. I mean the system that turns intent into verified change. Flow is the movement of valuable change through the whole path: specification, implementation, validation, review, release, observation, and learning.
_The Phoenix Project_ popularized a DevOps, Theory of Constraints, and Lean framing for software: visible work, small batches, feedback loops, bottleneck management, and work-in-process limits. Jidoka comes more directly from the Toyota Production System: build quality into the process and stop when something abnormal happens.
Those ideas become more important with agents, not less.
Lean does not ask: how do we keep every machine busy?
Lean asks: how does value flow through the system, where is the constraint, and what is creating waste?
That distinction matters because agentic development makes it dangerously easy to optimize for machine utilization. You can keep agents busy all day. You can keep them writing code, summarizing tickets, opening branches, rewriting tests, and drafting PR descriptions.
But a busy factory is not necessarily a productive factory.
A hundred idle agents are not the problem. A hundred busy agents producing unreviewed, unvalidated, incoherent work are the problem.
Agentic development also multiplies invisible WIP. Software teams notice tickets and maybe pull requests. They do not always count stale branches, unreviewed diffs, failed CI attempts, ambiguous specs, half-finished investigations, unmerged migrations, or agent transcripts that contain useful findings nobody captured.
Count agent WIP as anything requiring human interpretation, review, validation, cleanup, or decision.
This is where the Theory of Constraints matters. Improving work before the bottleneck just piles more work in front of the bottleneck. If review is the bottleneck, more coding agents create review inventory. If CI is the bottleneck, more agents create build queues. If product judgment is the bottleneck, more agents create decisions nobody has time to make.
The question is not "how many agents can we run?"
The question is:
What is the maximum amount of verified, coherent, valuable change our system can absorb?
That is the factory question.
The Mythical Agent Month
The agent version of Brooks's law is not exactly the same as the human version.
Agents remove some human coordination costs. They introduce artifact coordination costs.
You can duplicate them instantly. You can assign one agent to inspect API routes, another to read tests, another to profile bundle size, another to write a migration plan.
That is real leverage.
But every agent run needs a brief. Every brief encodes assumptions. Every run consumes context. Every output needs to be compared against intent. Every write-mode task creates merge risk. Every pull request enters a review queue. Every failed run creates cleanup. Every plausible but wrong explanation creates context debt.
The communication path is no longer mostly person-to-person. It is:
intent -> task packet -> agent -> artifact -> reviewer -> correction -> playbook -> future agent
If that path is weak, spawning more agents makes the project later in a new way. Not because the agents talk too much, but because their outputs pile up faster than the system can integrate them.
The mythical agent month is the belief that one hundred agent-hours can be exchanged cleanly for one hundred hours of engineering progress.
Sometimes they can.
Usually they cannot.
The exchange rate depends on task independence, validation quality, review capacity, and architectural coupling.
Where Parallel Agents Work
The problem is not parallelism. The problem is unmanaged parallelism.
Parallel agents are excellent when the work is independent, bounded, easy to validate, and cheap to discard.
Good parallelism looks like scans, audits, benchmarks, classifications, and isolated repair attempts. One hundred agents can scan one hundred repositories for dependency drift, classify flaky CI failures, compare candidate libraries, run independent benchmark configurations, audit documentation freshness, search for a security pattern across many services, or try multiple repair strategies in isolated worktrees.
Bad parallelism looks like many agents sharing one design surface. They should not independently redesign your onboarding flow. They should not all edit the same state management layer. They should not refactor a shared module without ownership boundaries. They should not make architecture decisions by majority vote.
Required control looks like a schema, a ranking function, a validation path, and a discard path. The agents do not need to share much context if the output can be deduplicated, ranked, validated, or thrown away.
AI is good at local plausibility. It can produce many changes that look reasonable in isolation and make the system worse together. A generated test helper, a small API cleanup, and a "simplifying" state refactor can each pass locally while creating a product that is harder to reason about after the merge.
This is Brooks's conceptual integrity problem in agentic form.
The system needs a center of gravity:
- one product intent;
- one architecture vocabulary;
- one task contract;
- one validation standard;
- one review rubric;
- one source of truth for decisions.
Without that, parallel agents do not create a factory. They create a bazaar of plausible ideas.
The work may all be "good." The product still gets worse.
The Agentic Factory
The real agentic shift is not that agents can write code.
It is that agents can participate across the entire software development lifecycle.
An agent can help shape the spec. Another can map the affected systems. Another can inspect prior incidents. Another can propose a test plan. Another can implement. Another can review. Another can triage CI. Another can draft release notes. Another can monitor production. Another can update the playbook so the next run is better.
That is the factory.
The production line is no longer "ticket goes in, code comes out." It is intake, spec shaping, impact analysis, planning, environment setup, implementation, validation, review, release, observation, and learning.
Most teams are still operating as if the important step is implementation. That is why their agent strategy feels chaotic. They automated the loudest part of the system, not the whole value stream.
The CDD move is to treat context, validation, and learning as first-class parts of the production line.
Context is not prework. Validation is not postwork. Learning is not retro work. They are production stations.
The code is just one station.
The Controls
The boring parts are the important parts.
An agentic software factory needs typed task packets. Every run should know:
- objective;
- scope;
- non-goals;
- allowed files;
- risk tier;
- acceptance criteria;
- validation commands;
- stop rules;
- escalation owner;
- artifact requirements.
This is how intent becomes executable without becoming vague.
It needs WIP limits. Concurrency should be capped by the capacity of the downstream system, not by how many agents the provider will let you spawn. You might allow:
- twenty-five read-only repo scans;
- ten CI triage agents;
- three unrelated small fixes in one repo;
- one shared-module refactor;
- zero high-risk write-mode tasks without explicit approval.
The exact numbers are less important than the principle: concurrency should be limited by downstream absorption capacity.
It needs telemetry. If you do not know which task classes succeed, which ones churn, which agents create rework, and where humans spend review time, you are not running a factory. You are running a vibes-based job shop.
Useful metrics are not mysterious: merged PRs per reviewer-hour, agent PR acceptance rate, rework rate, review queue age, CI-blocked branches, abandoned generated branches, and time from task packet to validated merge.
And it needs jidoka.
Most bad agent workflows encourage the agent to keep going. The prompt says "do your best." The agent hits an ambiguous decision and makes one up. The test environment is missing, so it claims a plausible validation path. A file outside the intended scope looks relevant, so it edits it. The diff grows. The confidence stays high.
This is not autonomy. This is a machine without an andon cord.
An agent factory needs explicit stop-the-line rules:
- stop if the task cannot be validated;
- stop if the diff exceeds the declared scope;
- stop if production data or secrets are required;
- stop if tests fail in an unexpected way;
- stop if the agent discovers the task is higher risk than classified;
- stop if two agents are touching the same ownership boundary;
- stop if the acceptance criteria no longer match the work;
- stop if the agent cannot explain the decision path in terms of the task packet.
The output of a stopped run should not be "failed."
It should be evidence: what was attempted, what was learned, what blocked progress, who needs to decide, and what should change in the task packet, playbook, test suite, or permission model.
That is how the factory improves.
Kaizen, Not Magic
Agent failures should not be treated as mysterious betrayals. They are operational data.
The agent followed the wrong convention. Good. The convention was not visible enough.
The agent changed too many files. Good. The scope boundary was too weak.
The agent passed tests but broke the product. Good. The evidence loop was incomplete.
Every one of those failures should feed back into the system: better task packets, better tests, better playbooks, better stop rules, better routing, better review rubrics, better examples, better memory.
That is kaizen. The factory is not just a room full of machines. It is a learning system wrapped around production.
A better model inside a broken method produces better-looking waste.
The Bottom Line
The Mythical Man-Month survived because it was never really about arithmetic. It was about coordination.
The Mythical Agent Month is the same warning in a new economic regime.
Agents make execution cheap. They do not make coordination free. They do not make validation free. They do not make product judgment free. They do not preserve conceptual integrity by default.
The senior engineering job does not disappear. It becomes delivery-system design: less time writing every line, more time designing the system that turns intent into safe shipped change.
If you use agents as a shortcut around the software delivery system, they will make the mess faster.
If you use agents as stations inside a designed factory, they can transform the whole SDLC.
Parallelize execution.
Centralize judgment.
Build the factory.
The Mythical Agent Month is part of the Context-Driven Development framework for building AI-native software systems that stay coherent as machine labor gets cheap.