This is a very informative article, a good starting point to understand the complexities and nuances of integrating these tools into large software projects.
As one commenter notes, we seem to be heading towards a “don't ask, don't tell policy”. I do find that unfortunate, because there is great potential in sharing solutions and ideas more broadly among experienced developers.
> The copyright status of LLM-generated code is of concern to many developers; if LLM-generated code ends up being subject to somebody's copyright claim, accepting it into the kernel could set the project up for a future SCO-lawsuit scenario.
There is no reason why I can't sue every single developer to ever use an LLM and publish and/or distribute that code for AGPLv3 violations. They cannot prove to the court that their model did not use AGPLv3 code, as they did not make the model. I can also, independently, sue the creator of the model, for any model that was made outside of China.
No wonder the model makers don't want to disclose who they pirated content from.
I used Claude Code to review a kernel driver patch last week. If found an issue that was staring me in the face, indeed one I would’ve expected the compiler to flag.
This is a great article in discussing the pros / cons in adopting LLM-generated patches in critical projects such as the kernel. Even some of the comments give their nuanced observations on this, for exammple the top comment gives an accurate assessment of the strengths and limitations of LLMs perfectly:
> LLMs are particularly effective for language-related tasks - obviously. For example, they can proof-read text, generate high-quality commit messages, or at least provide solid drafts.
> LLMs are not so strong for programming, especially when it comes to creating something totally new. They usually need very limited and specific context to work well.
The big takeaway is regardless of whoever generated the code: "...it is the human behind the patch who will ultimately be responsible for its contents." which implies they need* to understand what the code does with no regressions introduced.
This is a very informative article, a good starting point to understand the complexities and nuances of integrating these tools into large software projects.
As one commenter notes, we seem to be heading towards a “don't ask, don't tell policy”. I do find that unfortunate, because there is great potential in sharing solutions and ideas more broadly among experienced developers.
> The copyright status of LLM-generated code is of concern to many developers; if LLM-generated code ends up being subject to somebody's copyright claim, accepting it into the kernel could set the project up for a future SCO-lawsuit scenario.
Ain't that anticipatory obedience?
Yes, but two fold.
There is no reason why I can't sue every single developer to ever use an LLM and publish and/or distribute that code for AGPLv3 violations. They cannot prove to the court that their model did not use AGPLv3 code, as they did not make the model. I can also, independently, sue the creator of the model, for any model that was made outside of China.
No wonder the model makers don't want to disclose who they pirated content from.
Isn't it up to you to prove the model used AGPLv3 code, target then for them to prove they didn't?
I used Claude Code to review a kernel driver patch last week. If found an issue that was staring me in the face, indeed one I would’ve expected the compiler to flag.
Link to the patch and details on the issue the compiler missed that was found by the model or it didn't happened.
Sure. It was an uninitialized variable in the retry loop below. Fixed now.
https://github.com/PADL/linux/commit/b83b9619eecc02c5e95a1d3...
There's no such thing being fixed in those diffs
I think it contains the bug (nin_attempts), not the fix.
This is a great article in discussing the pros / cons in adopting LLM-generated patches in critical projects such as the kernel. Even some of the comments give their nuanced observations on this, for exammple the top comment gives an accurate assessment of the strengths and limitations of LLMs perfectly:
> LLMs are particularly effective for language-related tasks - obviously. For example, they can proof-read text, generate high-quality commit messages, or at least provide solid drafts.
> LLMs are not so strong for programming, especially when it comes to creating something totally new. They usually need very limited and specific context to work well.
The big takeaway is regardless of whoever generated the code: "...it is the human behind the patch who will ultimately be responsible for its contents." which implies they need* to understand what the code does with no regressions introduced.