Rereading The Mythical Man-Month

AI has not retired The Mythical Man-Month. It has enlarged the question: from organizing programmers to produce code, to organizing people and agents to keep complexity under control.

Part I · Returning to Brooks's problem

01Why reread The Mythical Man-Month now?

When The Mythical Man-Month first appeared in 1975, software was typed into terminals by hand, build cycles were expensive, and large systems were the province of a small number of institutions. Half a century later, we can ask a model—in ordinary language—to write an endpoint, expand a test suite, migrate a framework, or dispatch several agents into isolated workspaces. It looks like a different profession. Yet we have arrived at a version of Brooks’s old tar pit: output rises, but the system does not necessarily become easier to understand; more participants join the work, but the project does not necessarily finish sooner. ^[1]

The book survives because it is less concerned with tools than with ratios. How much of the work can be parallelized, and how much still depends on sequential decisions? How much local speed becomes end-to-end throughput? How much new capability can a system absorb before its cognitive burden outruns the team that owns it? Tools change those ratios. They do not make them disappear.

AI makes visible output unusually easy to count: lines changed, pull requests opened, prototypes produced, tickets closed. The less visible liabilities accumulate elsewhere—unstated assumptions, permissions no one modeled, migration paths no one rehearsed, on-call load, hidden coupling, and the mental model a future maintainer will have to reconstruct. Brooks’s enduring contribution is to pull our attention away from the pile of output and back toward the shape of the system.

A useful rereading therefore starts with three questions. Which costs has AI actually removed, and which has it merely pushed downstream? What happens to coordination when the set of contributors includes agents whose context is assembled afresh for each run? And what kind of knowledge and governance turns faster generation into software that can remain healthy for years?

02What a $5 billion bet taught us about software

Brooks did not arrive at his conclusions from a quiet study. In 1964 IBM introduced System/360, a compatible family of computers intended to replace several incompatible product lines. IBM remembers the program as a $5 billion, bet-the-company gamble; Fred Brooks was one of its project leaders. Its defining commercial promise was portability within the family: customers could grow their hardware without rewriting all their software. ^[3]

A unified hardware architecture created a platform, but it also concentrated unprecedented complexity in OS/360. Compatibility requirements, machine configurations, delivery schedules, organizational growth, and communication paths became one engineering problem. Under that pressure Brooks saw the flaw in treating software as divisible labor. Some tasks have an irreducible order. Newcomers must learn the system. Interfaces have to be negotiated. Existing team members stop producing while they explain, align, and integrate.

The modern parallel is not that an AI agent resembles a 1960s programmer. It is that we are living through another change in the production platform. Software organizations once treated the number of people available to write code as a scarce resource. Code supply is now expanding, so scarcity moves elsewhere: precise problem framing, domain judgment, architectural context, credible verification, and accountability for production outcomes. The production function has changed. Any organization that continues to manage the old scarcity will accumulate a large inventory of work that appears finished but has not truly been absorbed.

03What did fifty years of software engineering actually change?

Read as a list of technologies, the last fifty years look like a sequence of revolutions. Read as an engineering history, they form a surprisingly continuous line. Structured programming constrained arbitrary control flow. Object orientation tried to gather data and behavior into comprehensible units. Agile shortened the distance between a requirement and the feedback that could disprove it. Cloud computing made infrastructure programmable. DevOps brought build, test, release, and operations into one feedback system; platform engineering turned that system into an internal product. AI coding and Agent Engineering extend the same movement by making candidate implementation—and parts of the toolchain itself—delegable.

1968

The “software crisis” entered public debate, and software engineering began to take shape as a discipline.

1975

The Mythical Man-Month distilled the scheduling, organizational, and design lessons of large software programs. ^[1]

1987

Brooks published “No Silver Bullet,” separating essential complexity from accidental difficulty. ^[2]

1990s

Object orientation, design patterns, and open-source collaboration widened the boundary of reuse.

2001

The Agile Manifesto emphasized working software, human interaction, customer collaboration, and responsiveness to change. ^[10]

