Could This Finally Be the Silver Bullet?

In 1986, Frederick Brooks rejected an AI revolution in advance in “No Silver Bullet.”

People were already hoping that artificial intelligence, automatic programming, expert systems, graphical programming, and program verification would turn software development into something fundamentally different. Brooks’s judgment was sober: these technologies would certainly be useful, but none could produce an order-of-magnitude improvement in productivity, reliability, and simplicity at once. The hardest part of software had never been typing an idea into code. It was forming the complex, correct, and coherent conceptual structure behind the code.

Four decades later, the agent seems to have returned specifically to challenge him.

It can read an unfamiliar repository, search documentation, propose a design, modify dozens of files, run tests, inspect a page, trace a failure, and then ask another agent to review the result. One developer can start several tasks at once and wait for each to return a patch. Work that once crossed investigation, implementation, testing, and documentation can increasingly be delegated as one continuous unit.

This looks like more than a better editor or a higher-level programming language. The werewolf is standing in front of us, and the object in our hand really does shine like silver.

Before pulling the trigger, however, we have to answer one question:

What is the essential difference between an agent and a colleague?

If the answer is merely price and speed, then the agent is only software outsourcing taken to its limit. But price and speed are surface effects. The deeper change is this: a colleague is a durable member of an organization who shares consequences; an agent is an execution process that can be copied, reset, isolated, and temporarily instantiated by context.

That changes not one job, but the way software engineering organizes labor.

A colleague joins the organization; an agent is instantiated into the task

When a new colleague joins a project, the team does not gain an immediately usable pair of hands.

They need to understand why the product became what it is, learn historical reasons that were never written into the code, and discover which ugly interfaces cannot be broken. They gradually develop trust, responsibilities, and communication habits with everyone else. At the same time, they are not a function waiting to be called. They question goals, form preferences, carry reputation and consequences, and take what they learn today into tomorrow.

This is one reason the man-months in The Mythical Man-Month are not interchangeable. People are not uniform compute. Adding a person adds training, communication, and coordination, and it changes the relationship structure of the entire team. Adding people to a late project can make it later not because the newcomers cannot program, but because they must enter an organization.

An agent enters in a completely different way.

It can start inside an isolated worktree, load a task description, relevant files, project rules, and tests, then perform one bounded task. When the task ends, that instance can disappear. If another route needs exploration, three copies can begin from the same point. If the direction is wrong, every output can be discarded and the work restarted. The agent has no career identity that must continue and no social need to defend sunk cost when a design is rejected.

An agent is therefore not an extremely cheap colleague. A better formulation is:

A colleague has to join the organization; an agent can be compiled from organizational knowledge.

The goal, constraints, code state, tests, and completion criteria are the inputs to that compilation. If this knowledge exists only in the heads of a few long-time colleagues, the agent does not receive it automatically. Copying an agent that lacks context does not add capacity. It executes the same misunderstanding in parallel.

On the left, continuity is carried by a person. They accumulate tacit knowledge through collaboration and remain responsible for the outcome. There is no natural continuity on the right. Each agent is a temporary instance; continuity must be carried by the repository, specification, tests, task state, and feedback.

That is also why adding agents sometimes avoids Brooks’s Law and sometimes creates a faster disaster. Independent tasks with clear boundaries can be isolated and parallelized. When the shared design has not been expressed, parallelism only amplifies divergence. Agents remove part of the organizational cost of people, but turn formerly tacit organizational knowledge into a system interface that must be designed.

What disappears first is not programming, but the friction that keeps programming possible

In a software project, writing new logic with hands on a keyboard is only part of the work.

Someone must locate the right place to change, read the historical implementation, reproduce the failure, build the environment, compare approaches, decompose tasks, update dependencies, write migration scripts, add tests, inspect the diff, answer review comments, organize documentation, and wait for another team to confirm an interface. Much of this work does not directly create product behavior, yet it keeps the engineering process moving.

