The third golden age of software engineering – thanks to AI, with Grady Booch

The Pragmatic Engineer (Gergely Orosz, host; Grady Booch, guest) · article · 2026-02-04 Reader 🖥️

Abstraction Shifts in Programming (History)Agentic Engineering AI Labor Disruption Code Was Never the Bottleneck Mental Models & Understanding

Software engineering is entering a historically recurring pattern — a rise in the dominant level of abstraction — rather than being automated out of existence, because 'software engineering' has always meant balancing human, economic, legal, and ethical forces (not just writing code), and today's AI tools only automate the coding layer, which is itself bounded by the already-seen patterns they were trained on.

theoretical · mixed — A historical-narrative argument (three 'golden ages' of software engineering, told through Cold War, personal-computer, and AI case studies) deployed to support a theoretical claim — that AI coding tools are a continuation of a century-old abstraction-rising pattern, not a rupture — with practical corollaries (what to study, what to re-skill toward) drawn out at the end.

Structure

Part	Role
Opening definition: what 'software engineering' actually means — balancing static and dynamic forces (physics, algorithms, human organization, economics, law, ethics) to build 'reasonably optimal,' enduring solutions.	foundational definition
First golden age (c. late 1940s–late 1970s): algorithmic abstraction, driven by defense/Cold War economics (Whirlwind, SAGE), ending in the 'software crisis' named at the NATO conference.	historical case 1
Second golden age (c. late 1970s–2000): object-oriented abstraction, driven by personal-computer hobbyism and the rise of platforms/SaaS, ending in the dot-com crash and the (successfully averted) Y2K crisis.	historical case 2
Third golden age (c. 2000–present): abstraction rising from components to whole libraries, platforms and systems; today's AI coding assistants are framed as an acceleration of this existing trend, not the start of a new one.	core argument
Direct rebuttal of Dario Amodei's claim that 'software engineering will be automatable in 12 months.'	counter-argument / conclusion
Guidance on what becomes obsolete (custom delivery-pipeline/infrastructure work) and what to study instead (systems theory, Minsky, Brooks) to thrive in the transition.	practical application
Closing reframing: the abstraction shift removes friction and cost, freeing attention for imagination — an opportunity, not only a loss.	conclusion / call to action

Key terms

Software engineering
The discipline of balancing static and dynamic forces — the laws of physics, algorithmic constraints, human/organizational capacity, economics, law, and ethics — to build 'reasonably optimal' (never perfect), enduring solutions. Coding is one mechanism within this discipline, not the whole of it.
Golden age (of software engineering)
A historical era defined by a dominant level of abstraction and a vibrant expansion of what becomes buildable within it — bounded at its edges by a 'crisis' that exposes the era's limits (the software crisis; the dot-com crash/Y2K near-miss).
Level of abstraction
The conceptual layer at which a practitioner reasons about and manipulates a system — progressing historically from machine code, to algorithms/functions, to objects/classes, to libraries/platforms, to (now) natural-language instruction.

Propositions

