I’ve been a fan of Dr. Frederick Brooks’ essays from The Mythical Man-Month: Essays on Software Engineering for a long time. I’ve enjoyed many of them over the years, but one essay in particular – No Silver Bullet: Essence and Accidents of Software Engineering – has resonated with me more recently.

Originally published in 1986, the essay feels especially relevant today, with all the discussions around AI and software development productivity.

Brooks made a famous claim in that essay:

“There is no single development… that promises even one order-of-magnitude improvement in productivity within a decade.”

In other words, he argued that no single technology or methodology would give us a 10× improvement in software productivity within a decade.

But with the recent rise of AI-assisted coding tools, this claim suddenly feels worth revisiting. Many people believe tools like GitHub Copilot or Claude Code could significantly change how software is developed.

So I decided to bring this question to AI itself and see what it thinks.

I’m not saying either Brooks or ChatGPT is definitively right here, but I found the discussion surprisingly insightful. Below is a copy of our conversation.

P.S. This is probably my longest and easiest blog post so far.

Me: Can you read Fredrick Brooks paper “No Siver Bullet” and the later refired version, and discuss his argument about software productivity improved by technology. Please relate to how AI improves software  development productivity

Fred Brooks’ “No Silver Bullet — Essence and Accidents of Software Engineering” (1986) and his later reflection “No Silver Bullet Refired” (1995) are foundational arguments about why software productivity does not improve exponentially with new technology, unlike hardware. Understanding his reasoning is extremely useful when thinking about AI-assisted programming today.

I’ll explain in four parts:

  1. Brooks’ core argument
  2. The distinction between essential vs accidental complexity
  3. What Brooks clarified in Refired
  4. How AI fits into Brooks’ framework

1. Brooks’ Core Thesis: No 10× Productivity Breakthrough

Brooks’ most famous claim is:

“There is no single development… that promises even one order-of-magnitude improvement in productivity within a decade.” (Wikipedia)

In other words:

  • No single technology
  • No methodology
  • No management technique

will deliver a 10× improvement in software productivity in the foreseeable future.

Brooks contrasted software with hardware:

  • Hardware benefited from Moore’s Law
  • Software productivity does not scale the same way (Wikipedia)

This argument was controversial because every decade someone claims the next silver bullet:

Examples historically:

  • high-level languages
  • object-oriented programming
  • CASE tools
  • reusable components
  • visual programming
  • AI / automatic programming

Brooks’ position: all of them help — but none change the fundamental difficulty of software.


2. Essential vs Accidental Complexity (The Core Idea)

Brooks divides software difficulty into two types.

2.1 Accidental Complexity

These are difficulties caused by tools or implementation constraints.

Examples:

  • assembly programming
  • memory management
  • low-level machine details
  • syntax
  • compilation
  • boilerplate

Historically many breakthroughs reduced this:

Examples Brooks cited:

  • high-level languages
  • time-sharing
  • interactive IDEs (SuperSummary)

These improvements remove friction.

But they don’t change the actual problem being solved.


2.2 Essential Complexity

Essential complexity is the intrinsic difficulty of the problem itself.

Brooks identifies several inherent properties of software:

1️⃣ Complexity

Software systems have huge numbers of states and interactions.

2️⃣ Conformity

Software must match messy real-world systems.

Example:

  • business rules
  • regulations
  • legacy systems

3️⃣ Changeability

Software changes constantly because it is easy to modify.

4️⃣ Invisibility

Software has no natural physical representation, making reasoning difficult.

These are inherent to software itself, not the tools. (jtabb.dev)


Key Implication

Even if accidental complexity → 0, the essential complexity remains.

Therefore productivity cannot increase dramatically.


3. Brooks’ 1995 “Refired” Clarification

In “No Silver Bullet Refired”, Brooks responded to critics.

Key clarifications:

1️⃣ He was not pessimistic

He believed productivity would improve gradually, just not via one miracle technology.

2️⃣ Accidental complexity had already shrunk

He estimated:

accidental complexity was about half or less of total effort (blog.ploeh.dk)

Meaning:

Even if we removed all accidental work, improvement would be <2×, not 10×.

