That's a good point, and I don't think the author would disagree with your take. "How to build" can refer to many things at once, some which still matter and some which don't. In the case of the analogy it means you're no longer optimizing the micro-structure of cut stones, in favor a homogenous slurry that is quick to produce. Of course the macro decisions still matter. A well-built roman bridge could last centuries (depending on the nature of erosion it was contending with), a concrete/rebar structure cannot. When it comes to computer systems the tradeoffs are just different, for example, how we model, validate and persist data is much much more important than the details of the code that processes it.

I have a slightly different angle on the quoted sentence though. In my mind "what should we build" was always the most important question. Code becoming cheaper to produce just highlights that more than ever. But even before agentic coding, the world was full of software that was not fit for purpose because the people calling the shots lacked some dimension of how to translate a problem statement into a workable system (computerized or otherwise), and built by programmers who were content (or at least complicit) in not probing any of those questions with decision makers.

That's why I don't think AI is inherently bad for software—it at least has the potential to empower those with better judgment since the sheer cost of production can no longer be an excuse for why something makes absolutely no sense from the end-user perspective. There are other, larger risks with AI at a societal level, but I don't think it's inherently bad for software quality.