Agents are good at more than a block of code. They can connect these scattered activities into one execution: investigate, modify, run checks, then return the diff and the evidence. OpenAI’s research on Codex usage shows a shift from one-shot questions toward delegated work lasting minutes or hours. The task lengths are model estimates and should be read as directional, but the unit of work is clearly moving from “generate some text” toward “operate a process.” How agents are transforming work

This shifts the old problem posed by Peopleware. That book reminded the software industry that project problems are often not technological but environmental, organizational, and social. Agents do not make these problems vanish, but they begin to take over their mechanical parts. Plans, documents, review checklists, and status reports no longer exist only as management costs paid by human teams to keep one another synchronized. They also become organizational structure that a machine can read and execute.

In the past, a detailed plan could be dismissed as a document written for a drawer. Now it can let an agent that attended no meeting begin work in an isolated environment. In the past, tests were one part of quality assurance. Now they are also an external sense by which a one-off executor can detect that it has drifted.

Much of the “non-programming work” that once sustained team collaboration is moving from human labor into the agent’s runtime environment.

But more generated code does not imply more successful software engineering. DORA’s research on generative AI in software development found that AI improved some process measures, including documentation, code quality, and review speed, while delivery throughput and stability could still decline. One proposed explanation is that faster generation enlarged change batches while small batches and robust testing were forgotten. DORA: The impact of generative AI in software development

An agent can make every step in the wrong direction smoother. Once friction falls, direction becomes the main problem.

Giving only a goal compresses waterfall into a sentence

If an agent can investigate, design, program, and test, does the human only need to state the final goal?

“Build a team task manager.”

“Refactor this authorization module.”

“Make this page simpler.”

Then the agent decides everything and the human returns for acceptance. This sounds like genuine autonomy.

Yet this collaboration model hides an old assumption: before the project begins, the human already knows the complete requirement and merely lacks the labor to implement it. The goal can be handed off once; design and implementation then only need to approach it.

Brooks argued that approaching the goal is not the hardest part. Discovering the goal is. In “No Silver Bullet,” he wrote that clients cannot completely, precisely, and correctly specify the requirements of modern software before they have built and tried some versions. Software acts. It interacts with people, machines, and other systems. Those dynamic consequences are difficult to imagine in advance. The software builder’s most important work is therefore the iterative extraction and refinement of requirements with the client.

If we give an agent one vague objective and inspect the finished product hours later, we have not invented a future workflow. We have compressed waterfall into one prompt: one specification, one implementation, final acceptance.

Speed can make this more dangerous. In the past, a misunderstanding had to pass through scheduling, discussion, and development before it became a large body of code, leaving opportunities for it to surface. Now it can be fully implemented, tested, and documented before the first human feedback arrives.

Real human involvement is not a person sitting at the end of a pipeline pressing an approval button. Human understanding changes with the working software:

• The first version reveals that the important issue is not feature count but the path through the interface.
• Two implementations expose a tradeoff that no one had said aloud.
• Real data reveals a conflict between a performance constraint and a business rule.
• A usable version is rejected because it solves the wrong problem.

A colleague can participate in this negotiation of goals through long-term collaboration. With an agent, the negotiation has to be designed into the loop: intermediate artifacts must appear early, current assumptions must be visible, and rejecting an approach must be cheap.

The human does not provide the agent with a static goal. Human and agent manufacture the goal together through successive real artifacts.

TDD is not a nostalgic discipline; it is a temporary executor’s sense organ

This explains why test-driven development (TDD) feels sharp again in agentic programming.

If TDD is reduced to “write the test before the code,” it easily becomes a rigid ritual. Its deeper role is to turn the next expected behavior into something the environment can reject before production code appears:

1. Red: the current system cannot satisfy this judgment.
2. Green: add only enough change to satisfy it.
3. Refactor: improve the structure while behavior remains protected.

This is not a tiny waterfall. It is tiny growth. Every step keeps a running system and allows the next decision to respond to a real result.

