I think that keeping the code that the LLMs write relative small and highly focus will lead to a code base that's easy to maintain over the long term.

I plan to create an app that relies heavily on LLM written code. I'm hoping that if I architect it as if am working with a team of programmers I'll be able to create a code based that I can update over the long term. I'll assign it assingments that I can then merge into the master codebase. You're in the same path. That's 2 of us. I think it will work out. We'll get what we want while saving a ton of time.

Code "quality" is a judgement call. Just like some LLMs, I'll repeat your question: What do you consider quality code?

I treat all code from LLM, search, stackoverflow, etc, as "sample code" that requires review and most likely modification, or writing the code from scratch. Your abilities and laziness may vary.

Also, there are reasons other than code quality not to trust LLMs.

It also had a globbing test I'd never seen before, something like "if [[ $X = *"string"* ]]". It works, but wow, ugly.

The new bash program looked old, like someone with a distinct set of preferences wrote it years ago and 2 or 3 maintainers had hacked on it, being less careful to keep a consistent style.

That sort of thing would be judged low quality legacy code 5 years ago. It's harder for a human to understand, and since it just might depend on a peculiarity of "=" vs "==" vs "-eq", people make minimum changes or maybe no change at all. That's one way "low quality" you seek is exhibited.

Even thought the code quality is garbage ~90% time (to me), it’s still more fun than before—which is why I still use it.

Woe on to you though if you vibe code and don’t edit and don’t have taste from years of doing it manually before LLMs. You are building a mountain of tech debt (although maybe you can grow and hire fast enough to where that’s not an issue).