The idea that every crash isn't acted on is kind of a crazy one, to me. Not every crash is actually actionable in e.g. a mobile app, but every one should at least get an eyeball in my opinion.
This, to me anyway, is the bare minimum of "caring about software quality". If you do this regularly you'll have very solid code, and it's interesting that I have the perception at least that Guild Wars was a quality product.
There's another layer, where you do that for subthreshold issues like UI inconvenience, etc, but that's bonus, I think.
It's a shame, though, because I believe there is a lot of potential there.
I mean, quality is easier with the right tooling (monitoring, linters, property-based tests, theorem prover...). But, given limited resources, it can feel difficult to prioritize investing in quality when business is pressing devs to ship, ship, ship.
But now the cost of writing custom tooling has changed. These custom tools might be sloppy because vibe-coded but we wouldn't have them otherwise! Or we might finally have decided to make that investment after too much time suffering from their absence. Now the cost/benefit changed, so why not invest now?
There’s a lot of good tools out there that are not used, either because of ignorance of their existence or lack of expertise. An hour of config can pay real dividend later.
And sometimes you just use some unix utilities and hack a bash script while testing things out.
LLM can save hours of doc reading for non-critical tools that I would otherwise not use. Its also pretty good at "hacking a bash script" in order to test things out. Not everyone is confortable writing bash scripts.