The value of any given contribution is the same, regardless of whether the code was written by a seasoned developer, a neophyte as a first project, an LLM, a team of high school students learning the language, or space aliens - the code is the code, it helps or hurts exactly the same when merged with zero connection to who or what wrote it.
Caring about who or what wrote the code is applying prejudice. Prejudice works well in a lot of cases, but it’s no guarantee.
If you are accepting submissions from anonymous, or insecurely identified (same thing, really), contributors, they should all be treated with zero prejudice. You might think you know who or what wrote the code based on the name in the linked e-mail address, the way comments are (or aren’t) written, or a million other “tells” in the code that aren’t about the function of the code - that’s really irrlelevant. What’s relevant is: what does the code actually do after it’s merged.
If you’re trusting code because you think its “tells” track with seasoned developers, be prepared - very very soon - for maliciously crafted code full of “seasoned developer” tells to slip in backdoors and other malware, because bad actors are already using AI to mimic the things you want to see in a submission in order to gain your trust and lower your guard against them slipping in the things they want in your code base.
You’re right. It’s not about the code though, it’s about the interaction with the individual submitting the code. It is natural for humans to want to use language that is meant for communication between humans to actually reach humans.
The value of any given contribution is the same, regardless of whether the code was written by a seasoned developer, a neophyte as a first project, an LLM, a team of high school students learning the language, or space aliens - the code is the code, it helps or hurts exactly the same when merged with zero connection to who or what wrote it.
Caring about who or what wrote the code is applying prejudice. Prejudice works well in a lot of cases, but it’s no guarantee.
the blog post is not about who actually wrote the code, but whether it’s worth the effort to do a thorough review. if an actual person made it, then yes because they can learn from it and the world becomes a slightly better place. if it was a vibecoder just using an LLM, then explaining what needs to be done and why does not add much to.the world, but it possibly helps to make the LLM company richer
whether it’s worth the effort to do a thorough review.
If the vibe coder learns how to vibe better…
I’ve been using LLMs for a lot of things since last October, the models have improved pretty dramatically since then, but so have my skills in using them - so it’s hard to tell (and probably unimportant) which factor is more important in the increased quality and efficiency of my code production and reviews over the last year.
Using LLMs to review code (regardless of who/what wrote it) is a more efficient way to improving code quality, security, maintainability, etc. than just reading it all yourself. Certainly don’t go blindly trusting the LLM reviews, but if you haven’t tried them for pull request review, you should…
The value of any given contribution is the same, regardless of whether the code was written by a seasoned developer, a neophyte as a first project, an LLM, a team of high school students learning the language, or space aliens - the code is the code, it helps or hurts exactly the same when merged with zero connection to who or what wrote it.
Caring about who or what wrote the code is applying prejudice. Prejudice works well in a lot of cases, but it’s no guarantee.
If you are accepting submissions from anonymous, or insecurely identified (same thing, really), contributors, they should all be treated with zero prejudice. You might think you know who or what wrote the code based on the name in the linked e-mail address, the way comments are (or aren’t) written, or a million other “tells” in the code that aren’t about the function of the code - that’s really irrlelevant. What’s relevant is: what does the code actually do after it’s merged.
If you’re trusting code because you think its “tells” track with seasoned developers, be prepared - very very soon - for maliciously crafted code full of “seasoned developer” tells to slip in backdoors and other malware, because bad actors are already using AI to mimic the things you want to see in a submission in order to gain your trust and lower your guard against them slipping in the things they want in your code base.
You’re right. It’s not about the code though, it’s about the interaction with the individual submitting the code. It is natural for humans to want to use language that is meant for communication between humans to actually reach humans.
the blog post is not about who actually wrote the code, but whether it’s worth the effort to do a thorough review. if an actual person made it, then yes because they can learn from it and the world becomes a slightly better place. if it was a vibecoder just using an LLM, then explaining what needs to be done and why does not add much to.the world, but it possibly helps to make the LLM company richer
If the vibe coder learns how to vibe better…
I’ve been using LLMs for a lot of things since last October, the models have improved pretty dramatically since then, but so have my skills in using them - so it’s hard to tell (and probably unimportant) which factor is more important in the increased quality and efficiency of my code production and reviews over the last year.
Using LLMs to review code (regardless of who/what wrote it) is a more efficient way to improving code quality, security, maintainability, etc. than just reading it all yourself. Certainly don’t go blindly trusting the LLM reviews, but if you haven’t tried them for pull request review, you should…