Not sure how you thread the needle on the quality vs quantity dynamic.
Haskell also has a confounding issue: Because of its focus on research and experimentation, standard best practices don't exist like they do in languages optimized for real-world use. Because there are few community guidelines, engineering practices vary widely, and unfortunately at the same time, Haskell's public codebase resources are small.
To see this playing out, check out Haskell discussions about choosing a SQL library, effect system, monad transformer stack, or web framework. The answers are all over the map because that diversity is baked into Haskell's culture and practice.
that and the language supports (enforces) good decision making; static typing w/ inference and a functional style as a first class concept.
which then rolls into the same result : higher quality code available.
it's a lot harder to experience an agent telling you with certainty that something incomplete is totally finished if there is a comprehensive test suite, a hard failing compiler, a strict type system, etc.
LLMs like to produce a lot of JS and python that silently fails in a graceful way -- why is that? because those languages support that kind of a failure.
when using something like go/rust the LLMs are more likely to re-iterate rather than declaring a victory when they get a strict compiler barking in their face, refusing to output.