Abstract

AI has made code generation astonishingly fast. It has also encouraged a dangerous assumption: if implementation is cheaper, software projects should move faster and teams should shrink. In practice, the opposite pressures soon appear. More generated code means more to understand, test, coordinate, and own. The more agents can do in parallel, the more human attention, judgment, and accountability become points of congestion.

Peopleware was never merely a book about noisy offices or management technique. It was a book about the conditions under which knowledge work can happen: how concentration forms, how teams cohere, how trust makes learning possible, and how management quietly destroys all three. AI has not made those questions obsolete. It has simply added machines to the list of things that can interrupt us, while giving every strength and weakness in an organization a larger lever.

AI has changed the speed of software production. It has not changed the fact at the heart of Peopleware: the hardest part of a software project is rarely the code. It is the people living with it.

Part I · The people hidden by the tools

01Why revisit Peopleware now?

The first time I read Peopleware, I took it for a book about managing software teams. Its concerns seemed wonderfully concrete: noisy offices, too many meetings, impossible schedules, staff turnover, team cohesion, and the many ways a manager can dismantle a good team without quite realizing it.

Reading it again after the arrival of AI coding tools, I noticed that Tom DeMarco and Timothy Lister were asking a more fundamental question. In software development, is the real constraint technical—or human?

For years, the industry treated productivity as a typing problem. We invented higher-level languages, more capable frameworks, better IDEs, and increasingly automated delivery pipelines. AI has carried that instinct to its logical extreme. One developer can now ask several agents to search a repository, change code, write tests, inspect logs, and update documentation at the same time. Work that once took days can produce a plausible candidate in hours.

And yet projects have not acquired infinite speed. Requirements are still ambiguous. Systems still have histories. Boundaries still require judgment. Releases still fail. Responsibility still has to land somewhere. When the third edition of Peopleware appeared in 2013, its publisher still described software development as being shaped by human rather than technical issues. In the age of agents, that claim feels sharper, not weaker.^[1]

As execution gets cheaper, framing, judgment, verification, and ownership get more expensive. AI did not remove the human bottleneck. It moved it upstream from the keyboard into the decision chain.

02The bottleneck did not disappear. It moved.

In conventional development, implementation time was the most visible scarcity. Plans revolved around one question: how long will it take to build? AI cuts that cost dramatically, but it does not reduce every adjacent cost at the same rate. Someone still has to understand the problem, choose an approach, review the change, verify the business rules, assess security, plan a migration, observe the release, and restore service when things go wrong.

The cost simply travels downstream. The old shape of the work might have been four hours of coding followed by one hour of review. The new shape might be ten minutes of generation followed by two hours of reconstruction and verification. In the first case, the waiting happened before production. In the second, the queue forms after it. Measure only generation and the improvement looks spectacular. Measure the entire value stream and the gain may be modest—or swallowed by rework.

DORA’s 2025 research on AI-assisted software development treats this as a systems problem. AI magnifies the conditions already present in a team and its delivery system. Strong platforms, loosely coupled architectures, and fast feedback can absorb a larger volume of change. Weak tests, slow workflows, and tightly coupled systems turn that same volume into instability.^[6]

That is where a modern reading of Peopleware begins: never mistake the local speed of a tool for the productivity of an organization.

Part II · Attention becomes the new production line

03AI removed waiting—and created more interruption

One of the most durable ideas in Peopleware is the value of uninterrupted time. Programmers, designers, and architects rarely do their best work in the gaps between notifications. The problem, the code, the business constraints, and the available design choices have to coexist in the mind long enough to become a usable model.

That model may take fifteen minutes to assemble; it may take half an hour. A message that consumes two minutes can therefore cost much more than two minutes. Research on task switching finds the same pattern: changing tasks requires people to shift goals and reactivate rules, and the cost grows with the complexity of those rules.^[2]

In the old development environment, interruptions mostly came from other people: a product manager asking for status, a tester reporting a bug, a manager calling an impromptu meeting, a colleague asking for help. In the AI environment, machines have joined the queue.

A developer may have three, five, or more agents running at once: one refactoring a service, another building a UI, a third writing tests, a fourth reading production logs. Each returns results, asks questions, requests permissions, reports a failure, or waits for a decision. The developer stops working on one coherent problem and starts hopping among several partially remembered worlds:

• What exactly did agent A change, and did it cross the task boundary?
• Is agent B’s failing test a code problem or an environment problem?
• Which approach did agent C take, and what assumptions did it discard?
• How do I stop agent D from “helpfully” refactoring an unrelated module?
• How do these independent outputs fit back into one system?

The programmer has become a scheduler of concurrent cognitive work. The catch is simple: agents can run in parallel; human understanding, judgment, and accountability remain largely serial.

This explains a distinctly modern kind of exhaustion. You may spend little of the day typing and still finish it depleted. The effort went into rebuilding context, handling exceptions, and closing cognitive loops that kept reopening.

04Code is abundant. High-quality attention is not.

The easiest mistake in AI-assisted development is to confuse lower implementation cost with lower cost everywhere. When generation capacity surges upstream, review, testing, integration, and decision-making become the new places where work waits.

Code can be generated in parallel; careful review cannot scale without limit. Options can be produced in batches; a team still has to choose among them. Tests can run automatically; someone still has to understand why they failed. Agents can retry indefinitely; people still own the production incident. If every workflow sends every exception to a human, attention becomes the single-threaded lock shared by the entire automation system.

A manager therefore needs questions more useful than “How many more agents can we add?”

Without answers, adding agents is like increasing the speed of an upstream conveyor belt after the line is already jammed. The result is not faster delivery. It is a review backlog, an overloaded test system, architectural drift, and more operational risk.

When production becomes cheap, the organization has to protect attention—not spend it even faster.

05The codebase grew. The team’s understanding did not.

Software organizations have always been tempted to substitute visible activity for difficult-to-measure value: lines of code, commit counts, features shipped, tickets closed, sprint velocity. AI makes those proxies more dangerous.

An agent can produce thousands of lines in minutes. It can create a dozen modules in one pass. It can turn a small fix into a handsome, fully structured refactor. If output is still the measure of productivity, AI can make almost any team’s numbers look excellent.

But code is not automatically an asset. It becomes one only when the team understands it, has evidence that it works, can change it safely, and knows why it exists. Otherwise, faster generation does not build capability. It builds cognitive debt.

When a developer writes a piece of code, they usually remember why it took that shape, which boundary conditions mattered, and which alternatives were rejected. The documentation may be incomplete, but the decision passed through a human mind. AI-generated code can arrive in the repository without that journey. It may run. It may pass the tests. It may even look cleaner than the handwritten version. And no one on the team may truly own it.

This creates a convincing project illusion. The feature is done. The demo works. The repository is growing. Yet the engineers are looking at a system that feels less familiar every week. Only when production misbehaves, a business rule changes, or a cross-cutting refactor becomes necessary does the organization discover that generated code never became controlled software capability.

In 2025, METR ran a randomized study with 16 experienced developers working on 246 real tasks in mature open-source repositories. With the particular tools and sample used at the time, developers allowed to use AI took about 19 percent longer on average, even while believing they had become faster. The researchers stressed that this was a snapshot of early-2025 tools and a specific population. By 2026, selection effects made a follow-up experiment too unreliable to support a confident current estimate. The enduring lesson is not that “AI makes developers slower.” It is that feeling faster is not a substitute for measuring the whole workflow.^[7][8]

Part III · A team is not a container to be compressed

06Psychological safety is part of AI reliability

Peopleware returns again and again to a truth that management theory often misses: a team cannot be assembled into cohesion by command. A real team develops trust, a shared purpose, an identity, and enough autonomy to act as a unit. None of these qualities matters less in the AI era. They matter more.

As AI takes on more coding work, engineers have reasonable questions. Is my experience becoming less valuable? Is the company adopting AI to help me, or to reduce headcount? If I turn my working methods into a skill or an agent, am I documenting my way out of a job? When generated code fails, who is accountable?

If management avoids those questions and talks only about efficiency, people protect themselves. Some keep useful methods private rather than turn them into organizational knowledge. Some perform adoption without changing how they work. Some create complexity only they can explain. Others lower their sense of ownership because “the model wrote it.” None of this is irrational. It is what uncertainty produces when candor feels unsafe.

