Grokking Software Architecture • Matt Erman & Luca Mezzalira • GOTO 2026
Matt Erman, author of Grokking Software Architecture, joins Luca Mezzalira to discuss why engineering fundamentals matter more in the AI era, how architects can act as clarity engineers, a five-step architectural thinking process, Architecture Decision Records, and the risks of letting AI generate systems without human judgment.
Matt Erman’s central view is that AI does not change what good architecture is, it changes how much it matters. In his words, “AI only amplifies what you are”: it speeds up strong engineers and accelerates chaos for those without foundations. This conversation with Luca Mezzalira, drawn from Erman’s book Grokking Software Architecture, covers why fundamentals are slipping, how architects should think about clarity, a practical design process, and where AI helps and where it introduces new risk.
Why fundamentals are going missing
Erman’s motivation came from mentoring junior developers at Blackboard. Basic foundational questions often met blank stares, and when developers did reach the right answer after some nudging, the knowledge did not seem internalized. He sees a gap between what college or bootcamps teach and what the job demands: learning concepts is not the same as learning to apply them in real systems. At the same time, AI has raised the bar for entry-level work, and junior hiring has dropped in many places. Erman argues this makes foundations more important than at any point in the industry’s history.
Architects as clarity engineers
Erman suggests architects should think of themselves as “clarity engineers”. The shift from asking “how do I get this to work” to “how do I build something that lasts” depends on clarity about what is being designed, which tradeoffs matter, and which questions to put to the business. Mezzalira connects this to requirements translation: a product manager asking for a feature rarely states the architectural characteristics behind it. A demand for near-zero latency implies availability and resilience requirements, and surfacing those implicit needs is the core job.
Communication as a core architectural skill
Both speakers reject treating communication as a soft skill. Erman notes that the best idea doesn’t always win; the best-communicated one often does. Winning a debate requires people skills and some political awareness, but also professionalism: once a decision is made, everyone commits to it regardless of whose idea it was. He also points to language precision. English dominates technical discussion because its technical vocabulary has exact definitions, and approximations in other languages tend to cause trouble as systems grow.
A five-step architectural process
The book’s process starts with the request itself: what are you being asked to build? Next comes asking why, repeatedly. Erman borrows Toyota’s Five Whys to move from the surface request to the real driver, which might be a marketing launch deadline rather than a technical need. Then sketch the design on a napkin or whiteboard to make the idea concrete. Finally, write the decision down, including what you are explicitly not optimizing for.
Erman stresses that there is no perfect solution, only the best one for the constraints at hand. A three-person team with a two-week deadline should not build a web of microservices. Writing down non-goals, such as not optimizing for a million users when adoption is unknown, gives the team guardrails and a clear mental model before coding begins.
Architecture Decision Records
Erman’s team uses ADRs extensively. Their main value is stopping teams from rehashing the same debate every few weeks. A useful record captures who was present, the topic, the decision, the reasoning, what could trigger revisiting it, and when to revisit. He notes that other teams use similar formats under different names.
Decentralized, collaborative architecture
Both observe that architecture is becoming less of an ivory tower exercise. Erman’s team has no fixed roles; everyone works across front end, back end, and DevOps, and manages its own cloud environment. This spreads knowledge and avoids the situation where one person’s departure leaves a system nobody understands. Mezzalira adds that decentralization makes continuous enablement essential, since architectural outcomes compound over months or years rather than showing up within a week.
AI and the shifting value of engineers
Erman sees engineering value moving up the stack. Many engineers now direct, plan, review, and challenge AI agents rather than writing code themselves. That shift carries risk: skills erode without practice, and if nobody reads code anymore, teams lose the ability to judge what they have shipped. He has seen engineers say they never look at the code at all, only set gates for the AI to operate within. Code that looks right can still fail once systems interact. The problem is not that AI writes bad code but that it knows too much. It knows every pattern and can stitch them into “Frankenstein code” that works today and breaks later.
Accountability does not shift either. Mezzalira points out that when production fails at 3 a.m., the pager goes to the engineer, not the model. Erman puts it bluntly: “AI told me to” is not a defensible answer in a PR review.
Speed raises the stakes for planning
Because AI accelerates development, an engineer may now juggle three or four features at once and make four or five architectural decisions in the time one used to take. Erman argues that planning matters more, not less, and that the correctness of decisions, the understanding of tradeoffs, and the setting of boundaries become critical.
Your API schema is the system prompt
Erman explains Hyrum’s Law: with enough users, every observable behavior of an API becomes a contract, documented or not. An unspoken ordering of database results can become something downstream systems depend on, so changing it breaks users who never saw a spec. Newer developers often treat APIs as simple data transport, when they are in fact public contracts that must be honored.
Deterministic tools and probabilistic AI
Mezzalira argues that decades of deterministic tooling, such as dependency updates and complexity analysis, remain valid. Combined with probabilistic AI, they can surface heuristics that were hard to codify, such as where boundaries belong. He gives an example: AI can be guided through a skills file to treat certain components coarsely, because a three-team organization should not be engineered like a thirty-team one.
Will AI replace architects?
Erman does not expect that soon. AI follows instructions well but struggles with context that lives outside the code: a decision made years ago, an unwritten operational constraint, or the knowledge that a seemingly harmless change will cause trouble. Deciding which context matters in a given situation still requires human judgment. He does see promise in agentic loops that audit and improve their own work. His practical tip for newer developers is to always ask the AI for an adversarial, architect-level review of its output, which often surfaces red flags, implementation gaps, and issues the first pass missed. He also avoids predicting too far ahead, noting how quickly capabilities are moving.
Advice for the next six months
Erman’s first recommendation is to step back before writing code. Early in a career the urge is to start coding immediately, but gaining clarity on what is required, asking about ambiguity rather than guessing, and mapping tradeoffs (“if we do this, this happens; if you want this, it adds two weeks”) prevents costly rework. Even a favorites button carries architectural decisions.
His second recommendation is to build for longevity through separation of concerns and modularity. Do not stuff everything into a controller because it works in one file. Learn where concerns separate, so that other parts of the system can reuse components without rewriting everything.