Revisiting Peopleware:
The Better AI Gets, the More Software Depends on People

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.