I've been spending rather too much of my time reading the depressing threads on LLM use in the kernel. But I thought that this contribution from Lyude Paul worth the investment.

"For many people who need their jobs, guidelines around acceptable use of these tools beyond "a person needs to own the the code" may end up being the only thing allowing employees to be responsible with their contributions without repercussion from employers."

https://lwn.net/ml/all/3a5d891b536588e8e4fc84d60a5c8af72091d852.camel@redhat.com

@corbet Thanks for sharing this. This is definitely one of the more reasonable things I've read about this topic. 😔

@corbet This sounds like bullshit to me. If someone's employer wants them to work on an outside open source project, then the project (Linux kernel, here) holds all the leverage.

It's not forcing the employee to push back against slop tools where it might have workplace repercussions on them. It's giving them a third party to blame for the pushback.

@corbet I suspect this landscape will change once the full cost is borne by the user. Personally speaking, I just upgraded from $20 to $200/month Claude to keep access to Fable, but even that is changing soon to an insert-coin model on top of the subscription. And their IPO docs apparently talk about profitability by some time in the 2030s. Interesting times.

@dalias @corbet I'm not sure I understand your point correctly, but isn't that project leverage exactly what Lyude argues for?

@vbabka @corbet Maybe I misread it, but I thought it was saying that banning slop contributions might put employees directed to work on the kernel in a precarious position of having to tell their bosses no.

If the point was the same as mine, that it gives them someone else to blame for the no so they don't have to take the blame themselves, then fine.

@dalias @corbet yeah I think it was the same point as yours

@corbet part of QEMU's initial "no-AI" policy was because there was a concern about engineers being forced to "vibe code" their upstream contributions. We are in the process of reviewing the policy and trying to work our way to similar "own the code" language as well as discourage places where LLM's typically fail such as making changes across sub-systems to achieve something. The "small bug fixes" 20 lines or less heuristic is suboptimal though: https://patchew.org/QEMU/20260529094619.1034458-1-pbonzini@redhat.com/

@stsquad @corbet You mean discourage for changes across subsystems such as https://patchew.org/QEMU/20260711223707.42139-1-graf@amazon.com/? 😁

What AI works with depends heavily on model, context window and general steering (subagents and self-reviews are a must!). I am not convinced that anything we write down as rule of where it works well vs badly today will hold for long.

@Lyude @corbet I'm not sure where you get the idea that the kerne is a bunch of people paid by employers to do review of amateur contributions, and somehow there will be too many contributions and too few reviewers without them.

It's the corporations pushing the flood of bad contributions, and the volunteers and overworked maintainers who are doing that on the side, in addition to their paid job, who are stuck with review.

Less people getting paid to push garbage patches at Linux is good for Linux and for the maintainers.

@Lyude @corbet I'm not sure why you think I want to have a conversation with someone whose priority seems to be the employment of people getting paid to make our commons worse.

@Lyude @corbet Especially when it's a conversation you keep setting to followers-only so it breaks continuity for anyone else trying to read and makes my replies meaningless and out-of-context.

If I'm going to discuss these things, I want to be doing it in a public venue where any of my followers can follow, not in a half-private context where I'm wasting my time just talking to someone who's likely just pushing a pro-AI agenda.

@agraf well I did say it was sub-optimal ;-)

I think your series is a good example of where LLM's can work across large sections of the code because it's basically being used like #coccinelle on steroids. The individual changes are simple and fairly mechanical and good grounding stops the LLM going off the rails. However I have less confidence in LLMs when they need to make discreet changes across the code base to support more complex behaviour. That's when I see them get confused.

@corbet

@stsquad @corbet Do you have an example that failed for you (including details on what failed), so I can give it a try? 😁

@agraf the only serious experiment I did so far was https://patchew.org/QEMU/20260224121014.279248-1-alex.bennee@linaro.org/ which missed a bunch of the edge cases, smooshed together concepts like cpu_has_work() and generally failed to make clean atomic changes. There are some similarities with the final human patches that got merged but it was a lot more steps. @corbet