Every few decades, someone declares software engineering dead or about to be automated away. It hasn't happened yet — and why it hasn't is worth understanding if you're a developer trying to figure out where to put your energy right now.
Grady Booch has been in this field since the 1970s. He co-created the Unified Modeling Language, pioneered object-oriented design methodology, and has watched several waves of technology that were supposed to replace developers come and go. His read on the current moment differs from the loudest voices in the conversation — and is more grounded in history.
Three golden ages
Booch describes the history of software engineering as three distinct golden ages, each defined by a rising level of abstraction.
The first, from the 1940s through the 1970s, was the age of algorithms. Developers worked close to the hardware, optimizing for expensive machine time. The primary unit of abstraction was the algorithm itself. This era produced the foundational thinking in computer science — sorting, searching, data structures, and computational complexity.
The second, from the 1970s through roughly the 2000s, was the age of object-oriented abstraction. The rise of minicomputers and distributed systems created new complexity that procedural code alone couldn't manage. Object-oriented design, information hiding, and abstract data types emerged in response. Languages like C++, Smalltalk, and Java gave developers a new vocabulary for managing that complexity.
The third golden age — the one we're in now — started around 2000, before the recent AI boom. It's defined by systems: the rise of platforms, APIs, libraries, and packages that abstract entire subsystems. Cloud infrastructure, microservices, open source ecosystems — these developments all reflect the same pattern: raising the level at which developers operate so they can build more complex things with less foundational work.
AI, in Booch's framing, is a continuation of that trend, not the start of a new one.
Not the end. Another level up.
When compilers emerged in the 1950s, assembly programmers worried their careers were over. When high-level languages came along, the same fear rippled through the industry. And when object-oriented programming went mainstream, structured programmers said it was too abstract, too removed from how machines actually work.
Each time, the developers who understood that abstraction was the mechanism — not the threat — came out ahead. They used the new tools to tackle harder problems rather than mourning the loss of lower-level work.
Booch draws the same line for AI coding tools. They're doing for code generation what compilers did for assembly: abstracting away implementation details so developers can focus on higher-level problems. "Fear not, developers," he says. "Your tools are changing, but your problems are not."
The problems of software engineering — managing complexity, balancing competing requirements, making design decisions that don't become expensive liabilities later — are not problems that AI solves. They require judgment about systems, not just code.
What actually changes
Booch is clear-eyed about what AI tools are and aren't good at. Current models have been trained primarily on patterns the industry has already solved — web applications, CRUD systems, standard API integrations. In these well-documented domains, AI coding assistance is genuinely useful and improving quickly.
The frontier of computing is much larger. Novel systems, safety-critical applications, deeply embedded software, genuinely new problem domains — these require the kind of design thinking that comes from understanding systems at multiple levels of abstraction simultaneously. AI tools are not close to that.
What this means practically: the value of deep foundations is increasing, not decreasing. As AI handles more of the routine implementation work, the developers who understand architecture, system design, and domain complexity become more differentiated. The floor for what developers can build without deep expertise is rising. The ceiling — what great engineers can accomplish — also rises.
What to prioritize now
If the third golden age is a systems age, then systems thinking is the core skill. That means being able to reason about how components interact, how failures propagate, and how complexity compounds over time. It means understanding the tradeoffs in design decisions before they become expensive. It means caring about the architecture of what you're building, not just whether it works today.
AI agents can generate code. They can run tests. They can surface patterns. What they can't do is hold a theory of your system in their heads — an understanding of what the software is supposed to do, how the current design reflects those intentions, and how to change it sensibly over time.
That understanding lives in engineers. Protecting and developing it is the job that doesn't go away.
An invitation, not a warning
Booch's closing note on all of this isn't cautionary. He describes the current moment as an invitation. The imagination that was always the limiting factor — the ability to conceive of systems more complex than any team could build in a reasonable time — is now less constrained by implementation. Developers who engage with that seriously will build things that weren't previously possible.
The third golden age is not the end of software engineering. It's another step in the direction software engineering has always moved: toward handling more complexity with better tools, while the hard problems stay hard and the craft stays worthwhile.
