Can't you just say that you used Claude and be done with it? I mean, I don't really care but in general I would refrain from posting "Show HN" with stuff that has been vibed, or state that you did since in that case it's even more interesting from my point of view, like you could describe how you kept everything under control during generation, etc...
I mean, no biggie and I don't understand the reaction but hey, I'm old so...
I put Overview section from the Readme into an AI content detector and it says 92% AI. Some comment blocks inside codebase are rated as 100% AI generated.
That said, totally fair read on the comments. Curious if they helped/landed the way I intended. or if a multi-part blog series would’ve worked better :)
Thanks for the link, very interesting data structure.
I'm wondering is it really worth dumping a general knowledge articles into code comments? To me it feels like the wrong place. Would just the wikipedia link be enough here?
I also notice a lot of comments like this
// IsEnd checks if this is the EOF sentinel
//
// Example usage:
//
// if pos.IsEnd() {
// // We've reached the end, stop searching
// }
func (p *Position) IsEnd() bool {
return p.Offset == EOF
}
Is it really necessary to have a text description for a code like "a == b"? It would be really annoying to update comment section on every code change.
This is one of the typical issues when AI creates "code comments", because it always describes "What" is happening. A good comment should answer the question "Why" instead.
For the linked skip list module, a good comment could say why skip list was chosen over b-tree or other data structure and which trade offs were made. AI will never know that.
I wonder if I should really explain or if that would provide a list of things to sanitize before publishing stuff.
If someone has ever written any code is well aware of what can be done in a weekend and especially that no one doing something "in a weekend" will ever add all those useless comments everywhere, literally a few thousand lines of comments. That takes more time than writing code. Comments in Claude style. Other claude-isms all around.
It's ok to vibe things, but just say so, no shame.
And yes, after 5 minutes of looking around I had enough evidence to "prove it". Any moderately competent engineer could.
On my way to make a Dexter meme on this
When you think OP vibe-coded the project but can’t prove it yet
https://x.com/FG_Artist/status/1974267168855392371
OH YES! I Love it/this meme lol!!
Dexter's memes have been popping up recently and I am loving them
I don't know who bay harbor butcher is though :sob: but I don't want spoilers, I will watch it completely some day
My friend says that he watched complete dexter just via clips lol.
ohh boy, second this :D
Another possible tell (not saying this is vibe coded) is when every function is documented, almost too much comments
Ohh, I thought that inline comments would make it grokkable and be a low-friction way in. Seems this didn’t land the way I intended :'
Should a multi-part blog would've been better?
I like it, I comment exactly like you do. Comments are free, storage is plentiful, why not add comments everywhere?!
2 replies →
Can't you just say that you used Claude and be done with it? I mean, I don't really care but in general I would refrain from posting "Show HN" with stuff that has been vibed, or state that you did since in that case it's even more interesting from my point of view, like you could describe how you kept everything under control during generation, etc...
I mean, no biggie and I don't understand the reaction but hey, I'm old so...
1 reply →
I put Overview section from the Readme into an AI content detector and it says 92% AI. Some comment blocks inside codebase are rated as 100% AI generated.
Claude: "You're absolutely right" :D
> comment blocks inside codebase
Is vibe-commented a thing yet? :D
Wanted to give fellow readers a good on-ramp for understanding the FTS internals. Figured leaning into readability wouldn’t hurt
For me this makes the structure super easy to grok at a glance
https://github.com/wizenheimer/blaze/blob/27d6f9b3cd228f5865...
That said, totally fair read on the comments. Curious if they helped/landed the way I intended. or if a multi-part blog series would’ve worked better :)
Thanks for the link, very interesting data structure.
I'm wondering is it really worth dumping a general knowledge articles into code comments? To me it feels like the wrong place. Would just the wikipedia link be enough here?
I also notice a lot of comments like this
Is it really necessary to have a text description for a code like "a == b"? It would be really annoying to update comment section on every code change.
This is one of the typical issues when AI creates "code comments", because it always describes "What" is happening. A good comment should answer the question "Why" instead.
For the linked skip list module, a good comment could say why skip list was chosen over b-tree or other data structure and which trade offs were made. AI will never know that.
What makes you think so?
I wonder if I should really explain or if that would provide a list of things to sanitize before publishing stuff.
If someone has ever written any code is well aware of what can be done in a weekend and especially that no one doing something "in a weekend" will ever add all those useless comments everywhere, literally a few thousand lines of comments. That takes more time than writing code. Comments in Claude style. Other claude-isms all around.
It's ok to vibe things, but just say so, no shame.
And yes, after 5 minutes of looking around I had enough evidence to "prove it". Any moderately competent engineer could.
Probably the commit history.
Yayiee, the “cant prove it” Doakes Dexter meme, making it to HN
2 replies →