Again, I don’t really see the difference here. Whether the authors continue to maintain the project long or not has little to do with what tools were used to build the project. And calling anything where LLMs are used for development vibecoding is just silly to be honest. There’s a huge variation in quality of code both in hand written code and that where LLMs are used. What you should be looking at in both cases is how much usage project gets, how good the tests are, whether authors built useful things before, and so on.
If a project is useful then I really don’t care how it’s coded. Existing projects are in no way diminished by the fact that this project exists.
The exact same way you decide now. You go look at the projects, see which ones have the features you want, then you tend to look at how many users the projects have and how mature they are, and then pick one based on that. Don’t pretend that some thing changed here all of a sudden.
Correct, and again, I’m someone who uses AI, I’m not one of the ones who are purely against it. The definition what what I’ve both done and seen:
Using LLMs to code - fine. It’s a tool, use it as you’re saying. This is not what I’m talking about.
Using LLMs to vomit out all of your code into one commit is vibecoding. It’s clearly vibecoding when there weren’t even multiple commits. No trial and error, no refinement, just one giant dump.
I do care how it’s coded because it shows how well it will be maintained into the future. If someone uses LLMs over months to build something it will probably be maintained. If someone vomited out all of that code in one vibecoded session, it’s very likely they’ll be bored and in a month it’ll be abandoned. That’s what I’m looking at, because tests can be automated now.
Maybe I’ll be wrong and in a month they’ll have committed hundreds of times and are trying to mature it. I have no evidence of that though, so there is no reason I’d risk trying it out.
Using LLMs to vomit out all of your code into one commit is vibecoding. It’s clearly vibecoding when there weren’t even multiple commits. No trial and error, no refinement, just one giant dump.
Yeah, I completely agree there. Just like with regular coding, you have to go slowly, implement functionality in small focused chunks, review, and iterate.
And I’d also wait and see whether the project continues to be maintained before considering it. I just posted it because I thought it was neat, and might be worth watching to see how it develops, not that I’d use it over a more mature option at the moment.
I think we’re actually in complete agreement here.
I don’t think you’re in the wrong to say that code nobody has reviewed has not proven safe, and a brand new project (of any kind) is not proven reliable. A brand new big project that’s purely vibe coded is every red flag of unsafe and unsustainable.
Again, I don’t really see the difference here. Whether the authors continue to maintain the project long or not has little to do with what tools were used to build the project. And calling anything where LLMs are used for development vibecoding is just silly to be honest. There’s a huge variation in quality of code both in hand written code and that where LLMs are used. What you should be looking at in both cases is how much usage project gets, how good the tests are, whether authors built useful things before, and so on.
If a project is useful then I really don’t care how it’s coded. Existing projects are in no way diminished by the fact that this project exists.
Worthless projects dillute valuable projects.
Imagine there being 100 photo projects like this.
One of them is immich. You are new and have no experience. How would you decide which one to install?
The exact same way you decide now. You go look at the projects, see which ones have the features you want, then you tend to look at how many users the projects have and how mature they are, and then pick one based on that. Don’t pretend that some thing changed here all of a sudden.
Correct, and again, I’m someone who uses AI, I’m not one of the ones who are purely against it. The definition what what I’ve both done and seen:
I do care how it’s coded because it shows how well it will be maintained into the future. If someone uses LLMs over months to build something it will probably be maintained. If someone vomited out all of that code in one vibecoded session, it’s very likely they’ll be bored and in a month it’ll be abandoned. That’s what I’m looking at, because tests can be automated now.
Maybe I’ll be wrong and in a month they’ll have committed hundreds of times and are trying to mature it. I have no evidence of that though, so there is no reason I’d risk trying it out.
Yeah, I completely agree there. Just like with regular coding, you have to go slowly, implement functionality in small focused chunks, review, and iterate.
And I’d also wait and see whether the project continues to be maintained before considering it. I just posted it because I thought it was neat, and might be worth watching to see how it develops, not that I’d use it over a more mature option at the moment.
I think we’re actually in complete agreement here.
I don’t think you’re in the wrong to say that code nobody has reviewed has not proven safe, and a brand new project (of any kind) is not proven reliable. A brand new big project that’s purely vibe coded is every red flag of unsafe and unsustainable.