I fear for the variety in the internet coding culture. Significant portion of code is being written by ai, all looks the same, all has the same mediocre quality. Even the github page descriptions are generated with ai, overflowing with emojis and same sentence structures repeated.
> I fear for the variety in the internet coding culture. Significant portion of code is being written by ai, all looks the same, all has the same mediocre quality.
Who cares who actually "typed" it? Shit code will be shit code regardless of author, there is just more of it now compared to before, just like there was more 10 years ago compared to 20 years, as the barriers for getting started is lowered time and time again. Hopefully, it'll be a net-positive, just like previous times, it's never been easier to write code to solve your own specific personal problems.
Developers who have strict requirements on the code they "produce" will make the LLM fit with their requirements when needed, and "sloppy" developers will continue to publish spaghetti code, regardless of LLMs existence.
I don't get the whole "vibe-coding" thing because clearly most of the code LLMs produce is really horrible, but with good prompting, strict reviews and not accepting bad changes just to move forward lets you mold the code into something acceptable.
(I have not looked at this specific project's code, so not sure this applies to this project, but is more of a general view obviously)
I think the issue is, you used to be able to tell at a glance how much effort someone put into a project (among other things) and that would give you a reasonable approximation of what to expect from the project itself.
But now the signals are much harder to read. People post polished looking libraries / tools with boastful convincing claims about what they can do for you, yet they didn't even bother to check if they work at all, just wasting everyone's time.
Not even "care". The result is the only thing that matters. If at a first glance the source code of a project doesnt look pretty or whatnot odds might be that the reader landed on particularly nasty chunk or that it was indeed as complicated as the code itself. In my view this test is better done after the overall functionality of the software has been proven. Honestly if libraries with fancy benchmarks don't solve the business problem, I won't care much how clean their code is or if its written in Rust.
How is this commentary relevant to this project in any way? Why must every post about an LLM tool be accompanied by a pile of meta commentary about the LLM landscape? If someone posted a Ruby library, would we all start waxing philosophically about the Ruby ecosystem as a whole?
I’m not trying to attack your comment specifically, but every single post about LLMs being accompanied by deeply subjective, usually negative, meta commentary is highly annoying.
I left a comment like that, because the project itself is about the productivity of AI. Project aims to increase it. Mine is also about productivity of AI. But my distaste about its blandness.
On the whole meta discussion thing, i have been reading HN for at least 15 years. Posts with lots of comments are meta discussions. HN is not really a place to discuss technics of a project.
First of all, there are certainly many issues with abusing vibe coding in a production environment. I think the core problem is that the code can't be reviewed. After all, it's ultimately people who are responsible for the code.
However, not all code requires the same quality standards (think perfectionism). The tools in this project are like blog posts written by an individual that haven’t been reviewed by others, while an ASF open-source project is more like a peer-reviewed article. I believe both types of projects are valid.
Moreover, this kind of project is like a cache. If no one else writes it, I might want to quickly vibe-code it myself. In fact, without vibe coding, I might not even do it at all due to time constraints. It's totally reasonable to treat this project as a rough draft of an idea. Why should we apply the same standards to every project?
In fact, their approach to using vibe coding in production comes with many restrictions and requirements. For example:
1. Acting as Claude's product manager (e.g., asking the right questions)
2. Using Claude to implement low-dependency leaf nodes, rather than core infrastructure systems that are widely relied upon
3. Verifiability (e.g., testing)
BTW, their argument for the necessity of vibe coding does make some sense:
As AI capabilities grow exponentially, the traditional method of reviewing code line by line won’t scale. We need to find new ways to validate and manage code safely in order to harness this exponential advantage.
How does this compare with Claude Code's native OTEL reporting? Having a quick look at the codebase it looks like it parses your local Claude Code JSON files, why?
I’ve always wanted to do an analysis of how I use Claude Code. Then I found out that someone had already done it. I looked at my own usage data, and for now, there’s nothing particularly interesting. I wonder if anyone has any ideas.
I fear for the variety in the internet coding culture. Significant portion of code is being written by ai, all looks the same, all has the same mediocre quality. Even the github page descriptions are generated with ai, overflowing with emojis and same sentence structures repeated.
> I fear for the variety in the internet coding culture. Significant portion of code is being written by ai, all looks the same, all has the same mediocre quality.
Who cares who actually "typed" it? Shit code will be shit code regardless of author, there is just more of it now compared to before, just like there was more 10 years ago compared to 20 years, as the barriers for getting started is lowered time and time again. Hopefully, it'll be a net-positive, just like previous times, it's never been easier to write code to solve your own specific personal problems.
Developers who have strict requirements on the code they "produce" will make the LLM fit with their requirements when needed, and "sloppy" developers will continue to publish spaghetti code, regardless of LLMs existence.
I don't get the whole "vibe-coding" thing because clearly most of the code LLMs produce is really horrible, but with good prompting, strict reviews and not accepting bad changes just to move forward lets you mold the code into something acceptable.
(I have not looked at this specific project's code, so not sure this applies to this project, but is more of a general view obviously)
I think the issue is, you used to be able to tell at a glance how much effort someone put into a project (among other things) and that would give you a reasonable approximation of what to expect from the project itself.
But now the signals are much harder to read. People post polished looking libraries / tools with boastful convincing claims about what they can do for you, yet they didn't even bother to check if they work at all, just wasting everyone's time.
It's a weird new world.
I think you should never do that. Who cares how much effort went into something ? Its the result that matters.
Maybe "care" would have been more appropriate than "effort".
Not even "care". The result is the only thing that matters. If at a first glance the source code of a project doesnt look pretty or whatnot odds might be that the reader landed on particularly nasty chunk or that it was indeed as complicated as the code itself. In my view this test is better done after the overall functionality of the software has been proven. Honestly if libraries with fancy benchmarks don't solve the business problem, I won't care much how clean their code is or if its written in Rust.
It's fake polish, but at the end of the day you have always to check whats in the codebase if you're gonna vendor it in or adopt it as a dep imho
if anything the smelly readme's that look all like claude wrote them, are a good tell to check deeper
How is this commentary relevant to this project in any way? Why must every post about an LLM tool be accompanied by a pile of meta commentary about the LLM landscape? If someone posted a Ruby library, would we all start waxing philosophically about the Ruby ecosystem as a whole? I’m not trying to attack your comment specifically, but every single post about LLMs being accompanied by deeply subjective, usually negative, meta commentary is highly annoying.
I left a comment like that, because the project itself is about the productivity of AI. Project aims to increase it. Mine is also about productivity of AI. But my distaste about its blandness.
On the whole meta discussion thing, i have been reading HN for at least 15 years. Posts with lots of comments are meta discussions. HN is not really a place to discuss technics of a project.
I'm tired of <10 day old accounts being created on this site to pile on any dissenter to LLMs.
First of all, there are certainly many issues with abusing vibe coding in a production environment. I think the core problem is that the code can't be reviewed. After all, it's ultimately people who are responsible for the code.
However, not all code requires the same quality standards (think perfectionism). The tools in this project are like blog posts written by an individual that haven’t been reviewed by others, while an ASF open-source project is more like a peer-reviewed article. I believe both types of projects are valid.
Moreover, this kind of project is like a cache. If no one else writes it, I might want to quickly vibe-code it myself. In fact, without vibe coding, I might not even do it at all due to time constraints. It's totally reasonable to treat this project as a rough draft of an idea. Why should we apply the same standards to every project?
Anthropic talked about vibe coding in production: https://www.youtube.com/watch?v=fHWFF_pnqDk
In fact, their approach to using vibe coding in production comes with many restrictions and requirements. For example: 1. Acting as Claude's product manager (e.g., asking the right questions) 2. Using Claude to implement low-dependency leaf nodes, rather than core infrastructure systems that are widely relied upon 3. Verifiability (e.g., testing)
BTW, their argument for the necessity of vibe coding does make some sense:
As AI capabilities grow exponentially, the traditional method of reviewing code line by line won’t scale. We need to find new ways to validate and manage code safely in order to harness this exponential advantage.
How does this compare with Claude Code's native OTEL reporting? Having a quick look at the codebase it looks like it parses your local Claude Code JSON files, why?
I’ve always wanted to do an analysis of how I use Claude Code. Then I found out that someone had already done it. I looked at my own usage data, and for now, there’s nothing particularly interesting. I wonder if anyone has any ideas.
What’re you hoping or have some intuition you’ll discover/learn?
https://blog.continue.dev/intervention-rates-are-the-new-bui...
For example, error type distribution or intervention rates. This can tell me how efficient I am when using Claude.
But currently, the error type is a bit too broad, and I haven’t discovered much yet.
Feature suggestion: Costs (and tokens) per branch. I'm interested what branches we spend the most on.
another one: overall stats (same as per project)
I do use AI for vibe coding a lot of slop, but I make a favour to myself and the world and keep those repo's mostly private.
Nobody should publish slop code AI assisted or not tbh