Post #733214

2026-03-22 21:41 UTC

As the number of LLM-generated patches in my inbox increases, I am starting to experience the sort of maintainer stress that has long been predicted. But there&#39;s another aspect of this that has recently crossed my mind. Just over a week ago, a new personality showed up with a whole pile of machine-generated patches claiming to fill in our memory-management documentation. A few reviewers had some sharp questions, the response to which has been ... silence. This person doesn&#39;t seem to have cared enough about that work to make an effort to get past the initial resistance. Once upon a time, somebody who had produced many pages of MM documentation would be invested enough in that work to make at least a minimal attempt to defend it. Kernel developers often worry that a patch submitter will not stick around to maintain the code they are trying to push upstream. Part of the gauntlet of getting kernel patches accepted can be seen as a sort of &quot;are you serious?&quot; test. When somebody submits a big pile of machine-generated code, though, will they be *able* to maintain it? And will they be sufficiently invested in this code, which they didn&#39;t write and probably don&#39;t understand, to stick around and fix the inevitable problems that will arise? I rather fear not, and that does not bode well for the long-term maintainability of our software.

Replies (17)

@jani@floss.social 2026-03-22 21:54

@corbet It will be interesting to see how the use of the Assisted-by tag develops. I'm sure not everyone uses it. And if it changes the reception of a patch to be negative, surely people will be less forthcoming about LLM usage too. And, of course, a contribution based on a lie is not a great way to build trust either. I also see trivial patches with Assisted-by that make me think, why? Couldn't you have done this yourself and learned something in the process.

Open ##1059091
@WesternInfidels@mefi.social 2026-03-22 21:59

@corbet It could be one more facet of our looming neo-feudal moment. Bespoke, tested code for the elites, slop-upon-slop code for the peasants. I suppose some people will surely turn to LLMs to help navigate the social "are you serious" gauntlet.

Open ##1059092
@ydroneaud@mastodon.ouvaton.coop 2026-03-22 22:20

@corbet yes, it raises new questions, like, what happen when they will ran out of tokens.

Open ##1059093
@EricCarroll@cosocial.ca 2026-03-22 22:57

@corbet PR submitter blacklists are coming, if not here already.

Open ##1059094
@dalias@hachyderm.io 2026-03-22 23:13

@corbet Can we stop using the propaganda language "machine-generated code" for this? It's copyright-laundered code of unknown origin.

Open ##1059095
@markd@hachyderm.io 2026-03-23 00:54

@corbet "Unwilling to defend" is a good test for the motivation of the submitter. And, unfortunately, motivation is a good test of the cost of accepting the submission. If the motivation is self-aggrandisement (aka boosting your brand) then you know you are inheriting instant technical debt.

Open ##1059097
@slotos@toot.community 2026-03-23 03:26

@corbet In my eyes, this is just a continuation of an older trend of submitting patches with no maintainability consideration. I’ve seen it many times: a discussion of a feature is underway, someone creates a patch with no tests and barely implemented happy path, someone else asks a few month later why it’s not merged… It’s automated now.

Open ##1059100
@mahadevank@mastodon.social 2026-03-23 03:50

@corbet sounds like you should use an LLM to generate an initial response to any PR, and then gauge if there's investment on the other side. Another option - simply refuse to review large PRs.

Open ##1059102
@pizzaclick@hachyderm.io 2026-03-23 07:28

@corbet Thank you. This puts well into words one of my main concerns about LLM-generated or assisted code or documentation.

Open ##1059103
@hopeless@mas.to 2026-03-23 07:29

@corbet The kernel is kind of unique though in that it can offer life-changing opportunities to contributors. The vast bulk of other FOSS projects can't. The idea that contributors will stick around or take responsibility for maintaining their work is meaningless. For these less mighty projects, contributors are entirely drive-by and it only happens during the short window the project is on their radar. The project maintainer has to take on responsibility for whatever was offered, AI or not.

Open ##1059104
@peteriskrisjanis@toot.lv 2026-03-23 07:59

@corbet I remember in my FOSS past failure to communicate was show stopper. As you say, you need someone responsible. I personally treat everyone not doing their own code not responsible. I don't care what you do to get started, but own it. Simple as that.

Open ##1059105
@ljs@mastodonapp.uk 2026-03-23 13:27

@corbet I fear the precedent accepting this kind of thing will establish. Not only in terms of asymmetric levels of AI slop vs. maintainer resource, but also concerns around social engineering from bad actors (not this doc patch but other recent, clearly AI, series). Sadly mm is being run in a very chaotic fashion where, without pushback from sub-maintainers, we would just take this kind of thing. It's very tiring to have to constantly be on alert for that, and I hope at some point the culture will change and we can move away from default-take-everything mode. Another issue here is that it's often hard to really call out AI even if it really seems like it - if somebody denies it, you don't want it to turn into a witch trial. As always, many social issues at play :)

Open ##1059107
@themipper@mastodon.social 2026-03-23 13:46

@corbet this is the core problem with LLM generated anything. There is no personal or emotional bond with the generated output. I love to code and learn from my mistakes. I am highly invested. I cannot imagine anyone using LLMs doing or feeling the same.

Open ##1059109
@perigee@rage.love 2026-03-23 16:45

@corbet @untitaker I moderate a fading Discord server with almost 2,000 members but only a handful of active chatters. The server is anti-LLM-based-AI, anti-cryptocurrency. In late 2025 we published a couple of data centric apps and then things petered out. But every couple of weeks or months someone shows up to promote a new framework for our "funding problem" since we are entirely volunteer run, and not a nonprofit. And it is almost always a framework obviously created in "AI". It has the pattern of deluging us with new concepts and buzzwords. And almost always relies on some blockchain implementation to "handle" funding in a money laundering sense. So we do the due diligence, ask clarifying questions, and after 0-1 rounds they ghost us. Every single time. They lose interest or find the challenge of answering pointed questions insurmountable or their pet AI's memory runs out. It's turning into a meme. I agree. Kick them out. They and their temporary machines won't be able to maintain the effort.

Open ##1059110
@jef@mastodon.social 2026-03-23 20:36

@corbet I'm seeing the opposite, sort of. I get an LLM-generated patch, send back a response questioning whether the code they're changing even appears in my package, and then get a response full of "Oh, you're right, I'm an idiot and thank you for pointing this out" stuff that LLMs spew when you correct them. The whole thing is nauseating.

Open ##1059111
@inthehands@hachyderm.io 2026-03-23 20:37

@corbet @lisihocke Gatekeeping in its assorted forms does some very good things and some very bad things, and I feel like we are eliminating exactly the wrong ones.

Open ##1059112
@mirth@mastodon.sdf.org 2026-03-23 21:33

@corbet I think only accepting large changes from users with a track record of smaller contributions is probably good policy regardless of how they are generated. In my own contributions I usually only add small features or bug fixes that don't incur maintenance overhead, knowing in advance that I'm not able to provide reliable support after the fact. Conversely if it's something nobody else will care about or contributions are too much work I fork and live with old code.

Open ##1059113