The third golden age of software engineering - thanks to AI, with Grady Booch (AI column)
Interesting. interview Gradi Booch, creator of UML and Chief Scientist for Software Engineering at IBM, on The Pragmatic Engineer podcast. Gradi and Gergely Orosz, the author of the podcast, discuss how engineering's craft changes when the level of abstraction rises again (As was the case with assembler and then high-level programming languages.).
Interestingly, in this interview Gradi Butch discusses in absentia with Dario Amodei, which last March publicly spokethat we might be in 6–12 It's about a month from a situation where models will end-to-end what software engineers do, and engineers will go into "model writes - I edit." Butch reacts to this very harshly and essentially: it is a view of programming as a set of lines of code, not an engineering discipline:)
In general, the main theses of the interview are such
1We are already in the "third golden age" - and it is about systems, not about code Butch lays out the story 3 Golden Ages:
- 1940-1970 Algorithms and Business Automation
- 1970-2000 - object abstractions
- 2000Right now, systems where we assemble products from libraries, platforms, APIs, clouds, and now there's an AI layer on top of that. And according to Gradi, AI is not the end of the profession, but another leap in abstraction.
2Existential panic - a recurring cycle When compilers and high-level languages came along, there was no need for programmers. But the industry didn't die - it reassembled and went up the stack. One of Booch's central thoughts is that your tools change, but your problems don't.
3AI is strong where patterns are already established Current tools like Cursor/Claude are good where tasks are repetitive: typical CRUDs, standard integrations, familiar web patterns. Butch bluntly notes that they are trained on problems we've seen over and over again. But the boundaries of the interesting are systems, context, compromise, responsibility.
4Software engineering is not a set of code, but a balance of power and solutions Engineering is a balance of technical limitations, human factors and ethics, and code is just one tool. And from this we have a simple conclusion – AI can accelerate the production of artifacts, but not replace decision-making under restrictions.
5Automation will hit the delivery pipeline (And that's okay.) Butch separately notes that the pipeline supply (Everything around assembly/delivery/routine) It is a low-hanging fruit for automation. And people in these roles may need more training.
6The higher the abstraction, the more important the foundation Paradoxically, when code becomes easier to write, a deeper model of the world is more appreciated. Butch recommends strengthening the foundation and thinking systems
It seems that engineers now need the following skills: System design and distributed systemsThis topic is well described on system-design.space. Ability to work with limitations: cost, timing, risks, legacies, security, regulation, team - this topic is well described there + soon there will be a new site for technical leaders in the same style that I did system-design.space **Skills of “review and governance”**Check, test, set limits, catch non-obvious bugs that AI easily generates along with working code - Domain knowledge: a business context that is now valued even more:)
#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems #History