Bricolage | Essential Until It Wasn'tbricolage<br>blog, about

Essential Until It Wasn't<br>Posted July 03, 2026<br>What we call programming today is not the same activity it was two years ago. The daily work, the skills that matter, the texture of the craft — all changed. And yet people talk about it as if “programming” names a fixed thing that AI tools either threaten or enhance. But “programming” has never rested on solid ground.

Solid Ground

Consider how long each era of “solid ground” lasted:

Era<br>Main Skills Required<br>Years<br>Duration (years)

Machine code<br>Memorizing opcodes, manual register allocation<br>1945–1960<br>~15

Assembly<br>Hardware-specific idioms, memory addressing by hand<br>1960–1975<br>~15

C and early high-level languages<br>Pointers, manual memory management<br>1975–2000<br>~25

Pre-garbage collection<br>Tracking allocations, avoiding leaks<br>1975–1995<br>~20

Pre-StackOverflow / modern IDEs<br>Memorizing APIs, keeping references at your desk<br>1950s–2008<br>~60

Pre-AI<br>Implementation-level reasoning, writing code by hand<br>1945–2024<br>~80

Each row felt permanent to the people in it. Assembly programmers who memorized instruction sets thought that knowledge was the craft. C programmers who tracked memory allocations believed pointer arithmetic was what separated real programmers from pretenders.

Today’s ground felt just as solid: writing code character-by-character, debugging manually, tracing state by hand. It was easy to believe this was the irreducible core. Every previous generation believed the same thing about their ground.

Brooks and the Boundary

In 1986, Fred Brooks published “No Silver Bullet.”

His central distinction: essential complexity versus accidental complexity . Essential complexity is inherent to the problem you’re solving — the irreducible difficulty of specifying what a system should do, how components should interact, what happens when things fail. Accidental complexity is everything else — the incidental friction of the tools, languages, and environments you happen to be using.

Brooks’ argument was that no tool would ever deliver order-of-magnitude improvements because the essential complexity dominates. You can shave off accidental complexity — better languages, better debuggers, better IDEs — but you can’t touch the hard part. The hard part is thinking.

The Moving Boundary

Brooks’ distinction is useful — but the boundary moves. Every time capabilities change, the line shifts.

What counts as “essential” in one era becomes “accidental” in the next — not because the work disappears, but because tools absorb it. The work gets done; humans just stop doing it.

Here’s where the boundary has been:

┌──────────────────────────────────────────┐<br>│ System Design / Architecture │ ← essential<br>├──────────────────────────────────────────┤<br>│ Specification / Intent │ ← essential<br>├──────────────────────────────────────────┤<br>│ Algorithm Design │ ← essential<br>├──────────────────────────────────────────┤<br>│ Implementation Logic │ ← LINE IS HERE<br>├──────────────────────────────────────────┤<br>│ API Knowledge / Library Familiarity │ ← accidental<br>├──────────────────────────────────────────┤<br>│ Memory Management │ ← accidental<br>├──────────────────────────────────────────┤<br>│ Register Allocation / Memory Addressing │ ← accidental<br>├──────────────────────────────────────────┤<br>│ Opcodes / Machine Instructions │ ← accidental<br>└──────────────────────────────────────────┘

Look at the bottom of that stack. Nobody mourns the loss of opcode memorization now. Nobody argues anymore that “real programmers” allocate registers by hand. Those fights happened — older engineers did complain that high-level languages were making people soft — but the fights are over. The boundary moved, and everyone adjusted.

Memory management was more recent. When Java introduced garbage collection at scale in the mid-90s, many C programmers insisted that automatic memory management would breed a generation of developers who didn’t understand what was happening underneath. They had a point — and it didn’t matter. The boundary moved. The next generation of programmers built real systems without ever manually tracking allocations.

The same pattern repeated with API memorization. Before StackOverflow and intelligent IDEs, a programmer’s value partially resided in knowing obscure API details from memory. Then between searchable answers and autocomplete that surfaces signatures on demand, that knowledge became instantly accessible. The boundary moved again. What was once essential became accidental.

Now AI is doing the same thing by moving the boundary up past implementation-level reasoning. Writing code character-by-character, debugging by manually tracing state, holding syntax in your head — all the things that felt like the craft’s irreducible core — are becoming accidental complexity. The work still happens. Humans just stop doing it.

The Sound the Fault Makes

Every time this boundary moves, some of us say the same thing: “They’re not real programmers.”

Assembly...