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.

> 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?

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.

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.