2010s

Cloud, continuous delivery, SRE, and DevOps pulled feedback and operations into everyday development.

2021

Natural-language code completion reached a mass audience; developers began working alongside models.

2024

Tool use and protocols such as MCP made it easier to connect models to repositories, data, and external systems. ^[28]

2025–26

Coding agents moved beyond completion to reading repositories, editing files, running tests, preparing changes for review, and working in parallel agent workbenches. ^{[24] [25]}

AI is not an alien break in this history; it is the next rise in the level of abstraction. Every such rise removes some manual work and creates a new control surface. High-level languages needed compilers and type systems. Cloud needed infrastructure as code and observability. Continuous delivery needed automated gates. Agents need context, tool permissions, run traces, evaluations, and human approval.

Part II · Eight classic arguments, read for the AI era

04AI changes the speed of coding, not the existence of essential complexity

In “No Silver Bullet,” Brooks separates two sources of difficulty. Essential complexity belongs to the problem itself: the relationships the software must faithfully express. Accidental complexity is imposed by our tools, representations, and implementation process. The distinction is often flattened into a slogan—“AI can only remove accidental complexity”—but the reality is more interesting.

AI plainly reduces a great deal of implementation friction. Boilerplate, data conversion, familiar endpoints, test scaffolding, query construction, first-draft documentation, and translation across languages can all be produced faster. It can also help people explore the essential problem by summarizing interviews, proposing counterexamples, comparing designs, tracing dependencies, and explaining an unfamiliar domain. AI is not merely a faster typist. Used well, it expands the surface area of thought.

Assistance is not abolition. A bank still has to decide what evidence justifies declining a transaction. A medical system still needs a defensible definition of acceptable risk. A collaboration product still has to reconcile permission inheritance, retention policy, and legal obligations. A model can offer candidate answers. It cannot make the trade-offs vanish, and it cannot grant itself the authority to bear the consequences.

There is a second-order effect as well. When accidental costs fall, systems tend to grow. If another service, setting, workflow, or abstraction can be added almost for free, “one more” becomes the default answer. The local implementation gets easier while the whole system becomes harder to hold in mind. This is complexity rebound: coding cost saved at one point in the value stream is consumed by more features, dependencies, states, and operational obligations elsewhere.

“There is no single development … which by itself promises even one order-of-magnitude improvement.”

Frederick P. Brooks Jr., “No Silver Bullet,” 1987 ^[2]

Brooks was not arguing against progress. He was arguing against the promise that one breakthrough would transform the entire economics of building software. AI may deliver order-of-magnitude gains on particular tasks. Once the unit of analysis expands from “produce a function” to “operate the right system safely for a decade,” the claim has to be tested again.

05Brooks’s Law: more agents can make a bad architecture fail faster

“Adding manpower to a late software project makes it later.”

The Mythical Man-Month, Chapter 2 ^[1]

The law bites when three conditions hold: the work cannot be divided cleanly, newcomers need context, and the outputs must eventually be integrated. Human teams meet all three conditions. Agent systems do too. Ten agents do not create ten times the throughput if they read different versions of the requirement, edit the same surface, invent incompatible interfaces, and leave a human to settle the semantic conflicts at the end.

An agent appears to have almost no onboarding cost. Give it a repository, instructions, and tools, and it can begin. But its context is not durable understanding; it is a selection of information assembled, compressed, and reconstructed for a particular run. More parallel tasks mean more context slices, branches, build slots, and candidate changes demanding judgment. Where boundaries are vague, agents scale the vagueness with impressive efficiency.

A contemporary form of Brooks’s Law might read: adding agents to a project that has lost its conceptual boundaries usually produces more locally plausible work that cannot be safely combined. The remedy is not to reject parallelism. It is to improve divisibility first: define ownership, stabilize interfaces, write acceptance conditions, restrict write scopes, make every change independently testable—and only then choose the level of concurrency.

06The Surgical Team: are agents its digital counterpart?

