Post by @KeithD@lemmy.nz

2026-10-16 11:55 UTC

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.

Replies (2)

@WraithGear@lemmy.world 2026-10-16 12:29

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.

Open ##5061267
@cyclohexane@lemmy.ml 2026-10-18 19:39

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. Determining quantity of code is very difficult and expensive. It is often that issues with code don’t surface until certain patterns of usage. This is why judging code quality by judging the author’s track record, or the track record of their tools, is very valuable. If you’re vibe coding anything non trivial, your code is gonna be terrible. There’s no sugar coating it. There’s a wealth of examples on the internet that prove it. It’s a waste of time spending any effort evaluating it when we have this evidence, and especially when they didn’t spend reasonable effort shipping the code.

Open ##5116781