alt Hacker NewsI like the analogy, even if I find it a bit depressing. However, this caused me pause:
> Instead of the most important question being “how to build this”, or “can we build this”, now the most important question is “what should we build”.
Do people really think software is just a matter of paying for the tokens now? If that were true we should be able to ask for a web browser that is faster, leaner, more secure and more capable than all existing browsers, or otherwise be told why it can't be done. Given that the standards are all written down I shouldn't need to give any further direction. I would have thought AI companies would have tried this before trying something like Navier-Stokes.
Replies
Treating code as a low-entropy amorphous blob is a quick way to see bridges collapse.
It works for concrete because its tensile and compressive strengths are well known for a given composition, but for high-entropy products like software you pretty much need to also generate a formal proof to have any assurances.
Which, ignoring the production costs and assuming that the proof is in fact correct, is only ever as good as the specification.
If you were looking for a physical analogy for software development, it's closer to growing crystals than pouring concrete.
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.