Brooks borrowed Harlan Mills’s idea of a “surgical team”: one chief programmer preserves the intellectual unity of the design and implementation, while specialists support that person much as anesthetists, nurses, and technicians support a surgeon. The point was not to celebrate the lone hero. It was to avoid dividing one central design evenly among many people and hoping that coherence would somehow emerge.

Coding agents give the idea a new and quite practical form. A technical lead can ask one agent to search the project history, another to write a migration, a third to extend the tests, and others to inspect security risks or update documentation. The lead keeps authority over the problem statement, the choice of design, and the final merge. OpenAI’s 2025 introduction of Codex described an engineering agent that could work on software tasks in parallel, inside isolated cloud environments, run tests, and return changes for review. By 2026, the product surface had shifted further toward supervising several long-running agents at once. ^{[24] [25]}

This digital surgical team works only when the surgeon actually understands the system. If the lead merely distributes vague requests and nobody maintains the whole model, the arrangement becomes ten scalpels cutting at once. AI cannot supply an absent design authority. It can only amplify the authority, rules, and blind spots already present.

Nor should a modern version reproduce every weakness of a single-expert hierarchy. Conceptual authority may be concentrated, but evidence and dissent should be distributed. A security agent should be able to challenge the favored design; a test agent should look for counterexamples; a domain expert should be able to reject a false premise; important decisions should still face team review. The strongest structure is not “one person is always right,” but “one design thread remains legible while disagreement is deliberately organized.”

07Conceptual integrity is becoming a scarce advantage

Brooks considered conceptual integrity the most important quality in system design. Users do not experience the organization chart behind a product. They experience whether the product follows a predictable set of ideas: whether the same word means the same thing, similar actions behave alike, errors are expressed consistently, and permissions and data lifecycles obey a recognizable logic.

Conceptual integrity is not the same as stylistic consistency. A formatter can standardize indentation, but it cannot decide whether “customer” and “account” belong to the same domain boundary. A framework can standardize controller code, but it cannot decide whether inventory should be reserved at order time, payment time, or shipment. The integrity that matters lives in meaning and trade-offs.

AI magnifies the difference. In a repository with precise names, stable boundaries, and tests that express business invariants, an agent can infer a sound pattern from many consistent examples. In a ten-year-old codebase containing five competing architectures, it has no reliable way to know which one represents the future. A model tends to choose the most locally plausible answer, and a historical accident quietly becomes the next convention.

This is why domain-driven design, architecture decision records, the C4 model, and evolutionary architecture have fresh importance in the AI era. ^{[12] [16] [17] [18]} Each, in a different way, makes the reason behind a design searchable, reviewable, and traceable. Their purpose is not to feed a model more prose. It is to give people and models a small, stable set of concepts they can share.

08The documentary hypothesis: the central repository will be a knowledge repository

In his “documentary hypothesis,” Brooks argued that a project needs a small set of pivotal documents to express its objectives, constraints, organization, budget, schedule, and interfaces. The lesson was never that more documentation is always better. It was that a few authoritative objects are needed to preserve a shared reality. In the AI era, that principle is more dependable than “the code is the documentation.”

When most code was written by people, an experienced developer could sometimes recover intent from names, commit history, and implementation detail. When agents generate substantial amounts of code quickly, the code looks more like the sediment left by decisions; it may contain very little of their rationale. An implementation passing today’s tests does not tell its next owner which behaviors are contractual promises, which are temporary choices, or which changes require a data migration or a customer notice.

A useful knowledge repository needs at least six kinds of material: business vocabulary and important scenarios; a system map and ownership boundaries; architectural principles and ADRs; interface and data contracts; build, test, and release instructions; and the lessons of incidents, rollbacks, and security boundaries. Prompts, skills, project rules, retrieval indexes, and agent memory can form an access layer. They are not substitutes for the underlying facts.

