I don't like the idea of shaming people for making OSS vibe-coded tools for niche hobbies, so I don't want to name names, but there is ABSOLUTELY some stuff on Github now that can be used to get the job done but has UI/API/code performance, consistency, and quality issues, that would've been unfathomable for the average OSS project in 2018. Because it's the sort of stuff that only happens when there isn't a human in the loop to point out some very-obvious swings-and-misses. Like "you don't need a third button here doing the same thing as these other two" or "this button literally does nothing in 3/4 of the modes, but it's never shown as disabled" or "this takes 5 times longer than it needs to and blocks the main UI thread because work is all happening sequentially."

In the past it wasn't really common at all to add 10 features in an evening without actually trying to use those 10 features by hand yourself.

Personally I think it's wonderful that tools for these spaces exist when they didn't use to. But it's also ludicrous to say that anyone with Claude can replace even mediocre homemmade stuff in any dimension other than "being worth building even a bad tool" or "getting to semi-usable faster." Currently you still benefit massively from knowing what's going on behind the scenes, and from knowing "software engineering 201" type stuff around what sort of testing would be helpful where, vs accepting model-default-output everywhere.

> there is ABSOLUTELY some stuff on Github now that can be used to get the job done but has UI/API/code performance, consistency, and quality issues, that would've been unfathomable for the average OSS project in 2018

I will take time to address you comment fully, there are lots to unpack, but I'd like to stop here and point out that comparing "absolutely some stuff" from today to the "average 2018 project" might be unfair. If you are going to compare the bottom of the pile of synthetic code, you should do the same with organic code of back then lest you draw an unfair comparison.