Comment by anonzzzies
4 months ago
I mainly use vibe coding to figure out how hard something is to do if I would do it 'for real', so I vibe code working prototypes, often to find out there is no way this is feasible and, more often, finding it is easier than I thought it would be. When I have an issue, I search for a library to solve that issue, but to figure it it does and if it does in a friendly way, I have to try it, so I ask claude to give me my example in that library. I already know something is up if it doesn't work first shot; to me is not a shock that 99.9999% (well that is actually not true of all language ecosystems but the most popular ones) of all libraries out there are total garbage with very strange 'opinionated' abstractions/choices in them that truly suck and actually make some use cases impossible without changing the library itself even though it says in the manual it is possible but without an example. In that case the LLM usually hallucinates a parameter or function that it doesn't have but that is from another library or does not exist at all, ideally needed to implement said use case. LLMs save me a ton of time there and I assume it's low quality as I won't use that exact piece of code anyway, but now I know the effort involved to meet my specific use case.
Wanted to say something similar : high-quality code is not an excuse to make something that doesn't "work" (in regards to sales, usefulness, iterations, learning - all for which vibe coding are a perfect fit IMHO)