3️⃣ Human design remains central

Brooks emphasized:

  • great designers
  • conceptual integrity
  • architecture

Technology helps, but design thinking dominates productivity.


4. How AI Fits into Brooks’ Framework

Now we can analyze AI-assisted development.

AI tools include:

  • GitHub Copilot
  • ChatGPT
  • code generation
  • automated testing
  • AI debugging
  • documentation generation

The key question:

Does AI attack essential complexity or accidental complexity?


5. AI Mainly Reduces Accidental Complexity

AI significantly reduces implementation overhead.

Examples:

Code generation

AI can produce:

  • boilerplate
  • tests
  • wrappers
  • API clients

Faster debugging

AI can help with:

  • syntax errors
  • API usage
  • configuration issues

Documentation

AI can generate:

  • comments
  • docs
  • examples

Learning libraries

AI acts like a knowledge retrieval system.

These all reduce accidental complexity.


Example

Old workflow:

Design algorithm
Write boilerplate
Check syntax
Look up library docs
Write tests
Debug trivial errors

AI workflow:

Design algorithm
AI writes boilerplate
AI writes tests
AI suggests fixes

The thinking step remains.


6. AI Only Partially Attacks Essential Complexity

AI can help with some conceptual tasks:

Examples:

  • generating architecture sketches
  • proposing algorithms
  • explaining systems
  • brainstorming

But it still struggles with:

  • ambiguous requirements
  • real-world domain modeling
  • system tradeoffs
  • product design decisions

Those are the essential parts.


7. Empirical Evidence So Far

Current research suggests:

  • ~5–20% productivity improvements from AI coding tools (LinkedIn)

That aligns almost perfectly with Brooks’ thesis:

AI helps a lot, but not an order-of-magnitude change.


8. Where AI Might Challenge Brooks

There are two areas where AI could partially break his model.

1️⃣ AI as “Digital Labor”

Some economists argue AI functions as an additional factor of production, like labor or capital. (arXiv)

This could scale development teams dramatically.

Example:

1 engineer + AI agents ≈ small team.


2️⃣ AI-assisted design

If AI becomes capable of:

  • system architecture
  • requirement synthesis
  • reasoning over complex systems

Then AI would begin attacking essential complexity.

This is still an open question.


9. A Modern Interpretation of Brooks

A useful modern interpretation:

Layer Example tools Impact
Hardware Moore’s law 10× improvements
Programming tools languages, frameworks 2–3×
AI assistants Copilot, LLMs ~1.2–2×
Essential design human reasoning still dominant

Brooks’ real message:

Software progress is many small improvements, not one revolution.


10. Why Brooks Still Matters Today

Almost 40 years later, his framework still explains:

  • why new languages don’t solve productivity
  • why frameworks proliferate
  • why AI helps but doesn’t replace developers
  • why system design remains the bottleneck

The biggest gains still come from:

  • good architecture
  • clear requirements
  • strong engineering teams

In short

Brooks’ argument still largely holds:

  • AI reduces accidental complexity significantly
  • but essential complexity remains the main difficulty

So AI is not a silver bullet — but it moves the boundary of accidental complexity, which still produces meaningful productivity gains.


If you’d like, I can also show you something interesting:

Why AI might actually be the closest thing to a silver bullet since high-level languages — but still consistent with Brooks.

It becomes very interesting when viewed through cognitive load theory and systems design.

Me: Yes please

Great—this becomes really interesting when we reinterpret Brooks through modern cognitive science and AI tooling. AI may not violate Brooks’ thesis, but it changes where human cognitive effort is spent, which can still produce significant productivity gains.

I’ll explain in five parts:

  1. Brooks’ implicit model of developer productivity
  2. Cognitive load in software engineering
  3. How AI changes the cognitive stack
  4. Why AI might be the closest thing to a silver bullet so far
  5. What this means for engineers like you

1. Brooks’ Implicit Model of Software Productivity

In No Silver Bullet, Frederick P. Brooks Jr. effectively models software development as:

Total Effort =
    Essential Complexity
  + Accidental Complexity

Where:

Essential complexity

  • understanding the problem
  • designing algorithms
  • defining system behavior
  • managing interactions