Documentation also needs a lifecycle. Material without an owner or a version—material that cannot be tested and expires separately from the code—gives an agent confidently wrong context. The healthier pattern is straightforward: one authoritative source for each fact; decisions linked to changes; contracts checked by machines wherever possible; examples drawn from real tests; and a way to detect and remove stale material.

09Why Babel failed: shared language is still infrastructure

The Mythical Man-Month uses Babel to discuss a failure of communication. Projects fail not only because the technology is hard, but because their participants cease to share a language and a picture of the system. As a group grows, its potential communication paths rise roughly with the square of its size. Hierarchies, modules, and interfaces exist in part to prevent every participant from having to communicate with every other one.

Agents do not tire of meetings, but they bring their own version of Babel. One reads the product specification, another reads the code, and a third receives only the task description. Each may carry a different definition of “done.” A larger context window does not settle conflicts between sources, determine which one is current, or establish which one has authority. Memory can make matters worse by carrying an obsolete judgment cleanly and consistently into a new task.

Open protocols such as the Model Context Protocol (MCP) and Agent2Agent (A2A) aim, respectively, to standardize how models connect to tools and data and how agents interoperate. ^{[28] [29]} This work matters, but a protocol answers whether information can be exchanged, not whether its meaning is agreed. HTTP allowed services to communicate; it did not eliminate contract failures in distributed systems. Agents being able to call one another does not give them a shared understanding.

Context engineering is therefore an information-architecture problem before it is a prompt-size problem. A system needs priorities among sources, timestamps, scope, versions, and a way to resolve conflict. A handoff should contain the decision summary, open questions, evidence, and validation status—not merely the full chat transcript. Shared language has to be designed.

10The second-system effect when features become nearly free

Brooks observed that designers of a second system are tempted to include every idea they restrained themselves from putting into the first. The result is often bloated and over-engineered. AI makes that temptation stronger. Features once rejected because they were expensive can now appear as prototypes in hours. An abstraction that once demanded careful debate can be produced by asking a model to “make it more general.”

The cost of generating a feature and the cost of owning it are not the same number. Every new capability widens the test matrix, permission surface, documentation, monitoring, compatibility promise, and set of choices presented to users. Agents are good at completing a visible happy path. Most long-term cost lies in the failure paths: how old data migrates, how partial success is compensated, what happens when a dependency times out, and how an audit explains an automated decision.

The danger in vibe coding is not the use of natural language. It is the confusion of “it runs” with “we can responsibly own it.” Prototypes should move fast. Once a system carries real money, data, or organizational process, it owes a productionization tax: threat modeling, observability, capacity planning, recovery, data governance, and service objectives. AI can help pay that tax. It cannot declare the bill nonexistent.

Resisting the second-system effect means valuing deletion as highly as addition. Give the product a feature budget. Ask what concept each new concept replaces. Put limits on dependencies and configuration. Judge value by product outcomes, not generation speed. Mature AI engineering is not the ability to make anything; it is the judgment not to generate what should not exist.

11Plan to throw one away: from grand rewrites to replaceable experiments

“Plan to throw one away” is often repeated as a romantic case for the rewrite. Its real warning is that a first design, made before the problem is understood, will usually be a learning instrument. AI does make exploratory implementation cheaper. A team can compare data models, API shapes, or migration strategies quickly, using working code rather than slides to expose what it does not yet know.

Brooks reconsidered the maxim in the anniversary edition. He came to favor incremental growth: a system should develop through continuing feedback, not by completing one disposable whole and then replacing it wholesale. That revision matters even more now. AI lowers the cost of regenerating an implementation; it does not lower the cost of replacing a production system by the same amount. Production contains data, customer habits, external integrations, audit history, and hard-won operating knowledge. None can be recreated with a prompt.

The modern rule should be: make experiments disposable and assets migratable. Isolate uncertainty in a spike, sandbox, or shadow implementation. State the learning goal before the work enters the main branch. Protect external behavior with contract tests, make database migrations reversible, and replace old capability a piece at a time. When a prototype accidentally becomes production, require an explicit ownership and production-readiness review; having run once is not an inheritance mechanism.

