---

Two Pressures, One Bottleneck

For most of software engineering’s history, two old ideas have pushed on us from opposite directions.

The first is the software crisis. As computers become more capable, we try to build larger and more ambitious systems. Better hardware expands the frontier of what we attempt, so the demand for complex software keeps outrunning our ability to build it reliably.

The second is Fred Brooks’s No Silver Bullet. Brooks argued that languages, tools, and abstractions can remove the accidental difficulties of writing software. They cannot remove the essential complexity of deciding what a system should mean and how we can know it is correct.

We have raised the level of abstraction many times. Frameworks, cloud platforms, and CI/CD have removed huge amounts of lower-level work. But someone still has to resolve conflicting requirements, decide which constraints matter, design the solution, and define what success looks like.

To me, the two ideas meet at the same bottleneck:

Software Crisis
      ↓
more ambitious and complex problems
      ↓
ESSENTIAL COMPLEXITY
      ↑
No Silver Bullet
      ↑
removal of accidental complexity

Both pressures leave essential complexity, and the human effort needed to handle it, in the middle.

For decades, that looked like a stable equilibrium. Maybe LLMs are starting to move it.

Compute Reaches Essential Complexity

AlexNet moved an abstraction boundary in 2012. Much of computer vision had relied on people designing feature-extraction pipelines by hand. Deep convolutional networks learned those representations instead.

That was a major change, but people still defined the problem. For an ImageNet classifier, humans decided what counted as an image, which classes mattered, what the output meant, and which objective to optimize. The model learned how to solve a stated problem, not which problem should be solved.

This is where LLMs feel different. Imagine giving a coding agent a repository and three constraints:

• p99 latency must remain below 100 ms
• committed data must survive a regional failure
• infrastructure cost must remain below a fixed budget

Then ask it for a /plan. A (capable) agent can inspect the architecture, find tensions among the constraints, infer invariants, compare designs, point out missing decisions, and propose acceptance criteria. Its conclusions still need review. But before it writes any code, the important work has already begun: the model has started to shape what the solution should be.

This is where No Silver Bullet becomes uncomfortable. Brooks’s view still relevant. If a financial system contains twenty interacting regulatory constraints, an LLM does not make them disappear.

But I am no longer convinced that essential complexity must mean irreducible human work. An LLM can analyze constraints, propose ways to break a problem apart, and generate tests meant to challenge its own interpretation. Parts of requirements analysis, construction, and verification are becoming computational work.

Simply put, beyond instructing what to code, we are starting to give only “constraints”, e.g., in /plan. That’s beyond giving a problem to solve, let alone what to code.

It is computation being applied to the process of deciding what the solution should be.

A more useful distinction for the LLM era may therefore be:

essential complexity of the problem

            ≠

human effort required to manipulate
that essential complexity

The former may be irreducible. The latter apparently is not. Yet there’s a subtle line.

This does not make humans stop matter. A decision may still depend on leadership, values, or evidence that is not in the repository. What has changed is that a model can help us reach those boundaries and show us which decisions still require a person.

So,

Are LLMs the kind of silver bullet Brooks argued against? It is too early to say. The uncertainty is there; we don’t know if there’s real productivity gain yet. I am optimistic though.

LLMs clearly remove some accidental complexity. More importantly, they appear to make parts of the work around essential complexity computational/mechanical. They do not eliminate the complexity itself.

If I’m right, the deepest change in software engineering may be that the boundary between stating a problem and computing a solution moves so close that we stop treating them as separate activities.