Amy Edmondson defined team psychological safety as a shared belief that interpersonal risk-taking is safe within the team. Her study of 51 work teams associated psychological safety with learning behavior, which in turn connected to team performance.^[3] AI collaboration demands exactly this kind of risk-taking. People have to be able to say:

• “I do not understand this generated code yet.”
• “The tests pass, but I do not believe they cover the real risk.”
• “My prompt sent this in the wrong direction. We should start again.”
• “This problem is not ready for more automation. We need to clarify it first.”

If an organization makes “I don’t know” unsafe, AI magnifies false certainty. The model answers confidently. The engineer hesitates to object. The manager wants a visible win. Those three forces can carry code that nobody understands through every review and into production.

07Teamicide in the AI era

Peopleware coined a wonderfully severe word: teamicide. Capable teams are often damaged not by a lack of talent, but by the way they are managed—impossible deadlines, constant reshuffling, internal competition, excessive standardization, and process used as a substitute for trust.

AI gives management several new ways to commit the same old crime.

Turn engineers into agent operators

A manager may decide that the model can now handle most technical work, gradually remove design authority from engineers, and leave them to receive tasks, invoke agents, and submit the results. Output may rise for a while. Judgment will not. People who are no longer expected to make design decisions eventually lose the opportunity—and then the ability—to make good ones.

Turn AI use into an individual output contest

Who generated the most code? Who closed the most tickets? Who ran the most agents at once? These metrics look objective and reward exactly the wrong thing: local activity at the expense of shared review, knowledge, and responsibility. The SPACE framework already argues that developer productivity spans satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. No single activity metric can stand in for the whole.^[4] As generation gets cheaper, the distance between activity and value only grows.

Cut until the system loses its memory

Once some tasks can be automated, it is tempting to conclude that work once done by ten people now requires three. But those ten people did more than write code. They carried business memory, operational judgment, cross-functional relationships, customer context, on-call experience, and spare capacity for the unexpected. Those contributions are almost invisible in task counts. They are also what let a team recover when reality departs from the plan.

The people who look least productive on a dashboard may be carrying the context the system cannot regenerate.

08The best AI team is not the one with the fewest people

The AI era has produced an extreme but seductive picture of the future: one founder, surrounded by a tireless workforce of agents. That model can produce prototypes at remarkable speed. It may even operate a small product with clear boundaries. It is less convincing as a plan for the long life of a complex system, because the hardest problems in such systems are rarely questions of code generation.

Complex systems need the friction of different responsibilities. Architects think about long-term evolution. Developers see implementation and readability. Testers search for failure paths. Operators watch runtime behavior. Product people ask whether the work creates value. Security specialists imagine the paths ordinary use never takes.

AI can simulate each role and list the questions it might ask. What it struggles to reproduce is the judgment created by real consequences. The person responsible for production stability treats a harmless-looking dependency update differently. Someone who has lived through a financial reconciliation failure asks about idempotency before being prompted. Someone who has served the same customers for years knows which innocent sentence in the requirements is actually non-negotiable. That knowledge comes from experience under responsibility, not from information alone.

The aim of a strong AI team, then, is not to drive the human count toward zero. It is to move human time away from mechanical implementation and toward work that carries more value: framing problems, designing boundaries, testing reality, handling exceptions, building knowledge, repairing systems, and making tradeoffs that can be explained.

Part IV · Designing an environment for people and agents

09The manager’s new job: redesign the work environment

In the view of Peopleware, management is not primarily the art of keeping people busy. It is the work of creating an environment in which people can get something done. That idea survives intact in the AI era, but the environment has become larger.

It now includes more than quiet rooms, sensible meetings, and stable teams. It includes which resources an agent may access; which actions require human approval; which results must pass automated checks; how much of the system one task may change; how context is preserved and handed over; how concurrent workflows avoid overwriting each other; how work stops, rolls back, and recovers after failure; and who owns the final result.

None of this can be solved by adding one clever sentence to a prompt. If an organization buys AI tools for everyone but leaves the development system untouched, AI becomes an accelerator bolted onto the old machinery. It produces code faster. It does not make the requirements clearer, the decisions wiser, the tests stronger, or the releases safer.