For a human developer, experience, patience, and responsibility may still reveal that something is wrong even when the tests pass. An agent has no natural responsibility for the project and does not feel the loss when over-implementation wastes two weeks of team effort. It needs a feedback source independent of its own verbal judgment. Tests do not prove that an agent is intelligent. They let it avoid using confidence as the test of completion.

superpowers links red-green-refactor, fine-grained tasks, specification review, and verification before completion into a mandatory workflow not because agents cannot write code, but because they can write it too quickly. It can even start a fresh executor for each bounded task, then separately review specification compliance and code quality. The superpowers workflow

A “zero-context plan” therefore has a deeper meaning. It is not a demand for maximal document length. It tests whether an engineering decision can leave its author’s mind and be reliably loaded by another temporary executor.

Tests can, of course, protect only the intent that has been expressed. Brooks had already made the same point about program verification: even a perfect proof that a program meets its specification leaves the hardest problem untouched—obtaining a complete and consistent specification. Much of software work is the debugging of the specification itself.

TDD cannot replace the human. It moves what has already been understood into a form that machines can repeatedly check, preserving human attention for what has not yet been understood.

Agents let agile become fast in the literal sense

Agile software development later accumulated sprints, standups, story points, and an entire organization of ceremonies. Its original principles were simpler: deliver valuable software early and continuously, welcome changing requirements, deliver working software frequently, measure progress through working software, and treat simplicity as the art of maximizing work not done. Principles behind the Agile Manifesto

All of these principles rest on one fact: requirements are not discovered before the project begins. They emerge as working software meets people.

Agents do not make agile obsolete. They push it into a timescale that was previously unaffordable. Prototypes and iterations that once took weeks can shrink to hours. Two approaches that were once debated because building both cost too much can now both be tried. An implementation that once felt too expensive to reject can be discarded as soon as its direction proves wrong.

The best division of labor between humans and agents then becomes clearer:

• Agents generate candidates, execute changes, collect evidence, and lower the cost of each attempt.
• Humans carry intent, taste, responsibility, and conceptual integrity across attempts, deciding what deserves to enter the next one.
• Tests, specifications, and runtime environments move formalizable judgments out of human heads so that results from different agents can be compared.
• Working software keeps bringing back facts that neither side anticipated.

This is not “the human gives the goal; the agent completes it.” Nor is it “the agent finishes; the human reviews.” It is closer to selection pressure: agents make variations abundant, the environment eliminates obvious failures, and humans decide which variations belong to the thing they actually want to build.

The silver bullet hits the cost of trying, not complexity itself

We can now return to the opening question.

Is the agent a silver bullet?

If a silver bullet means one technology that independently eliminates software’s complexity, changeability, and invisibility, Brooks remains right. Agents can write more code, but cannot stop the rules of the real world from conflicting. They can generate specifications, but cannot decide for everyone what is worth building. They can run tests, but cannot guarantee that the tests express the real intent.

Yet agents do change something Brooks could not assume: the marginal cost of a running version is falling rapidly.

Brooks believed that the most promising attacks on software’s essential difficulty were requirements refinement, rapid prototyping, and incremental growth, because people discover what they need only when they encounter real software. Agents do not eliminate that repetition. They make the repetition cheap, parallel, and disposable.

If something this time comes close to a silver bullet, it is therefore not a super-agent that receives one objective and completes an entire project alone.

It is a radically accelerated loop:

A human offers a provisional intent. An agent rapidly makes it real. Tests and the environment expose the gap. The human changes the intent in response to reality.

The essential difference between an agent and a colleague finally lands here. An agent is not a faster and cheaper person. It is engineering labor that can be regenerated for each attempt and allowed to die immediately after failure. It does not naturally carry organizational continuity, which is why continuity must be written into code, specifications, tests, and feedback. It also does not need to be preserved as a person does, which lets us generate many approaches and mercilessly retain only a few.

When implementation is no longer scarce, the center of software engineering moves.

Humans once advanced a project by personally performing much of its implementation. Their more important job may increasingly be to preserve one clear judgment: among all the things that have become possible to implement, which ones are worth keeping?