Comment by palata

> [With compilers] There is a clear an unambiguous contract between the source code and what gets executed

Debatable in practice. You can't tell me you believe most developers understand what their compiler is doing, to a level of unambiguity.

Whether something gets unrolled, vectorized, or NOP-padded is mysterious. Hell, even memory management is mysterious in VM-based languages now.

And yes (to the inevitable follow-up) still deterministic, but those are things that developers used to have to know, now they don't, and the world keeps spinning.

> You can say that "it's okay if a website fails every 100 times, the user will just refresh and we're still more profitable". But wouldn't you agree that such a website is objectively of worse quality? It's cheaper, for sure.

I would say that's the reality we've been living in since ~2005. How often SaaS products have bugs? How frequently mobile apps ship a broken feature?

There are two components here: (1) value/utility & (2) cost/time.

There are many websites out there that can easily take a 1 in 100 error rate and still be useful.

But! If such a website, by dint of its shitty design, can be built with 1/100th of the resources (or 100x websites can be built with the same), then that might be a broader win.

Not every piece of code needs to fly in space or run nuclear reactors. (Some does! And it should always have much higher standards)

> Said differently: would you fly in a plane for which the autopilot was vibe coded? If not, it tells you something about the quality of the code.

I flew in a Boeing 737 MAX. To the above, that's a domain that should have called for higher software standards, but based on the incident rate I had no issue doing so.

> Do we always want better code? I don't know. What I see is that the trend is enshittification: more profit, worse products. I don't want that.

The ultimate tradeoff is between (expensive/less, better code) and (cheaper/more, worse code).

If everything takes a minimum amount of cost/effort, then some things will never be built. If that minimum cost/effort decreases, then they can be.

You and I are of like mind regarding enshittification and declining software/product standards, but I don't think standing in front of the technological advancement train is going to slow it.

If a thing can be built more cheaply, someone will do it. And then competitors will be forced to cheapen their product as well.

Imho, the better way to fight enshittification is creating business models that reward quality (and scale).