If the code is obvious crap, it doesn’t matter if AI was involved. If the code is perfectly obviously fine, it doesn’t (directly) matter if AI was involved.
In the grey area in between, if someone doesn’t say AI was involved it might mean AI was used undisclosed to vibe code the result from beginning to end. If someone said AI was involved, it might mean AI was used solely to speed up testing to track down the cause of the bug. In the former case, you’ll get nothing useful out of the submitter; in the latter case the submitter can engage usefully in pushback on their proposed flawed fix. In neither case did the AI disclosure (or lack thereof) actually help.
And that’s more or less where this news comes from - the tool usage disclosure turned out to not be useful, partly due to the vagueness of the method of disclosure (a tag in the commit message), partly due to people not reliably following the requirement, so they decided to stop requiring it.
I’m not going to start using AI voluntarily any time soon, but I’m also not going to start panicking that the kernel is suddenly completely turned into vibe coded AI slop like so many crazy people seem to have been doing lately.
honestly the code should be stood behind by the developer. then it won’t matter.
and by stood behind, i mean responsible for the outcome as if they wrote it, able to explain exactly what the code does, how it does it. and have been reviewed before deployment. often times that takes longer then just coding it yourself
you can’t use ai as a scape goat when the code does not work.
Exactly. While I do have issues with the ethical and environmental aspects of AI, I do believe that many of the criticisms are disingenuous. Some made me wonder if the one criticizing never worked in a real dev project and just parroting
Bad developer have been copy pasting from stack overflow, writing slop, not following documentation/standards for years. This will never go away.
AI can do amazing good stuff, keeping the exit criterias checked, act as a second opinion, verifying upstreams and helping building a good prototype. making harnesses, hell even find a forgotten RAII pointer or concurrency.
But it can also lead to making gibberish that no one understands, mess up with productivity factor (if someone do code fast, why dont you??) and many other issue.
I think its all about approaching how we can gatekeep the bad code, instead of trying to pin how it was made.
Exactly, that’s the only rational way to look at it. The person submitting the code is responsible for it. Period. How they went about producing it is their own business, but they are the one who takes ownership of the result.
If the code is obvious crap, it doesn’t matter if AI was involved. If the code is perfectly obviously fine, it doesn’t (directly) matter if AI was involved.
In the grey area in between, if someone doesn’t say AI was involved it might mean AI was used undisclosed to vibe code the result from beginning to end. If someone said AI was involved, it might mean AI was used solely to speed up testing to track down the cause of the bug. In the former case, you’ll get nothing useful out of the submitter; in the latter case the submitter can engage usefully in pushback on their proposed flawed fix. In neither case did the AI disclosure (or lack thereof) actually help.
And that’s more or less where this news comes from - the tool usage disclosure turned out to not be useful, partly due to the vagueness of the method of disclosure (a tag in the commit message), partly due to people not reliably following the requirement, so they decided to stop requiring it.
I’m not going to start using AI voluntarily any time soon, but I’m also not going to start panicking that the kernel is suddenly completely turned into vibe coded AI slop like so many crazy people seem to have been doing lately.
honestly the code should be stood behind by the developer. then it won’t matter. and by stood behind, i mean responsible for the outcome as if they wrote it, able to explain exactly what the code does, how it does it. and have been reviewed before deployment. often times that takes longer then just coding it yourself
you can’t use ai as a scape goat when the code does not work.
Exactly. While I do have issues with the ethical and environmental aspects of AI, I do believe that many of the criticisms are disingenuous. Some made me wonder if the one criticizing never worked in a real dev project and just parroting
Bad developer have been copy pasting from stack overflow, writing slop, not following documentation/standards for years. This will never go away.
AI can do amazing good stuff, keeping the exit criterias checked, act as a second opinion, verifying upstreams and helping building a good prototype. making harnesses, hell even find a forgotten RAII pointer or concurrency.
But it can also lead to making gibberish that no one understands, mess up with productivity factor (if someone do code fast, why dont you??) and many other issue.
I think its all about approaching how we can gatekeep the bad code, instead of trying to pin how it was made.
Exactly, that’s the only rational way to look at it. The person submitting the code is responsible for it. Period. How they went about producing it is their own business, but they are the one who takes ownership of the result.
Holy fucking shit… rational conversations when talking about AI tool usage on Lemmy? WTF?!
it is rare 🤣