AI also makes it practical to generate several candidates for the same requirement and choose among them with evaluations and benchmarks. Throwing one away then becomes the ordinary cost of search, not a failure. The evaluation criteria must come first, however. Otherwise, the team is simply choosing the most attractive of several answers it cannot explain.

12No silver bullet: why the myth keeps returning

Every generation of software technology spends a little time cast as the silver bullet: fourth-generation languages, objects, components, low-code systems, microservices, cloud-native platforms, and now large language models. All created genuine value. All met a new form of complexity when their field of application widened. The myth returns because a local gain in production is so easily projected onto the delivery of the whole system.

AI is unusual in that it touches many stages at once—requirements, design exploration, implementation, testing, operations, and knowledge retrieval. Its reach may prove broader than that of any previous single tool. Breadth is still not freedom from constraints. As long as software models a changing world, it must deal with incomplete requirements, conflicting aims, organizational power, and an unknowable future.

“No silver bullet” must not become an excuse for conservatism. Brooks did not claim that tools were useless. He argued that no single technology promised an order-of-magnitude improvement in software productivity, reliability, and simplicity within a decade. ^[2] An engineer can hold two ideas at once: use AI aggressively to remove repetitive work, and refuse to treat demo speed as lifecycle evidence.

Durable improvement usually comes from a combination: smaller system boundaries, clearer domain models, shorter feedback loops, better tools, more automated verification, safer releases, and healthier organizational design. AI can strengthen that combination. It cannot stand in for it.

Part III · From AI Coding to Agent Engineering

13From code assets to knowledge assets

Software organizations have long treated source code as their central asset, and with good reason: code is the final authority executed by the machine. As AI generation becomes ordinary, however, the economics begin to change. More implementations can be reproduced from specifications, contracts, and examples. Some code starts to resemble a compiled artifact or a cache—still important and carefully controlled, but no longer a complete account of the organization’s rarest knowledge.

That idea should not be stretched into another grand claim. Production code is not a temporary file that can be deleted on a whim. It contains verified edge cases, performance work, compliance evidence, and repairs made after incidents. If the knowledge that produced it is incomplete, the code itself may be the only surviving truth. “Code as cache” is a directional observation: stronger specifications and verification make more implementation detail reproducible. It is not a description of where most systems are today.

The assets that grow in value are those behind generation and judgment: domain models, constraints, policy, decision records, evaluation suites, failure cases, operational experience, tool capabilities, and permission models. They determine what an agent can produce and what must never enter production. TOGAF’s Architecture Repository, DDD’s domain knowledge, and SRE runbooks begin to look like parts of the same control plane. ^{[12] [14] [20]}

Knowledge assets differ from code assets in a fundamental way: storage alone does not make them valuable. Knowledge needs provenance, an owner, an applicability boundary, a refresh cycle, and a process for resolving conflict. A vector database can retrieve a passage; it cannot decide whether that passage still represents an organizational decision. Knowledge Engineering is less about retrieval scores than about governing what counts as fact.

14Agent Engineering: beyond the prompt, toward an operating system

Prompt Engineering asks how a single input can elicit a better output. Context Engineering asks which information a model should receive, and when. Loop Engineering deals with how a model uses tools, observes results, corrects itself, and stops. Agent Engineering places that model inside an operable, observable, governable system. Knowledge Engineering, finally, manages the production and lifecycle of the facts on which the whole system depends.

These are not competing phases. They contain one another. A good prompt cannot repair bad data. Good context cannot make an unbounded permission safe. A sound loop cannot rescue the wrong goal, and a well-designed agent cannot compensate for the absence of an authoritative source of organizational knowledge. As the engineering matures, attention shifts from “What did the model say?” to “Under what conditions may this system act, and how can its result be proved?”

OpenAI’s practical guide treats models, tools, and instructions as foundational, distinguishes single-agent from multi-agent orchestration, and emphasizes guardrails. The Agents SDK brings tool use, handoffs, sessions, human intervention, and tracing into the runtime; traces can capture generations, tool calls, handoffs, and guardrail events. ^{[26] [27]} Anthropic’s account of effective agents offers a complementary lesson: begin with simple, composable patterns and add autonomy only when the value of the task justifies the added complexity. ^[30]