explicitSoftware engineering is the discipline of balancing static and dynamic forces — the laws of physics, algorithmic constraints, human/organizational capacity, economics, law, and ethics — to build 'reasonably optimal,' never perfect, solutions that must endure beyond any one individual; this is what makes it engineering, as distinct from coding.conf: high
explicitSoftware's history divides into at least three 'golden ages,' each defined by its dominant level of abstraction: algorithmic abstraction (c. late 1940s–late 1970s), object-oriented abstraction (c. late 1970s–2000), and a third age under way since around the turn of the millennium, defined by abstraction rising from individual components to whole libraries, platforms, and systems.conf: high
explicitToday's AI coding assistants (Cursor, ChatGPT, Claude) are a continuation of the third golden age's abstraction-rising trend, not a break from it or the start of a new one — they exist to accelerate the use of the libraries and platforms that the third age already produced.conf: high
explicitEvery prior rise in abstraction level (machine code to assembly, assembly to high-level languages, functions to objects) provoked the same existential fear among practitioners that their skills would become worthless — and each time the fear was wrong in aggregate: the field expanded and displaced skills were replaced by new, higher-level ones.conf: high
explicitAI coding tools represent another shift in levels of abstraction — this time from formal programming languages toward natural language itself — because English, given a well-structured enough domain and a practitioner who supplies the missing fundamentals, can function as 'a good enough programming language.'conf: high
explicitCurrent AI models are effective mainly on patterns that have already been built over and over again — especially web-centric CRUD systems — because that is what they were trained on; the frontier of computing (embodied systems, genuinely novel domains) remains far larger than what these tools have mastered.conf: high
refinesWhen AI Writes Almost All Code, What Happens To Software Engineering? · p17 — Booch's 'trained on already-seen patterns' claim adds a mechanism for why large, complex organizational codebases (not just CRUD) remain a frontier AI hasn't absorbed.
explicitDario Amodei's claim that 'software engineering will be automatable in 12 months' conflates coding (a subset) with software engineering (the whole discipline of balancing human, economic, legal and ethical forces); none of the automation evidence he or his peers cite addresses the decision problems that actually define the discipline.conf: high
explicitAs the shift moves from building individual programs/apps to building and operating whole systems, the professionals most in demand will be those who can manage complexity at scale and balance human as well as technical forces — not those whose value was narrow coding skill.conf: high
extendsWhen AI Writes Almost All Code, What Happens To Software Engineering? · p9 — Booch's historical abstraction-level framework provides the deeper theoretical grounding for why 'solid software engineer over coder' becomes more valuable, not less.
explicitThe software delivery pipeline (deployment infrastructure, custom CI/CD plumbing) is 'low hanging fruit' for automation, and real job losses will fall on people whose skill was specifically building that messy, custom infrastructure — they will need to re-skill toward systems-level work.conf: high
supportsLeading your engineers towards an AI-assisted future · p11 — Both argue AI automates tedious/low-judgment work (delivery pipelines; rote tasks) rather than eliminating demand for engineers overall.
explicitAs AI absorbs more coding friction, deep foundational knowledge — systems theory and complexity science (Simon & Newell, the Santa Fe Institute), and historical multi-agent architectures (Minsky's Society of Mind, blackboard/global-workspace architectures, Brooks's subsumption architecture) — becomes more valuable, not less, because fundamentals are what let a practitioner judge, steer, and architect what AI produces.conf: high
supportsThe "funhouse mirror": How AI reflects the hidden truths of your software pipeline · p6 — Both argue that fundamentals (here: systems theory and foundations; there: architecture and modularity) matter more, not less, as AI absorbs coding friction.
explicitWhether fundamentals matter for a given piece of AI-assisted work depends on whether the software is meant to endure or to be thrown away: disposable, single-user automation built by non-engineers (hobbyists, an accountant scripting her own tools) is a valid and valuable use of AI, but it is categorically different from engineering durable systems, and doesn't carry the same fundamentals requirement.conf: high
explicitAI-enabled non-professionals writing their own disposable software (hobbyists, an accountant building her own automation) expands who writes software without threatening the professional discipline, paralleling the hobbyist wave that accompanied the rise of personal computers in the late 1970s/80s.conf: high
explicitMulti-agent AI systems are not a wholly new engineering problem; they should be designed using existing systems-theory architectures developed for other multi-agent problems — Minsky's Society of Mind, blackboard/global-workspace architectures, Brooks's subsumption architecture.conf: medium

Arguments

Software engineering will not be fully automated by AI in the near term, contra Dario Amodei's claim that it will be 'automatable in 12 months.'

Explicit premises:

Coding is a subset of software engineering, not the whole of it.
Software engineering also requires balancing human, economic, legal, and ethical forces that current AI does not address.
Today's AI models are trained on, and excel only within, previously-seen patterns (especially web-centric CRUD systems).
The frontier of computing is far larger than that trained distribution.

Implicit premises:

Automation-timeline claims from AI lab leaders are shaped by commercial incentives to impress stakeholders, which should discount their reliability as predictions.
The historical pattern of past abstraction shifts not eliminating the profession is a reliable guide to how this one will play out.

Inferences:

Engineers whose value is defined by systems-level judgment, rather than narrow coding skill, are the most durable professionals in this transition.
Organizations should expect to need to re-skill, not simply eliminate, roles whose work is being absorbed by automation.

Narratives

