No, but it can help a capable developer to have more of those moments, as one can use LLMs and coding agents to (a) help explain the relationships in a complicated codebase succinctly and (b) help to quickly figure out why one’s code doesn’t work as expected (from simple bugs to calling out one’s own fundamental misunderstandings), giving one more time to focus on what matters to oneself.
help explain the relationships in a complicated codebase succinctly
It will offer an explanation, one that sounds consistent, but it’s a crap shoot as to whether or not it accurately described the code, and no easy of knowing of the description is good or bad without reviewing it for yourself.
I do try to use the code review feature, though that can declare bug based on bad assumptions often as well. It’s been wrong more times than it caught something for me.
Yeah - there’s definitely a GIGO factor. Throwing it at a undocumented codebase with poor and inconsistent function & variable names isn’t likely to yield great revelations. But it can probably still tell you why changing input X didn’t result in a change to output Y (with 50k lines of code in-between), saving you a bunch of debugging time.
TBH, it’s not really that great at that. Is average at best and grossly misleading and flat out wrong at worst. It may bring slight speedups for average development on boring legacy enterprise code, but anything really novel and interesting? Detrimental.
Most code on the planet is boring legacy code, though. Novel and interesting is typically a small fraction of a codebase, and it will often be more in the design than the code itself. Anything that can help us make boring code more digestible is welcome. Plenty of other pitfalls along the way though.
Fair enough, that’s true. I guess my gripe is with the narrow use case and the debugging and/or prompt/context tuning to get what you want. I still feel that if you don’t get what you want on the first try, it’s faster to write it yourself than spending time “debugging” the input and maybe get a 60% chance on correct output, which in most cases, still needs debugging. And god forbid, a framework is rewritten.
I just wished it was a bit better before we hit the plateau of diminishing returns.
Hah, yeah. Vibe coding and prompt engineering seem like a huge fad right now, although I don’t think it’s going to die out, just the hype.
The most successful vibe projects in the next few years are likely to be the least innovative technically, following well trodden paths (and generating lots of throwaway code).
I suppose we’ll see more and more curated collections of AI-friendly design documents and best-practice code samples to enable vibe coding for varied use-cases, and this will be the perceived value add for various tools in the short term. The spec driven development trend seems to have value, adding semantic layers for humans and AI alike.
AI can help you be more agile in getting out a PoC but vibe coding always ends up eating itself and you either aren’t capable enough to fix it (because you are a vibe coder) or you spend more time on the back 9, trying to clean up the code so you don’t have so many hacks and redundancy because the AI was too literal or hallucinated fake libraries that return null or its context window expired and it wrote 5 different versions of the same function
Eh, I’ve enjoyed writing a SQL query and having AI translate it to Linq. I’ve had at least one work directly, very clear on what it’s doing, just with Linq’s odd syntax. The other query was more complicated and wasn’t something that translated well to Linq. I may have had to split that into two Linq queries.
Then again, I wouldn’t count translating psuedocode (or SQL) as really vibe coding. To me “vibe coding” means you’re not really looking at the code it produces.
It’s a changing world, and there is going to be an ever increasing amount of AI slop out there, and even more potential programmers who won’t make the leap due to the crutch.
At the same time, there are always people who want to and will learn in spite of the available crutches the latest tech revolution brings.
There will also be many good engineers who will exploit the tech for all its worth while applying appropriate rigour, increasing their real productivity and value manyfold.
And there will be many non-programmers who can achieve much more in their respective fields, because AI tools can bridge gaps for them.
Hopefully we won’t irreversibly destroy ourselves and our planet while we’re at it. 🙈
No, but it can help a capable developer to have more of those moments, as one can use LLMs and coding agents to (a) help explain the relationships in a complicated codebase succinctly and (b) help to quickly figure out why one’s code doesn’t work as expected (from simple bugs to calling out one’s own fundamental misunderstandings), giving one more time to focus on what matters to oneself.
It will offer an explanation, one that sounds consistent, but it’s a crap shoot as to whether or not it accurately described the code, and no easy of knowing of the description is good or bad without reviewing it for yourself.
I do try to use the code review feature, though that can declare bug based on bad assumptions often as well. It’s been wrong more times than it caught something for me.
Wow, well it’s absolutely terrible at A. B is worth a shot, but it’s 50/50 to bullshit you in my experience.
Yeah - there’s definitely a GIGO factor. Throwing it at a undocumented codebase with poor and inconsistent function & variable names isn’t likely to yield great revelations. But it can probably still tell you why changing input X didn’t result in a change to output Y (with 50k lines of code in-between), saving you a bunch of debugging time.
TBH, it’s not really that great at that. Is average at best and grossly misleading and flat out wrong at worst. It may bring slight speedups for average development on boring legacy enterprise code, but anything really novel and interesting? Detrimental.
Most code on the planet is boring legacy code, though. Novel and interesting is typically a small fraction of a codebase, and it will often be more in the design than the code itself. Anything that can help us make boring code more digestible is welcome. Plenty of other pitfalls along the way though.
Fair enough, that’s true. I guess my gripe is with the narrow use case and the debugging and/or prompt/context tuning to get what you want. I still feel that if you don’t get what you want on the first try, it’s faster to write it yourself than spending time “debugging” the input and maybe get a 60% chance on correct output, which in most cases, still needs debugging. And god forbid, a framework is rewritten.
I just wished it was a bit better before we hit the plateau of diminishing returns.
Hah, yeah. Vibe coding and prompt engineering seem like a huge fad right now, although I don’t think it’s going to die out, just the hype.
The most successful vibe projects in the next few years are likely to be the least innovative technically, following well trodden paths (and generating lots of throwaway code).
I suppose we’ll see more and more curated collections of AI-friendly design documents and best-practice code samples to enable vibe coding for varied use-cases, and this will be the perceived value add for various tools in the short term. The spec driven development trend seems to have value, adding semantic layers for humans and AI alike.
AI can help you be more agile in getting out a PoC but vibe coding always ends up eating itself and you either aren’t capable enough to fix it (because you are a vibe coder) or you spend more time on the back 9, trying to clean up the code so you don’t have so many hacks and redundancy because the AI was too literal or hallucinated fake libraries that return null or its context window expired and it wrote 5 different versions of the same function
Eh, I’ve enjoyed writing a SQL query and having AI translate it to Linq. I’ve had at least one work directly, very clear on what it’s doing, just with Linq’s odd syntax. The other query was more complicated and wasn’t something that translated well to Linq. I may have had to split that into two Linq queries.
Then again, I wouldn’t count translating psuedocode (or SQL) as really vibe coding. To me “vibe coding” means you’re not really looking at the code it produces.
It’s a changing world, and there is going to be an ever increasing amount of AI slop out there, and even more potential programmers who won’t make the leap due to the crutch.
At the same time, there are always people who want to and will learn in spite of the available crutches the latest tech revolution brings.
There will also be many good engineers who will exploit the tech for all its worth while applying appropriate rigour, increasing their real productivity and value manyfold.
And there will be many non-programmers who can achieve much more in their respective fields, because AI tools can bridge gaps for them.
Hopefully we won’t irreversibly destroy ourselves and our planet while we’re at it. 🙈
Removed by mod
Hm? Oh, I obviously misread the room. It seems I interrupted a circle jerk? My apologies.
I thought you made a good point. I have decades of experience and I find LLMs useful for the things you described.
I have a suspicion that the guy took issue with my use of “one” instead of “you”, more-so than the content. Maybe it came across as uppity.