The family resemblance to Brooks is strong. A few clear components beat an ornate framework. Organization and interfaces matter more than headcount. The system needs a control thread a person can still follow. Agent Engineering is not the art of connecting more models. It is the design of an execution organization that can delegate safely, detect drift, retain evidence, and stop when it should.

15Multiple agents are an organizational design, not free parallelism

Treating agents like cloud instances is one of the most misleading analogies in this field. Computation scales out cleanly when it has no shared state. Software work commonly revolves around shared concepts and shared files. Multiple agents help when the work is genuinely divisible: independent modules, distinct evidence sources, non-overlapping verification roles, or candidate results that can be recombined through explicit contracts.

As coupling rises, four taxes appear. There is a decomposition tax: someone must cut the problem into units that can actually be completed independently. There is a context tax: each agent needs enough information, without contradictions. There is a coordination tax: dependencies, order, and changes have to be scheduled. And there is a verification tax: the local results must eventually be shown to fit together at the system level.

Multi-agent designs tend to use one of two basic shapes. In a manager pattern, a central agent retains control and invokes specialist agents as tools. In a handoff pattern, control passes to a new specialist. The first keeps the main thread coherent; the second allows greater specialist autonomy in a long workflow. Neither is universally better. The choice depends on who must retain the final context, whether mistakes are reversible, and whether a transfer of control should involve the user. ^{[26] [27]}

The most useful rule still comes from queueing theory and continuous delivery: limit work in progress, keep batches small, and integrate early. Starting twenty tasks at once and settling the conflicts at the end is rarely as effective as maintaining a few high-value parallel streams, each continually passing build, test, and contract gates. The faster the agents work, the more important WIP limits become; otherwise, verification is simply the new late project.

16Architecture must become executable governance

Architecture documents have traditionally been written for people to read. With agents in the development path, architectural principles also have to operate at execution time. “Keep modules loosely coupled” is too vague on its own. A useful rule says which modules may depend on which, which service alone may write a particular class of data, which APIs require idempotency keys, which directories an agent must not edit, and which changes need approval from a security owner.

Architecture now needs two representations. One expresses intent for people: principles, models, trade-offs, and the reasons for exceptions. The other expresses constraints for machines: types, schemas, static-analysis rules, policy as code, tests, CI gates, permission manifests, and deployment checks. Intent without enforcement becomes a wish. Enforcement without intent becomes a prohibition nobody can explain.

An Architecture Guardian should not merely be another agent that leaves comments. It should be a layered control system. Low-risk rules run automatically. Medium-risk deviations require an explanation. High-risk actions require human approval. Every exception carries an owner and an expiry date. Tools follow least privilege; reading and writing are separated; an agent stops before an irreversible production action by default; important runs remain auditable; sensitive context has an explicit boundary.

Testing also expands into evaluation. Deterministic code can be checked with input-output assertions. A system containing models must also be evaluated for task success, tool choice, factuality, safety, cost, latency, and regression. Its evaluation suite should grow from real failures and critical business scenarios. Otherwise a model upgrade can improve the headline score while quietly changing the behavior at the edge of the business.

17Rethinking productivity: more code is not faster value

The worst managerial response to AI is to prove the return on investment with lines of code, commit counts, or tasks completed by agents. The SPACE framework already warns that developer productivity spans satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. No single measure can stand in for all five. ^[21] As generation gets cheaper, the distance between visible activity and delivered value only widens.

Empirical results also argue for restraint. In 2025, METR ran a randomized controlled trial with 16 developers working on 246 real tasks in mature open-source projects they knew well. Under the study’s particular population and early-2025 tools, the group allowed to use AI took about 19 percent longer on average. The researchers explicitly framed the result as a snapshot of a population, a toolset, and a moment—not a conclusion that AI will always reduce productivity. ^[32] Its most useful lesson is simpler: feeling faster is not a measurement.

