What if I am a quality person and I am disappointed because LLMs are squandering any remaining commitment to quality in favor of quantity and speed in certain environments?

Then you might want to spend more time on the quality of your guard rails. It's the best way to ensure LLMs produce higher quality output. To get the best results, you need to get systematic about enforcing what you want. Guardrails are one of the tools for doing that.

A lot of developers are acting like passive bystanders here. You can take a more active role in the whole process, including doing quality assurance and correcting LLMs when needed. And like it or not, QA is actually still part of your job. A lot of developers never liked doing QA. The good news is that you can make the LLM do most of that. But it helps if you are a bit opinionated about how to do QA. Again, guardrails.

For example, if you care about performance, get systematic about performance testing and tell the LLM to find and fix your performance bottlenecks. I did that with a Go server a few months ago. It was functionally correct but it had a few bottlenecks. So, I generated a benchmark and then made the LLM suggest and implement solutions for all these bottlenecks. Once it had the benchmark, it got good at testing and validating its own solutions. After a few iterations, I had very decent throughput.