The title is pure clickbait, but the article is nuanced and reasonably well written, IMO.
No one wants a freaking Ubuntu chatbot on their desktop, but code submission is an entirely different issue, and I think “the submitter is entirely responsible for their code” is a very reasonable position.
And obviously, LLM-generated code policy needs to be tuned to each project and their contributor community. As an example not cited in the article, vibe-coded PRs are an ongoing plague for llama.cpp, an LLM inference engine itself, so they blanket ban them. Ironic, and perfectly reasonable. But Linus researching that Intel bug with a little help, but using his brain for the legwork and actual submission, is also reasonable.
I think “the submitter is entirely responsible for their code” is a very reasonable position.
Especially since I just don’t see how it’s possible to fully prevent people from using AI if they want to use it. Yes a lot of code might be more obvious and could be rejected with an “absolutely no AI policy” but some people will submit perfectly good code where AI was involved in some way.
Plus if the general requirement is ‘high quality code’ then that automatically excludes the majority of LLM usage where people just vibe code it and rely heavily on the LLM to do the work. VS someone writing their own code while using an LLM to help find problems.
Well… IMO, there’s a whole spectrum between “very rare LLM brianstorming/troubleshooting” and “I don’t know how to code” vibe-coding, and Im not sure what the distribution looks like.
Personally, I get LLMs to generate boilerplate, formatting, and functions, but manually write plenty and audit/assemble all the pieces myself. But I would not call myself a vibecoder; I loathe vibe coding.
Yeah I often tell a local LLM to find problems with my code before I submit it. It’s essentially a round 0 reviewer, trained on previous (human) reviews of the same project.
The title is pure clickbait, but the article is nuanced and reasonably well written, IMO.
No one wants a freaking Ubuntu chatbot on their desktop, but code submission is an entirely different issue, and I think “the submitter is entirely responsible for their code” is a very reasonable position.
And obviously, LLM-generated code policy needs to be tuned to each project and their contributor community. As an example not cited in the article, vibe-coded PRs are an ongoing plague for llama.cpp, an LLM inference engine itself, so they blanket ban them. Ironic, and perfectly reasonable. But Linus researching that Intel bug with a little help, but using his brain for the legwork and actual submission, is also reasonable.
Especially since I just don’t see how it’s possible to fully prevent people from using AI if they want to use it. Yes a lot of code might be more obvious and could be rejected with an “absolutely no AI policy” but some people will submit perfectly good code where AI was involved in some way.
Yes, that too.
Incentivizing hiding LLM use would be a problem. Encouraging disclosure is good.
Plus if the general requirement is ‘high quality code’ then that automatically excludes the majority of LLM usage where people just vibe code it and rely heavily on the LLM to do the work. VS someone writing their own code while using an LLM to help find problems.
Well… IMO, there’s a whole spectrum between “very rare LLM brianstorming/troubleshooting” and “I don’t know how to code” vibe-coding, and Im not sure what the distribution looks like.
Personally, I get LLMs to generate boilerplate, formatting, and functions, but manually write plenty and audit/assemble all the pieces myself. But I would not call myself a vibecoder; I loathe vibe coding.
Yeah I often tell a local LLM to find problems with my code before I submit it. It’s essentially a round 0 reviewer, trained on previous (human) reviews of the same project.