The 2025 DORA report approaches the other side of the question. It describes successful AI adoption as a systems problem rather than a tool problem, and emphasizes value-stream management as the means by which local gains become product performance. ^[31] That is a Brooks-shaped argument. Individual speed is not project throughput; project throughput is not a business outcome. Architecture, platforms, process, and culture mediate the effect of the tool.

A credible scorecard watches four levels at once. At the task level: completion time, rework, and evaluation pass rate. At the engineering-system level: change lead time, deployment frequency, failure rate, and recovery time. At the team level: cognitive load, review queues, and the spread of knowledge. At the business level: user outcomes, risk, and total cost. The analysis should also separate greenfield work from legacy systems, familiar repositories from unfamiliar ones, and short tasks from long ones. An average is not a universal law.

18The human role moves toward intent, boundaries, and responsibility

“AI amplifies architects, not programmers” is memorable and incomplete. Good programmers have never been mere typists. At the level of code, they discover contradictions in requirements, performance limits, and failure modes. The change is not that programmers disappear while architects prevail. It is that every software role has to move toward judgments with greater leverage.

The engineer’s growing responsibilities include turning vague problems into testable hypotheses; finding domain boundaries and invariants; designing tasks that can be delegated safely; creating evaluations that expose mistakes; understanding the consequences for security, data, and operations; and maintaining a habit of disproof when a model offers a fluent answer. Reading and reviewing may matter more than personally entering every line.

Architects cannot retreat into the writing of rules either. Architecture is a set of decisions continually tested by code, measurements, and incidents. It belongs in the value stream. The architect needs to see where agents misread the system, which rules are routinely bypassed, and which boundaries create needless coordination—and then simplify the system in response. Governing AI behavior and governing software boundaries are becoming the same work.

Responsibility, above all, cannot be outsourced. An agent may propose a migration; the person approving the outage window still needs to understand the risk. An agent may generate an access policy; the person signing the compliance statement still needs to know who can reach the data. “The model recommended it” must not become an organizational passive voice. Every irreversible decision should have an answer to four questions: Who authorized it? On what evidence? How will it be monitored? How can it be undone?

Part IV · An engineering path for organizations

19From individual acceleration to organizational capability

The most common mistake in adopting coding agents is to buy seats first and wait for productivity to appear. Individuals can gain locally without much governance. Scaling the gain across an organization requires absorptive capacity. The sequence below is not a maturity certification. It is a practical order of operations intended to keep learning ahead of risk.

Phase one: choose bounded, verifiable work

Begin with tasks such as adding tests, synchronizing documentation, upgrading dependencies, fixing static-analysis findings, and building internal scaffolding. Each task class needs clear acceptance conditions, a dependable build, and a rollback path. Record baseline time and rework, not merely satisfaction. High-risk production actions, critical permissions, and irreversible data migrations should not yet be autonomous.

Phase two: repair the knowledge entrance and feedback loop

Give each repository a one-page system map: how to build, test, and run it; its major modules and owners; and its critical constraints and prohibitions. Remove stale documentation, add high-value tests, and shorten CI. Agents do not offer a shortcut around engineering health. Brittle tests and slow feedback directly limit how many useful loops an agent can complete.

Phase three: make architectural rules machine-checkable

Choose three to five of the most expensive kinds of drift—cross-layer dependencies, unauthorized data access, incompatible APIs, missing migrations, or leakage of sensitive information, for example—and turn them into static rules, contract tests, or policy gates. Keep the rule set small enough to trust, and give exceptions a formal route.

Phase four: delegate by risk tier

Classify work by reversibility, data sensitivity, blast radius, and user impact. Low-risk changes may be generated and verified automatically. Medium-risk work gets a named reviewer. For high-risk work, the agent researches and proposes but does not act. Every tier preserves provenance and traces. Permissions are granted for the task, not left open indefinitely.

