4 ms·
I have been SWE for almost three decades now - have read all the comments in this post and almost every negative comment about vibe coding holds true about almo
by bdangubic 1y ago
I have been SWE for almost three decades now - have read all the comments in this post and almost every negative comment about vibe coding holds true about almost every single ‘human-coded’ codebase I’ve ever seen ( some notable exceptions of course :) )
- raincole 1y agoYeah since when prototypes built to throwaway are a bad thing? They're arguably the most important step to build a business. Legacy code isn't a bad thing either. The majority of code that actually generates revenue right now is probably considered "legacy" by the devs working there.
- roywiggins 1y agoStuff that you know you aren't going to maintain? Vibe code it. It's fine. The article's point is that if you are planning to maintain something, you've created instant legacy code. Which might be fine, depending!
- qingcharles 1y agoThis. I'm using vibe-coding now to build little utils and apps that I will literally never maintain as they do one job, often a one-time job. In this situation vibe-coding is incredibly time-saving. I know zero about the code the LLM created, though. I've tried going through it, and it is all well-written, but it's all foreign. I wasn't there for any of its creation and I don't have any map in my head about the layout of the functions or the flow of the apps.
- ZeroGravitas 1y agoThe article is very pro-prototypes to throw away. I've also, in pre-llm days, seen warnings to not show visually polished prototypes to non-technical customers/salespeople/managers because they have no way of judging the quality and will try to force you to use the prototype immediately because "look, it's done".
- Arubis 1y agoYep. The humorous definition of legacy code is anything merged to trunk.
- vlovich123 1y agoKind of but vibe coding lets you attempt at tackling problems without bothering to do any research to understand what the solution needs to look like or how the existing codebase is structured. Just yesterday a coworker who knows little Rust vibe coded a new feature that “worked” but is actually horribly broken (lots of synchronous I/O/locks/channels in a tokio async context). On top of everything else, they created their own bad abstractions for things that already had safe async abstractions. If they’d had to actually do this themselves they either would have asked for help sooner so they could be guided or they would have done research in the code which already had examples on how to do things.
- cadr 1y agoWhen you say "almost" - could you say something about the codebases you saw where this doesn't apply? I'd love to hear about the best codebase you were SWE for and what we could learn from it.