Software Architecture, Human Judgment, and What AI Still Cannot Do

Software Architecture, Human Judgment, and AI's Limits with Grady Booch

TLDR: Kent C. Dodds and Grady Booch dig into what it actually means to be a software engineer when AI agents can produce working code on demand. The conversation centers on a question that I find genuinely important: is implementation the hard part, or was it never the hard part to begin with? Booch argues that human judgment — the kind that shapes durable, defensible systems — is not being automated away anytime soon.

Summary:

Grady Booch has been thinking about software architecture longer than most working engineers have been alive. He co-created UML, spent decades at IBM Research, and has watched more than a few technology revolutions come through. So when he sits down with Kent Dodds to talk about AI and software engineering, he is not speaking from anxiety or hype. He is speaking from pattern recognition.

The core of their conversation is something that gets glossed over in a lot of AI discourse. Writing code is one thing. Deciding what to build, why to build it, how it should behave under failure, what it owes to the humans who depend on it — that is a different activity entirely. Booch makes the point that implementation has always been the smallest part of the job for engineers who actually understand the work. AI making implementation faster does not change the nature of the hard problem. It just removes one of the easier excuses for not solving it.

What I find compelling here is the implicit critique of how teams measure productivity. If you are celebrating faster code generation without asking whether the right thing is being built, you have mistaken motion for progress. Booch's framing suggests that the engineers who will matter most in an AI-saturated environment are not the ones who prompt most cleverly. They are the ones who can reason about systems over time, who can articulate tradeoffs, who know when to say no.

There is also a thread in the conversation about durability. A system that works today and falls apart when requirements shift is not a good system — it is a deferred liability. Booch has always been interested in what makes software stand up over years and decades, and AI-generated code has not yet demonstrated that it produces structures with that kind of integrity. The scaffolding can look right while the foundations are soft.

Kent's framing throughout is characteristically grounded. He is building a course called Epic Product Engineer, and the lens he brings is exactly this: implementation skill matters, but it is downstream of product thinking, user empathy, and architectural judgment. Booch fits neatly into that argument. If anything, he sharpens it.

Key takeaways:

• Implementation is not the hardest part of software engineering and never was
• AI accelerating code generation does not resolve the question of what to build or whether the architecture will hold
• Human judgment about tradeoffs, failure modes, and system durability remains the differentiating skill
• Engineers who can reason architecturally are more valuable when AI handles the routine code, not less
• Durable systems require intent and defensible decisions, not just working outputs

Why do I care: This conversation cuts against a narrative I see constantly — that senior engineers should be worried about being replaced because AI writes code faster. Booch and Dodds are pointing at something more honest: the work that was always hard is still hard, and the work that was easy is now easier. If your value was in typing, that is a problem. If your value is in judgment, context, and knowing what not to build, this moment is clarifying rather than threatening. I would rather have this conversation at my team meeting than another demo of a tool that generates boilerplate.

Software architecture, human judgment, and AI's limits with Grady Booch