Indeed, and I don't think there's any reliable signal other than the author saying so that something is "vibe coded" vs. "I used an LLM for some aspect of it."
I recently ran an experiment where I tried to use _quantitative signals_ (and not _qualitative_ ones) to tell whether something is vibe-coded or not.
My idea was that, if I see that your project is growing 10k LOC per week and you're the only developer working on it, it's most likely vibe-coded.
I analyzed some open-source projects, but unfortunately it turns out not to be so clear cut. It's relatively easy to estimate the growth rate of a project, but figuring out how much time developers worked on it is very error prone, which results in both false positives and false negatives.
The biggest signal is not the code itself but whether the thing is actively and continually developed for more than a few weeks.
And then look through the commits -- were they only adding new features, or did the author(s) put effort into improvements on engineering fundamentals (benchmarking, testing, documentation, etc)?
Perhaps a year ago “vibe coding” was indicative of a low quality product.
It seems many have not updated their understanding to match today’s capabilities.
I am vibe coding.
That does not mean I am incompetent or that the product will be bad. I have 10 years of experience.
Using agentic AI to implement, iterate, and debug issues is now the workflow most teams are targeting.
While last year chances were slim for the agent to debug tricky issues, I feel that now it can figure out a lot once you have it instrument the app and provide logs.
It sometimes feels like some commenters stick with last year’s mindset and feel entitled to yell about ‘AI slop’ at the first sign of an issue in a product and denigrate the author’s competence.
No, it is still indicative of a low quality product. And I say that as someone who has probably been agentic coding longer than you have.
Indicative in my dictionary doesn't mean definitive. It just makes it much more likely. You can make quality products while LLMs write >99% of the code. This has been possible for more than a year, so it's not a lack of updating of beliefs that is the issue. I've done so myself. Rather, 90% of above products are low quality, at a much higher rate than say, 2022, pre-GPT. As such, it's an indicator. That 10% exists, just like pearls can hide in a pile of shit.
As others have said the reason is time investment. You can takes 2 months to build something where the LLM codes 99%. Or you can take 2 hours. HN, and everywhere else, is flooded by the latter. That's why it's mostly crap. I did the former. And luckily it led to a good result. Not a coincidence.
This applies far beyond coding. It applies to _everything_ done with LLMs. You can use them to write a book in 2 hours. You can use them to write a book in 2 years.
I've been neck deep in a personal project since January that heavily leverages LLMs for the coding.
Most of my time has been spent fitting abstractions together, trying to find meaningful relationships in a field that is still somewhat ill-defined. I suppose I could have thrown lots of cash at it and had it 'done' in a weekend, but I hate that idea.
As it stands, I know what works and what doesn't (to the degree I can, I'm still learning, and I'll acknowledge I'm not super knowledgeable in most things) but I'm trying to apply what I know to a domain I don't readily understand well.
Indeed, and I don't think there's any reliable signal other than the author saying so that something is "vibe coded" vs. "I used an LLM for some aspect of it."
I recently ran an experiment where I tried to use _quantitative signals_ (and not _qualitative_ ones) to tell whether something is vibe-coded or not.
My idea was that, if I see that your project is growing 10k LOC per week and you're the only developer working on it, it's most likely vibe-coded.
I analyzed some open-source projects, but unfortunately it turns out not to be so clear cut. It's relatively easy to estimate the growth rate of a project, but figuring out how much time developers worked on it is very error prone, which results in both false positives and false negatives.
I wrote a post about it (https://pscanf.com/s/352/) if you're interested in the details.
Ask a llm for a code review along code duplication, encapsulation and sequential coupling as quality axes and the difference should show up readily
The biggest signal is not the code itself but whether the thing is actively and continually developed for more than a few weeks.
And then look through the commits -- were they only adding new features, or did the author(s) put effort into improvements on engineering fundamentals (benchmarking, testing, documentation, etc)?
Perhaps a year ago “vibe coding” was indicative of a low quality product.
It seems many have not updated their understanding to match today’s capabilities.
I am vibe coding.
That does not mean I am incompetent or that the product will be bad. I have 10 years of experience.
Using agentic AI to implement, iterate, and debug issues is now the workflow most teams are targeting.
While last year chances were slim for the agent to debug tricky issues, I feel that now it can figure out a lot once you have it instrument the app and provide logs.
It sometimes feels like some commenters stick with last year’s mindset and feel entitled to yell about ‘AI slop’ at the first sign of an issue in a product and denigrate the author’s competence.
No, it is still indicative of a low quality product. And I say that as someone who has probably been agentic coding longer than you have.
Indicative in my dictionary doesn't mean definitive. It just makes it much more likely. You can make quality products while LLMs write >99% of the code. This has been possible for more than a year, so it's not a lack of updating of beliefs that is the issue. I've done so myself. Rather, 90% of above products are low quality, at a much higher rate than say, 2022, pre-GPT. As such, it's an indicator. That 10% exists, just like pearls can hide in a pile of shit.
As others have said the reason is time investment. You can takes 2 months to build something where the LLM codes 99%. Or you can take 2 hours. HN, and everywhere else, is flooded by the latter. That's why it's mostly crap. I did the former. And luckily it led to a good result. Not a coincidence.
This applies far beyond coding. It applies to _everything_ done with LLMs. You can use them to write a book in 2 hours. You can use them to write a book in 2 years.
I've been neck deep in a personal project since January that heavily leverages LLMs for the coding.
Most of my time has been spent fitting abstractions together, trying to find meaningful relationships in a field that is still somewhat ill-defined. I suppose I could have thrown lots of cash at it and had it 'done' in a weekend, but I hate that idea.
As it stands, I know what works and what doesn't (to the degree I can, I'm still learning, and I'll acknowledge I'm not super knowledgeable in most things) but I'm trying to apply what I know to a domain I don't readily understand well.