Margaret Hamilton, working on the Apollo program, coined the term 'software engineer' to distinguish herself from the hardware/structural engineers around her.
→ Grounds the claim that 'engineering' was always meant to signal force-balancing judgment, not just code production (supports p1).
The Cold War defense buildout (Whirlwind, SAGE, the DEW Line) consumed an estimated 20–30% of all US software developers at the time, driven by the Russian bomber threat rather than consumer demand.
→ Illustrates that non-market forces (government, defense, 'commerce and warfare') have repeatedly set the pace of software's abstraction shifts, supporting the periodization in p2.
The Y2K remediation effort was enormous, largely invisible labor that successfully prevented a crisis — which in hindsight looks to many as if it 'wasn't needed.'
→ Supports the observation that 'the best technology is one you simply don't see,' and that successful, careful engineering work is systematically undercounted — relevant to how teams should value unglamorous reliability work in the AI era.
Booch directed Cursor, in plain English, to build minimal examples using the D3.js library he didn't know, then iteratively refined the output to learn and extend it himself.
→ A first-person case of 'moving up a level of abstraction': using AI to close the gap between what he wants and what he knows how to specify (supports p5).

Questions addressed

✅ Will software engineering be automated away in the near term, as Dario Amodei claims?
No — it is a continuation of a century-old pattern of rising abstraction; current tools are trained on and bounded to familiar patterns, and the discipline's defining forces (human, economic, ethical) are untouched by current automation.
✅ What should a software engineer entering now, or displaced from infrastructure/pipeline work, actually do?
Move up a level of abstraction: focus on systems-level thinking and complexity management, and study foundational systems theory (Simon & Newell's The Sciences of the Artificial, Minsky's Society of Mind) rather than narrow coding or pipeline-building skill.
⭕ What marks the end of a 'golden age' and the start of the next one?
Booch identifies crisis events for ages one and two (the 'software crisis'; the dot-com crash and averted Y2K crisis) but never states a terminal condition for the third golden age, or what would distinguish its continuation from the start of a fourth.

Gaps

incompleteBooch never addresses what would mark the end of the third golden age or the start of a fourth, despite his own periodization implying golden ages are finite — leaving open whether the current AI-driven jump (natural language as programming interface) is a continuation of the third age, as he claims, or qualifies as a new, fourth golden age with its own characteristic crisis.
Read next: Look for a framework that defines golden-age boundaries by their crisis type (complexity crisis → software crisis → platform/trust crisis) and test whether AI coding constitutes a new crisis class rather than an extension of the third age's.
illogicalThe claim that 'fundamentals survive every abstraction shift' is argued by induction from two prior cases (assembly→high-level languages, functions→objects), both of which stayed within formal, deterministic languages. Booch doesn't examine whether a shift to informal, ambiguous natural-language instruction plus probabilistic generation differs in kind, not just degree — which is the actual crux of disagreement with people who think 'this time is different.'
Read next: Pair with other corpus pieces that directly engage the 'is AI categorically different from prior automation' counter-argument, and with technical analyses of LLM capability trajectories beyond trained-pattern distributions.
incompleteBooch's re-skilling advice ('move up a level of abstraction, start worrying about systems') is pitched at the individual, not the organization — he never discusses who funds, structures, or sequences re-skilling for displaced infrastructure/delivery-pipeline engineers, or what happens to those who can't make that jump, a gap directly relevant to teams and orgs living through this transition.
Read next: Look for team/org-level AI-adoption frameworks that assign leadership responsibility for re-skilling, not just individual advice (e.g. phased adoption models with explicit organizational mandates).
uninformedBooch dismisses Amodei's prediction partly on the basis that current models are trained only on previously-seen patterns, but doesn't engage with the trajectory argument — that model capability has been expanding beyond narrow CRUD patterns at a measurable rate — which is the actual empirical crux of near-term automation-timeline disagreements, rather than a settled historical analogy.
Read next: Pair with benchmark- or practitioner-report-driven pieces examining the rate of capability expansion across recent model releases, not just a snapshot of current limits.

Closes gaps elsewhere

Fragments: February 13 · g1 — Booch offers concrete guidance for displaced/mid-level developers: move up a level of abstraction toward systems-level thinking, and study specific foundational texts (Simon & Newell, Minsky's Society of Mind) rather than leaving 'what to do' unspecified.
Is AI Doom Going Out of Style? · g1 — Booch directly engages the 'AI is categorically different from prior automation' counter-argument: he argues AI's apparent power is bounded by its training distribution (patterns already seen, e.g. CRUD) and that coding is only one of several forces (economic, ethical, human) that define 'software engineering' — his explicit reason for believing the historical analogy still holds.