Neal Ford and Mark Richards argue that the familiar architect's reply — "it depends" — has become more important than ever. Generative AI can produce working services quickly, but that capability highlights the boundary between what these tools can do and what requires human contextual judgment.
The First Law: everything is a trade-off
The authors remind readers of a core maxim of software architecture: every decision is a trade-off. Generative AI does not overturn this principle; if anything, it makes the trade-offs more consequential. Large language models and similar tools excel at answering "how" questions — for example, how to implement a saga pattern, how to set up circuit breakers between services, or how to paginate an API. Those answers exist in documentation, open source code, and years of posts that LLMs have ingested.
Architectural questions, however, are typically not "how" questions but "should" or "why" questions. Honest answers to those require organizational context that is absent from training data: that your ops team is three people, that the CFO has frozen cloud spend, or that a recent reorg left the payments team demoralized. An AI can enumerate generic trade-offs for distributed systems, but it cannot weigh them — the weights live inside your organization, not on the internet.
This is essentially the Second Law the authors describe: "why is more important than how." LLMs are "how" machines; architects are "why" people.
Cheap code makes decisions expensive
The article points out that making code cheaper to produce does not reduce the importance of architecture — it increases it. When code was expensive, the cost of building acted as a brake on poor designs: a questionable architecture took months to implement and often got noticed in time. Today, a team can stand up a fleet of services in a week; that brake is gone. It is now easier than ever to build the wrong thing quickly and at scale, even with tests.
The authors describe AI as an amplifier: point it at a sound design and it accelerates progress; point it at a flawed design and it pours concrete over the flaw before anyone objects. The half-life of a bad architectural decision used to be tied to implementation time; now implementations arrive almost instantly, and organizations have to live with the consequences for years.
This shifts leverage: when implementation is abundant, judgment becomes the scarce resource. Someone still needs to decide service boundaries, what "good enough" availability means for a system, and which architectural qualities truly matter.
Judgment is not acquired by reading alone
The uncomfortable truth is that trade-off analysis cannot be learned only by consuming content. Ford and Richards acknowledge that books and talks provide vocabulary and pattern catalogs, but not judgment. Judgment arises from making decisions and living with their consequences, or from watching experienced practitioners make decisions, asking why, and debating alternatives. Most working architects learned the craft through messy, real problems and feedback loops — the pattern catalog was the easy part; knowing which pattern not to use and why took years of repetitions.
This is precisely what today's AI lacks: a model trained on the world's code has observed millions of decisions but almost none of the consequences. A postmortem that links an outage to a boundary drawn incorrectly in 2019 rarely becomes part of training data, and even when it does, it is not connected to the pull request that caused the change. Architecture's feedback loops are measured in years — the sort of learning that cannot be scraped.
What this means for engineers
For developers watching AI take on more implementation work, the strategic question is where to move up the value chain. The authors advise moving toward decisions: trade-offs, constraints, and the "it depends" territory. That territory is expanding, because every AI-accelerated team needs someone who can tell the amplifier where to point.
The good news is that this skill is learnable — but not from a book alone or from an LLM. It is learned the traditional way: practicing architectural thinking on real problems with experienced people asking "why." The authors note that they have spent several years teaching this approach, most recently in a six-week cohort format that resembled a short apprenticeship focused on making and defending architectural decisions.
However one pursues it, pursue it: machines have become very good at "how." The career-defining skill of the next decade will be the person in the room who can answer "should," who starts with "it depends," and can finish the sentence using their own judgment alone.
