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.
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.