A meaningful distinction to me at least is that when I’m vibecoding a one-off personal project I don’t care about, I don’t even look at the code.
When I’m using LLMs on a serious project that matters, I never blanketly give it a task to write code. Debugging and investigation work is more “go do the thing” vibecody, but when it comes to actually implementing fixes or features: I’d only ever use an LLM when I already know what the code should look like. And most of the time, when I’m writing in a language that I’m not perfectly familiar with, it’s writing as good as me if not better. Its a flat win case. In something like C++, I have a particular style and am very pedantic, and I know the standard very well, and so I tend to need to handhold and fix or rewrite a lot more. The vast majority of programmers who write C++ don’t write like I do, and I’m willing to bet that my “like me or better” statement about languages I’m only intermediate in applies to most casual or junior C++ devs.
With that said, his diff seems to have a hell of a lot of additions. I’d be willing to bet if he’s using Frontier LLMs that the vast majority of that is testing (and comments if they use claude…)
I think if someone has a hard no-AI stance, then it’s probably just safe to avoid the project. Whether or not it’s “vibecoding” depends a lot on their workflow and their standards.
If I need to write 10,000 lines, and I know what it should look like, and the AI produces that: I see no reason why I should waste my time typing it all out by hand. With that said, “Bot, go implement XYZ” isn’t how I or most experienced devs work with AI, and that’s where a lot of problems come from.
The good news is that it’s mostly a self-solving problem, because those codebases become completely impossible to work in over time.
A meaningful distinction to me at least is that when I’m vibecoding a one-off personal project I don’t care about, I don’t even look at the code.
When I’m using LLMs on a serious project that matters, I never blanketly give it a task to write code. Debugging and investigation work is more “go do the thing” vibecody, but when it comes to actually implementing fixes or features: I’d only ever use an LLM when I already know what the code should look like. And most of the time, when I’m writing in a language that I’m not perfectly familiar with, it’s writing as good as me if not better. Its a flat win case. In something like C++, I have a particular style and am very pedantic, and I know the standard very well, and so I tend to need to handhold and fix or rewrite a lot more. The vast majority of programmers who write C++ don’t write like I do, and I’m willing to bet that my “like me or better” statement about languages I’m only intermediate in applies to most casual or junior C++ devs.
With that said, his diff seems to have a hell of a lot of additions. I’d be willing to bet if he’s using Frontier LLMs that the vast majority of that is testing (and comments if they use claude…)
I think if someone has a hard no-AI stance, then it’s probably just safe to avoid the project. Whether or not it’s “vibecoding” depends a lot on their workflow and their standards.
If I need to write 10,000 lines, and I know what it should look like, and the AI produces that: I see no reason why I should waste my time typing it all out by hand. With that said, “Bot, go implement XYZ” isn’t how I or most experienced devs work with AI, and that’s where a lot of problems come from.
The good news is that it’s mostly a self-solving problem, because those codebases become completely impossible to work in over time.