The real change is to treat software delivery as an operating system shared by people and agents. Machines search, generate, repeat, and perform preliminary checks. People define goals, resolve ambiguity, make tradeoffs, recognize risk, and accept responsibility. The interface between those roles has to be explicit. So does the pace.

10Treat human attention as capacity, not as a free resource

The most common design error in an AI workflow is to count model throughput without counting human absorption. A patch may cost almost nothing to generate. Turning it into a trustworthy change still requires review time, domain knowledge, test evidence, and a release window. If any one of those is scarce, candidates wait in line.

Even a team with unlimited agents cannot deliver faster than its weakest control loop. Too much work in progress also damages the very capacity needed to clear it. Unfinished reviews, unanswered questions, parallel branches, and unresolved options occupy working memory and make every context switch more expensive.

Limiting concurrency is not a retreat from modern tooling. It is an engineering measure that protects cognitive integrity. A team can start with a few unglamorous practices:

• Set a limit on active agent workflows per engineer instead of rewarding unlimited concurrency.
• Filter low-confidence, duplicate, and out-of-scope results automatically before asking for human attention.
• Require every agent to deliver a change summary, key assumptions, verification evidence, and known gaps.
• Reserve uninterrupted, notification-free time for understanding and reviewing complex work.
• Measure the path from start to safe production, not merely the time the model spent generating.

Productivity research supports this broader view. SPACE rejects the single metric; DORA emphasizes the way platforms, process, architecture, and value streams shape the outcome of AI adoption.^[4][6] The manager’s real optimization target is not “model calls per engineer.” It is whether the team can deliver the right value with less cognitive strain and more dependable quality.

11Six Peopleware rules for AI teams

Bringing Peopleware into an agent workflow does not require a grand new management doctrine. A better place to start is to turn respect for human work into concrete system constraints.

12The better AI gets, the more Peopleware matters

The Mythical Man-Month taught us that adding people does not accelerate a software project linearly because communication and coordination grow with the team. Peopleware went further: even without adding people, even with better tools, productivity collapses when an organization ignores cognition, emotion, relationships, and the conditions of work.

AI has not overturned either book. It has given their old problems new forms.

We once worried about adding programmers to a late project. Now we should worry about adding agents to a process already out of control. Managers once consumed engineers’ days with meetings, reports, and procedure. Now model output, permission requests, review queues, and parallel tasks can consume the same finite attention. Teams once lost flow to office noise. Now they can lose it to AI workflows that never stop asking for the next decision.

The more capable the tool becomes, the easier it is to see the person as the slow, expensive component that should be compressed. Yet this is exactly when judgment, trust, responsibility, and imagination become most valuable. AI can generate code, but it cannot decide on behalf of an organization what deserves to exist. It can offer options, but it cannot carry the consequences of choosing one. It can imitate the language of collaboration, but it cannot automatically create trust.

After rereading Peopleware, my conclusion is not the comforting slogan that people will never be replaced. It is something less reassuring and more useful:

AI will not make a software organization better by itself. It will make the organization more like itself.

An organization that trusts people, protects focus, and cares about quality can use AI to extend its abilities dramatically. One that worships metrics, exhausts teams, and chases short-term output will use the same technology to accumulate technical debt, cognitive debt, and organizational debt at greater speed. DORA’s description of AI as an amplifier gives that observation a timely empirical echo.^[5]

The software teams that lead the next era may not run the most agents or have permanent access to the strongest model. They may simply be the first to understand that when code is no longer scarce, people are what must be protected.

Abstract

Generative AI has pushed the marginal cost of producing code to a level few software teams would have believed possible only a few years ago. That has encouraged a seductive conclusion: if code can be produced almost on demand, the old laws of software engineering must be on their way out.

This essay argues the opposite. What endures in The Mythical Man-Month is not Brooks’s view of a particular language or tool. It is his account of complexity, communication, organizational structure, and conceptual integrity. AI changes the division of labor and the speed of feedback. It does not decide what a product ought to be, which constraints matter, or who remains answerable when a system fails.

The chapters that follow revisit Brooks’s central arguments and carry them forward into coding agents, multi-agent coordination, context engineering, architecture constraints, evaluation, and organizational knowledge. The point is neither that AI is merely another tool nor that it makes software engineering obsolete. The control plane of software development is moving upward—from code toward knowledge, boundaries, and systems of verification.

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.