Give a coding agent a requirement and watch it read the repository, change the implementation, run tests, and follow errors toward a fix. A thought comes naturally: software development is finally getting cheaper. Then comes one of software engineering’s most famous cautions: no silver bullet. Brooks used it to challenge the expectation that a single technological or managerial invention could deliver an order-of-magnitude improvement in productivity, reliability, or simplicity within a decade. That caution deserves another reading.
In No Silver Bullet, he separates two kinds of difficulty. One comes from implementation conditions, such as awkward languages and scarce machine resources. The other comes from the conceptual relationships software must embody. Better tools can reduce the first kind of work without deciding how the system should behave. If the second consumes most of the effort, making coding ten times faster cannot make the whole project ten times faster. The force of the argument comes from its account of software itself.
Software concentrates work in design
-
Implementation contains design. Constructing a building means turning a design into large quantities of physical materials and connections. Once software is complete, another copy is usually cheap; the costly work lies in first determining and expressing its behavior. Even with an architecture diagram in place, programmers must still resolve conditions, states, and interactions as they write. Coding contains substantial design work, making it difficult to separate deciding what to build from following instructions as neatly as an assembly process might.
-
Complexity lives in relationships. Software must accommodate many rules made by people. Identity, permissions, time, and historical data can each change an operation’s meaning. Explaining every feature individually does not explain everything that happens when they interact. Nor do these relationships fit neatly into a single floor plan. Code structure, data flow, and runtime ordering each have their own view, with errors often hiding where those views intersect. Software complexity thus becomes a cost of understanding, communication, and verification.
-
Requirements grow through use. Those rules also change. Some changes come from outside: the business shifts or a connected system is updated. Others arise when using the software helps people understand what they actually need. A workflow may sound reasonable in a description, yet using it reveals an unnecessary wait or a missing choice. The delivered software helps form the requirements, so development can rarely consist only of executing an answer settled beforehand. Building something and understanding the problem often have to alternate.
-
Understanding needs human continuity. For much of software’s history, this work has depended on people with finite cognitive capacity who need uninterrupted time to think. The Mythical Man-Month discusses the training and communication burden of adding staff: newcomers must understand existing work, requiring time from those already doing it. Peopleware turns to the work environment and team relationships. Together they point to a practical reality: software capacity depends on people forming and maintaining an effective understanding of the same system. Hours at desks cannot simply be added up into progress.
Think ahead, or get feedback sooner
Plan-driven development can be understood as a way of managing this cost: if later work is expensive, resolve problems that might waste it as early as possible. Requirements reviews reduce disagreement, architecture divides responsibilities, interfaces let people work separately, and change control prevents a local decision from disrupting the whole project. Stable documents and phase deliverables carry understanding between people. The appeal is clear: establish direction before committing substantial labor.
The difficulty is that some problems emerge only through implementation. Agreements written without practical feedback may merely settle misunderstandings earlier. In his 1970 paper on large software development, Royce already emphasizes early pilot work, test planning, and customer involvement: leaving risks until the end can make their consequences intolerable. Even a carefully planned approach needs reality to enter early enough to correct the plan.
Agile puts that feedback closer to the center. The principles behind the Agile Manifesto emphasize frequent delivery of working software and welcoming changing requirements. Commit to a shorter stretch, complete it, and let users and the team reassess the direction. The value lies in shortening the life of misunderstandings: an incorrect assumption discovered after a few days need not underpin months of subsequent development.
Frequent change also needs technical support. Test-driven development first turns expected behavior into executable examples, continuous integration exposes conflicts between parts early, and refactoring organizes the structure that has grown. In Is Design Dead?, Fowler explains how such practices support evolutionary design: keeping the next change affordable requires continuing work on structure and verification. Behind short iterations lies a substantial effort to reduce the cost of change.
Seen this way, both approaches address the same constraints: some relationships in the problem remain unclear, the environment changes, and human understanding and implementation are expensive. Upfront design aims to avoid wrong turns; shorter iterations aim to end them sooner. Both must weigh thinking more now against building something to learn from it. Much of software engineering is a search for the right balance between those choices.
Thinking becomes work we can call on
Coding agents change that calculation. They can follow a failure through state transitions, trace the actual meaning of a convention across files, or build two implementations for comparison through tests and runtime results. This involves understanding, design, and verification. Some conceptual work previously done by programmers can now be repeatedly assigned to models. Software remains complex, but the labor for handling that complexity has a new source.
Difficulty inherent in a problem is not the same as labor that humans must personally perform. That is why I think the silver-bullet question deserves reopening. The conditions, states, and relationships still need to be handled, but the speed, price, and parallel capacity for handling them are changing. Treating some portion of human cognitive cost as software’s eternal essence would confuse work that must be done with work that must always be done in the same way.
The simplified workload below illustrates this difference. First increase implementation speed: analysis, design, and external waiting become the dominant costs. Then increase analysis and design speed, and that previously limiting work begins to shrink too. The impact of a tool depends on which labor it can take on.
How does a new cost of labor reshape development?
Recalculate the cost of documents and iterations
Plan-driven development feels this change first. When a small runnable implementation can answer a question, adding several pages to a written specification may no longer be the cheapest approach. Design documents can still preserve key decisions, constraints, and reasons, while much of the procedural instruction written for implementers can be resolved through exploration and execution. Human planning should increasingly concentrate on decisions that are difficult to reverse, such as the meaning of data, external commitments, and responsibility boundaries between systems.
Agile also needs to reconsider its rhythm. Week-based sprints, decisions waiting for the next meeting, and tasks fragmented for assignment to different members all reflect the timescale of human teams. When an agent can carry a complete task forward, step-by-step human dispatch and confirmation turn automated work back into a human queue. Frequent feedback still matters, but its timing can follow the problem itself: when the model finds an ambiguity affecting the requirement, it brings that decision back.
Focus feedback and review on consequential decisions
This gives greater importance to the part of test-driven development that establishes what counts as correct. An agent can quickly write an implementation and tests that agree with it; their agreement shows that they express the same understanding. People need to examine which business behavior the tests fix, which important conditions they omit, and whether the validation environment can observe the outcomes that matter. Once those judgments become dependable feedback, agents can carry out many subsequent changes on their own.
The object of review changes with this. Translating every line generated by an agent back into human understanding requires reading speed to keep pace with machine production. A more effective arrangement makes business meaning and consequential engineering choices explicit and easy to review: people confirm behavior and boundaries, while models implement, find errors, and verify repeatedly. Architecture, tests, and repository organization gain another responsibility: expose the important decisions clearly and let routine work proceed continuously.
The continuity of understanding explored by The Mythical Man-Month and Peopleware can also acquire new supports. Another agent can begin with saved task state, searchable decision records, and an environment that reproduces the problem. More of a team’s accumulated understanding can then reside in its working system. Human attention remains scarce, but less of it needs to go toward repeatedly explaining background and more toward deciding which problems are worth solving and which outcomes are worth accepting.
So this time, I am willing to take the prospect of a silver bullet seriously. Agents are beginning to take on the understanding and design work that was hardest to mechanize. That is enough to reconsider the entire development process: settle the decisions worth fixing, and let agents continuously carry out work supported by useful feedback. Traditional methods’ respect for complexity and agile’s emphasis on feedback can endure, while divisions of labor and rhythms built around expensive human effort need redesign. Software engineering has a chance to engineer its own process again, under a different cost of labor.