Phase five: add multiple agents and long-running work later

Introduce specialist agents through a manager or handoff only after the failure modes of the single-agent workflow are understood. Give every handoff a structured packet: objective, current state, evidence, change scope, unresolved risks, and next step. Limit work in progress, and give long-running tasks budgets, checkpoints, and stop conditions.

Phase six: turn incidents and evaluations into knowledge

Convert misgenerations, missed defects, bad tool calls, and human takeovers into evaluation cases or clearer constraints. Regularly delete ineffective rules and obsolete memory. A mature organization is not one that never makes a mistake. It is one in which every mistake sharpens the control plane instead of merely lengthening the prompt.

20Software engineering’s next job: governing generative systems

The next era of software engineering will not be one in which nobody writes code. It will be one in which more systems contain deterministic software, probabilistic models, and agents able to take action. Their boundaries will be more dynamic than those of conventional applications: the same objective may produce different paths; tools and data change in real time; persistent memory carries the past into the present. Engineering expands from managing static artifacts to managing generative behavior.

The first change is that specifications become first-class assets again. This is not a return to enormous waterfall documents. It means maintaining evolvable, testable intent: scenarios, contracts, invariants, policies, and evaluations. Specifications and implementations will exchange feedback more rapidly and may even generate parts of one another, but people retain judgment over meaning.

The second is that the software supply chain becomes a knowledge supply chain. Organizations will track not only the origin of dependency packages, but also the models, instructions, tools, knowledge sources, and evaluation versions used by an agent. A defect may enter through an expired retrieval result, contaminated memory, or a changed permission—not through a code commit.

The third is that architecture extends from structural design to behavioral governance. Yesterday’s diagrams mainly explained how components connect. Tomorrow’s must also say who may act for whom, which decisions require approval, how a system presents evidence, and when autonomy must stop. Security, compliance, SRE, product, and architecture will meet earlier in the work.

The fourth is that source code is no longer the only human-machine boundary. Natural language, schemas, policies, skills, evaluation sets, and operational traces all define system behavior. Teams will need to version, test, review, release, and roll back these objects as they do code. Prompt review, skill review, and memory review are not replacements for code review; they are new surfaces of review.

The fifth is that advantage comes from the feedback system, not from one model. Foundation models will change and tools will converge. What remains difficult to copy is the organization’s way of encoding domain knowledge as boundaries, turning real failures into evaluations, turning operational evidence into improvements, and letting agents accelerate within those constraints. The stronger the loop, the more AI behaves like leverage. The weaker the loop, the more it behaves like an amplifier of complexity.

Conclusion: Brooks was not wrong; the object of management has changed

In 1975, the visible problem was how to organize programmers to deliver software systems of unprecedented size. In 2026, the problem has widened: how to organize people, models, tools, knowledge, and automation as they evolve a system together. We used to review commits; now we must also review an agent’s context and trail of action. We used to manage communication among developers; now we must manage handoffs among agents. Architectural constraints once lived mainly in human memory; now they must be understandable to people and executable by machines.

Some things have not changed. Software is still a model of a real problem, and every model contains choices. Complex systems still need conceptual integrity. Communication still consumes time. More participants still create coordination. Rapid production still does not replace sound judgment. Responsibility still belongs to people and institutions.

What has changed is the location of scarcity. Code is no longer the rarest input; knowledge and verification become the bottlenecks. Prototypes and candidate solutions are cheap, while selection and long-term ownership matter more. Agents amplify an architect’s reach—and propagate an architectural mistake at the same speed.

The deepest lesson of The Mythical Man-Month for the AI era is therefore not to distrust new tools, but to put them back inside the system. AI can help a good team verify, learn, and ship faster. It can also help an organization with unclear boundaries accumulate unexplained code at unprecedented speed. The difference has never been generation alone. It is the presence of clear intent, coherent concepts, dependable feedback, and people willing to own the consequences.

When code becomes cheap, judgment becomes expensive. When agents become ordinary, the heart of software engineering will be the reality they are required to obey.