One of the problems with vibe coding is that the hardest part of software engineering is not writing the code, rather it's *choosing* what to code, and designing the system (and, later on, maintaining the code/operations/etc)
The barriers and investment cost to writing code is itself a *desirable* aspect of software engineering because it forces you to make careful, good choices before you invest in building something
Because the majority of the time spent writing, say, curl, is not writing the original tool but rather maintaining it over time, it's important to make good choices from the beginning, and at every major version change
Insecurity Princess 🌈💖🔥
in reply to Insecurity Princess 🌈💖🔥 • • •Early in my career, I built a system for a customer that made it easier for their university to automate sending invitations and login instructions for new users.
I missed some key differences in some user environments that weren't covered in my testing, and I ended up sending thousands of malformed login invitations... twice.
Insecurity Princess 🌈💖🔥
in reply to Insecurity Princess 🌈💖🔥 • • •If I'd been forced to write separate login invitations manually for each segment of the user population, I would also have been forced to do more fine grained testing and take more care to ensure it works and think through the details.
But as a starryeyed new engineer, I was too excited by the idea of automating the whole thing in one go. I made it too easy to distribute the impact of my mistake, and I wasted the time of thousands of users.
EndlessMason
in reply to Insecurity Princess 🌈💖🔥 • • •Tim Ward ⭐🇪🇺🔶 #FBPE
in reply to Insecurity Princess 🌈💖🔥 • • •Marc
in reply to Insecurity Princess 🌈💖🔥 • • •I'd be surprised if their app could not be made with less than 10k locs...
recursive 🏳️🌈
in reply to Insecurity Princess 🌈💖🔥 • • •I think it's an immature attitude borne out of people resigned to working within languages and frameworks that force a lot of 'boilerplate' on them, who haven't had a chance to develop the understanding that there are better approaches (more expressive *durable* abstractions, etc)
Proponents of the tool seem to extrapolate from the relative increase in ability of these tools in the past 6 months (mostly due to more cleverly wiring them up to the ability to use external tools and edit files) that in another 6 months they'll solve significant issues of design ... and I'm not seeing evidence of it