Accidental complexity

  • programming language syntax
  • tooling friction
  • writing boilerplate
  • documentation lookup

Brooks argued that most progress had already attacked accidental complexity.

Examples he cited:

  • high-level languages
  • time-sharing systems
  • structured programming
  • interactive environments

So further gains would be incremental.


2. Cognitive Load in Software Engineering

Modern research reframes this using cognitive load theory.

Developers constantly juggle:

Working memory

Understanding current code context.

Long-term memory retrieval

Remembering APIs, patterns, algorithms.

Attention switching

Moving between tasks:

  • writing code
  • debugging
  • reading docs
  • compiling
  • testing

Much of the real productivity loss comes from:

  • context switching
  • information lookup
  • interruptions

Not just coding itself.


3. The Modern Software Cognitive Stack

Before AI, the developer workflow looked roughly like this:

Problem
  ↓
Design
  ↓
Search documentation
  ↓
Translate to code
  ↓
Compile / test
  ↓
Debug
  ↓
Refactor

The biggest cognitive costs were:

  • searching information
  • remembering syntax
  • switching contexts

4. How AI Changes the Cognitive Stack

AI collapses multiple layers of cognitive work.

Old workflow:

Problem
  ↓
Google
  ↓
StackOverflow
  ↓
Docs
  ↓
Translate idea → code

AI workflow:

Problem
  ↓
Ask AI
  ↓
Receive solution + explanation

AI acts as:

  • documentation
  • search engine
  • code generator
  • reviewer
  • tutor

all simultaneously.

This drastically reduces context switching.


5. Why This Is More Powerful Than Previous Tools

Most previous productivity tools helped with execution.

Examples:

Tool Improvement
Compiler faster build
IDE easier editing
Libraries reusable components
Frameworks structure

AI improves thinking support.

It assists with:

  • exploring ideas
  • generating approaches
  • debugging reasoning
  • explaining unfamiliar code

That is fundamentally different.


6. AI as “Cognitive Amplification”

Think of AI not as automation, but as cognitive amplification.

Similar to how spreadsheets amplified financial analysis.

AI amplifies:

  • knowledge retrieval
  • reasoning scaffolding
  • pattern recall
  • code translation

So the developer becomes more like:

architect + reviewer

instead of

manual implementer

7. Why Brooks Might Still Be Right

Even with AI:

Developers must still:

  • define requirements
  • model real systems
  • design architecture
  • resolve ambiguity
  • manage tradeoffs

These are exactly the essential complexities Brooks described.

AI helps, but cannot remove them.


8. A Useful Mental Model

Modern productivity layers:

Hardware speed     → 10x improvement
Programming languages → 3–5x
Frameworks/libraries → 2–3x
AI assistants       → 1.5–3x

Multiply these over decades and we see huge improvement — just not from a single breakthrough.

Which is exactly Brooks’ claim.


9. The Most Important Change AI Creates

AI may not eliminate essential complexity, but it moves the boundary.

Developers can now:

  • write more code
  • explore more ideas
  • prototype faster
  • test more approaches

So the bottleneck shifts from:

writing code

to

designing good systems

10. Why This Matters for Your Type of Work

Given your background (numerical algorithms, scientific software):

AI is especially strong at reducing accidental complexity:

Examples relevant to you:

  • unit test generation
  • refactoring legacy C++/Fortran
  • translating algorithms between languages
  • writing glue code
  • generating experiment scripts
  • documentation

But AI still struggles with:

  • numerical stability reasoning
  • convergence analysis
  • algorithm design
  • scientific correctness

Those remain essential complexity.

So your expertise stays the core value.


In short

AI doesn’t contradict Brooks.

Instead:

  • Brooks explained why software is hard.
  • AI removes much of the friction around it.
  • But the hardest part — understanding systems — remains.

If you’d like, I can also show you something fascinating:

Why AI might create a “two-tier engineer economy” — something Brooks never predicted, but we’re already starting to see.

It has big implications for senior engineers and technical experts.

Last modified: March 9, 2026

Author

Comments

Write a Reply or Comment

Your email address will not be published.