The Software Freedom Conservancy's LLM-backed generative AI recommendations [LWN.net]

The Software Freedom Conservancy (SFC) has announced the release of its recommendations for using LLM-backed generative AI systems for FOSS contributions. The recommendations were created by the SFC and volunteers from the free-software community.

The recommendations reflect the extremely difficult dilemmas that these systems pose for FOSS contributors. SFC and its volunteers understand that FOSS developers are approaching LLM-gen-AI from a variety of perspectives. The recommendations offer practical assistance to minimize the damage caused by using proprietary systems, whether FOSS contributors reject LLM-gen-AI or choose (voluntarily or by employer mandate) to use them.

These recommendations are best practices (but not definitions or requirements) that SFC and its volunteers formulated after careful study of the growing LLM-gen-AI use among FOSS contributors. SFC will follow these recommendations with a series of supporting materials, including documents, online tutorials, public Q&As, podcasts, and other community engagement. We will routinely refine our recommendations and continue to support FOSS contributors as they navigate this difficult landscape.

to post comments

Time saving cannot go one way only

Posted Jun 18, 2026 19:11 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (4 responses)

> Before submission, FOSS Contributors must invest substantial time reviewing LLM-gen-AI -assisted and/or -generated contributions. Such contributions need curation. Contributors should acquire an in-depth understanding of their contribution.

This is really important from a non-technical point of view. I have no problems with you deciding to save time by using an LLM; but I expect you to invest a comparable amount of time in understanding and polishing your submission.

If the time saving only goes one way, or in fact I have to spend more time pointing out ways in which the submitted code does not follow the standards of the project you're contributing to, that is disrespectful towards the maintainers and you can't expect me to like your work.

Time saving cannot go one way only

Posted Jun 19, 2026 12:40 UTC (Fri) by alx.manpages (subscriber, #145117) [Link] (3 responses)

> I have no problems with you deciding to save time by using an LLM; but I expect you to invest a comparable amount of time in understanding and polishing your submission.

If we take Kernighan's quote:

> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

-- Brian Kernighan, 1974

Can anyone really benefit from using an LLM? I expect either the user doesn't do enough debugging work (and thus quality goes down, or the burden is moved to the maintainer as you say), or that it spends twice as much time as it did before LLMs (and quality remains more or less constant).

Time saving cannot go one way only

Posted Jun 20, 2026 4:26 UTC (Sat) by pbonzini (subscriber, #60935) [Link] (2 responses)

First, you are assuming the usage of LLMs for the cleverest code in the submission. You can get help from writing boilerplate code or testcases, for example.

Second, code review is not debugging. Code review can take as much as you want, unlike debugging which finishes when the root cause is found, and you would do code review on your code anyway even if not written by an LLM. (And dually, you can have an LLM do code review).

You can also get help in the design phase and then implement it yourself.

So, depending on the problem, you can gain time, you can gain quality, or neither.

Time saving cannot go one way only

Posted Jun 20, 2026 9:42 UTC (Sat) by LtWorf (subscriber, #124958) [Link] (1 responses)

We should really stop thinking that writing tests is easy. It's not.

Having many tests that all test the same thing is completely pointless. We need good tests, not many tests.

I have personally seen AI written test that was assigning a variable to 1, never re-assigning it and then testing in several places that the variable was still 1. And no, it was not a test to check if the CPU and RAM are working.

Write good tests instead of committing thousands of lines of useless asserts.

Time saving cannot go one way only

Posted Jun 20, 2026 10:46 UTC (Sat) by pbonzini (subscriber, #60935) [Link]

I didn't say it's easy, I said it's usually not the most clever code.

Details of disclosure

Posted Jun 18, 2026 20:12 UTC (Thu) by mvollrath (subscriber, #183387) [Link] (42 responses)

> Full disclosure of how and when an LLM-gen-AI system was utilized to assist in creation of a contribution is a moral imperative.

I feel like the kernel LLM guidelines mandate disclosure of "when", but lack details about the "how". Tagging the LLM more specifically could help to bridge this gap. For example, when a real person helps you with suggesting, reviewing, or testing a commit, you don't use a one-size-fits-all Assisted-by tag. LLM contributions can be any of these activities, not just implementation.

Details of disclosure

Posted Jun 18, 2026 23:16 UTC (Thu) by kiko (subscriber, #69905) [Link] (41 responses)

I am conflicted on this specific recommendation. Details on when and how an LLM was used to write a contribution is technically useful information, but I would prefer to avoid advertising for the LLM provider in open source code — even if its in metadata. Am curious what others make of this.

Details of disclosure

Posted Jun 19, 2026 2:30 UTC (Fri) by collinfunk (subscriber, #169873) [Link] (9 responses)

Some people on the glibc mailing list proposed using "Assisted-by" tag with the model name on patches. Their argument is meritorious, i.e., we want transparency from contributors. But others, including myself, mentioned our dislike of including information that might be interpreted as an advertisement.

Details of disclosure

Posted Jun 19, 2026 4:43 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (5 responses)

We have maintained a distinction between attribution and advertisement for decades. The 3-clause BSD license mandates it (as does, for that matter, the original 4-clause BSD license). Merely naming the source of something is not an ad, and has never been an ad.

Details of disclosure

Posted Jun 19, 2026 5:06 UTC (Fri) by ssmith32 (subscriber, #72404) [Link] (1 responses)

Subtly inserting the name of a product in a context meant to convey an authentic recommendation is pretty much the oldest advertisement form in the book.

I'm not sure where and when this distinction is documented, and in what context, but ... I think you might be being a _bit_ overly broad with your use of "we" in your comment.

The BSD license is not a product, an AI-assistant that you pay a private company to use most definitely is.

One of the main distinctions between attribution and advertisement is *what* is being recommended and *why*.

It has very little to do with *how*.

Details of disclosure

Posted Jun 19, 2026 5:32 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

> The BSD license is not a product,

I do not understand how you could possibly misinterpret my comment that grossly.

The 3-clause BSD license requires you to attribute the source of your code, but simultaneously bans you from using this attribution to imply endorsement. The 4-clause BSD license additionally requires you to advertise the creator, while still banning you from implying endorsement. These are thus recognized as three separate things (attribution, endorsement, advertisement). Since the 4-clause license first appeared in 1990, this distinction has existed, uncontroversially, for over three decades. When the advertisement requirement was removed, the attribution requirement was kept, and nobody had a problem with that either, because we all understood that advertisement and attribution are not the same thing.

I will admit that there is an important difference between giving attribution to a human and giving attribution to a machine. It is not reasonable, for example, for the LLM companies to demand attribution from their users. But I think it is entirely reasonable for a FOSS project, after due consideration, to decide that transparency outweighs other concerns, and require LLM attribution for all LLM-assisted contributions.

Details of disclosure

Posted Jun 19, 2026 5:11 UTC (Fri) by collinfunk (subscriber, #169873) [Link] (2 responses)

I am not sure if I understand your point. Licenses are a legal instruments. They don't control how someone interprets text, e.g., an "Assisted-by" tag.

Details of disclosure

Posted Jun 19, 2026 5:24 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (1 responses)

My point is that, if a project has a policy requiring Assisted-by, your options are to either provide the tag in the format requested, or do not use an LLM to contribute. You don't get to tell them how to manage their project.

Details of disclosure

Posted Jun 19, 2026 5:37 UTC (Fri) by collinfunk (subscriber, #169873) [Link]

Oh, I guess I should have been more clear that I am a glibc comitter and these opinions were shared when a policy was proposed. I was not trying to claim that my view was the only reasonable one, or that it should be unilaterally imposed on the project.

Details of disclosure

Posted Jun 19, 2026 6:02 UTC (Fri) by mvollrath (subscriber, #183387) [Link] (1 responses)

I'm curious about this. Do you personally use LLMs to assist with your commits and don't want to advertise the product you are using, or do you not want other contributors to have to advertise the product they are using? Or both?

Details of disclosure

Posted Jun 19, 2026 18:13 UTC (Fri) by collinfunk (subscriber, #169873) [Link]

I don't use LLMs for my commits, or really any other purpose for that matter. Assuming that another contributor uses an LLM in a way that does not jeopardize the copyrightability of their patch, I don't think the should be forced to specify the product used.

Details of disclosure

Posted Jun 19, 2026 23:29 UTC (Fri) by kiko (subscriber, #69905) [Link]

Coming back to reflect on this. Do you think the brand of the model being used is actually that relevant? And wouldn't we as a community prefer to be able to treat any of them as interchangeable? If that's the case, then perhaps we don't need to include the brand.

Including the brand of the model also opens a bit of a can of worms as there will be version strings, derivative versions, etc. Maybe we want to sidestep that whole mess and just indicate in a binary manner whether an LLM was used to generate any of the code being submitted.

Details of disclosure

Posted Jun 19, 2026 7:00 UTC (Fri) by mvollrath (subscriber, #183387) [Link] (13 responses)

In this article and otherwise, I see it taken for granted that knowing which commits are LLM is technically valid information, but I don't think I've seen maintainers weigh in on how it is useful. Most of what I've read from maintainers is about why they are banning LLM entirely. For those still on the fence, how is it useful?

Details of disclosure

Posted Jun 19, 2026 9:10 UTC (Fri) by IanKelling (subscriber, #89418) [Link] (12 responses)

Are you a human or a bot? Can you see why that might be useful information? Seems obvious to me.

Details of disclosure

Posted Jun 19, 2026 15:01 UTC (Fri) by mvollrath (subscriber, #183387) [Link]

If one were to follow the kernel's LLM guidelines, that's not the information being offered. If I do 90% of the work and the LLM does 10% of the work, I Sign-off Assisted-by the LLM. If the LLM does 100% of the work, I Sign-off Assisted-by the LLM. These are a world apart wrt judging confidence in both the committer and the commits. At face value, you're lumping somebody who took the time to use a /kreview skill to check their work at the end together with somebody who was entirely hands off and couldn't pass a quiz about their commit.

As someone who genuinely wants both to learn how to work on the kernel and to use LLM tools responsibly, I don't want to look like a bot at a glance. Meanwhile the actual bots can just lie. So I don't think it's that obvious. If the policy is "you have to voluntarily add this mark of shame if you used a particular type of tool" then it's not likely to benefit anyone in such an obvious way. As we can see in the comments here, developers have all kinds of moral agendas which may conflict with the imperatives of the maintainers they are working with. The SFC's attempt at an ethical treatise is apparently not yet the final word.

And I don't want to dismiss the very real moral and ethical questions surrounding LLM technology and the way it is being rolled out. In our community the maintainers are the ones feeling the most pain, so I feel like the best course of action is to do whatever small change they ask me to do, for now, because my ethics bone tells me that these software projects continuing to be well-maintained is more important than hand wringing over mentioning the name of a company whose product I use while holding my nose.

From Corbet's 7.1 release statistics article:

> This release saw the merging of 15,849 non-merge changesets from 2,479 developers.

> The 7.1 cycle continued that trend [of first-time kernel contributors] with 530 new contributors [...]

> There are 299 commits in 7.1 that include an Assisted-by tag indicating the use of such a tool. The number of actual commits created with LLM involvement must be significantly higher, though; a number of developers are clearly not complying with the kernel's rules for disclosing that use.

Details of disclosure

Posted Jun 19, 2026 18:13 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

Should I put "Assisted-by: Whatever LanguageTool is using for spellchecking"? What is the threshold for the model help?

Details of disclosure

Posted Jun 22, 2026 9:57 UTC (Mon) by coriordan (guest, #7544) [Link] (9 responses)

This is a good question. I guess the answer is: no, but if you don't include any 'assisted-by' tag then you are asserting that the text or code is the fruit of your brain.

More importantly, I think the "assisted-by", or whatever tag, could contain something more useful than the name of the LLM. What tasks the LLM was used for, for example. "initial code generation" could be one, and some projects might think that's a great or a terrible idea. "checking my code after I wrote it" could be another, and even the anti-AI people might agree that that makes sense and that human-written code that is checked by an AI tool is better than human-written code that was not checked by an AI tool - or some projects might value the checking done by some tools but not others.

When I use LLMs to write a document, I sometimes keep a table with one LLM's suggetions in column 1, a second LLM's suggetions in column 2, my comments on picking or merging them in column 3 and then my own text in column 4. Maybe we should have standards and tools to document how code was written (and checked).

Details of disclosure

Posted Jun 22, 2026 14:51 UTC (Mon) by pbonzini (subscriber, #60935) [Link] (1 responses)

For QEMU it was floated to have an "AI-used-for" tag instead of Assisted-by.

Details of disclosure

Posted Jun 22, 2026 20:35 UTC (Mon) by coriordan (guest, #7544) [Link]

A step in the right direction. But it probably needs to be far more detailed than that.

And if knowing some detailed procedure becomes mandatory for contributing, then it would be nice if we had one standardised procedure for the FOSS ecosystem.

Details of disclosure

Posted Jun 22, 2026 22:17 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

Maybe we should standardize on AI levels, like we have for self-driving cars:

Level 0: no AI help whatsoever.
Level 1: minor AI help (autocomplete suggestions during code editing, spellchecking)
Level 2: some AI code generation, but everything is overseen and signed off by a human
Level 3: autonomous AI code generation, where a human provides inputs and only checks the final results
Level 4: completely autonomous AI design and generation

Details of disclosure

Posted Jun 22, 2026 22:18 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Oh yeah, and AI reviews probably fall under Level 2.

Details of disclosure

Posted Jun 23, 2026 9:04 UTC (Tue) by taladar (subscriber, #68407) [Link] (1 responses)

I really feel there is a fundamental difference though between generation and review. If your code does not contain a single line of AI generated code, just code you wrote based on AI reviews pointing out bugs, that is fundamentally different from AI writing your boilerplate. Or in other words, a single axis might not be enough here.

Details of disclosure

Posted Jun 23, 2026 17:11 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

I guess we can add another sublevel to Level 2? "AI for reviews but not code generation"?

Or maybe bikeshed another level?

Details of disclosure

Posted Jun 23, 2026 2:04 UTC (Tue) by cypherpunks2 (guest, #152408) [Link] (2 responses)

Level 2 would include everything from generating a little boilerplate, whipping up a tiny helper function, or adding the headers you need all the way to being used to generate the majority of the code with the human only helping when it gets confused. I think its scope is too broad to be useful.

I really like the idea though.

Details of disclosure

Posted Jul 28, 2026 22:17 UTC (Tue) by IanKelling (subscriber, #89418) [Link] (1 responses)

I think numbering things is the wrong approach. In general, and I don't see a reason for an exception here, if is important, it deserves a name.

Details of disclosure

Posted Jul 31, 2026 16:14 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Agreed. Not to mention that while the numbers themselves have order, they're not always applied as such. For example, first degree murder is worse than third degree, but you'd much rather have a first degree burn than a third degree burn (assuming you're being burned at all). Is "Level 2" stricter or looser than "Level 1" is not clear at all without knowing what they are already.

Details of disclosure

Posted Jun 19, 2026 7:18 UTC (Fri) by fenncruz (subscriber, #81417) [Link] (7 responses)

Do you remove company names from email addresses people commit with? If not, that's advertising. So why would an LLM name/provider be different to any other company/product name that ends up in a commit message/metadata.

Details of disclosure

Posted Jun 19, 2026 8:58 UTC (Fri) by taladar (subscriber, #68407) [Link]

That is actually a good argument. When it comes to contributions that deal with specific hardware devices and/or interoperability with specific software I am sure plenty of product names are going to be part of commit messages or code comments as well.

Details of disclosure

Posted Jun 19, 2026 11:13 UTC (Fri) by hailfinger (subscriber, #76962) [Link]

This depends. Yes, the email address of a committer and also the email address listed in Tested-by and Reviewed-by tags is some form of advertising.
However, I also remember Linux kernel patches being submitted with lines similar to
> This development was paid for by Company Foobar

This even caused a change in the contribution policy for the Linux kernel:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...
Quoting from that patch:
> The author may indicate their affiliation or the sponsor of the work
> by adding the name of an organization to the ``from`` and ``SoB`` lines,
> e.g.:
> From: Patch Author (Company) <author@example.com>

Details of disclosure

Posted Jun 20, 2026 12:21 UTC (Sat) by hsivonen (subscriber, #91034) [Link] (3 responses)

Metadata that results in the GitHub UI showing the icon/logo of the LLM in the sidebar of the repo is in practice advertising. Disclosing LLM use in free-form text of the commit communicates to the reviewer but does not cause the same kind of display effects in practice.

Details of disclosure

Posted Jun 20, 2026 13:56 UTC (Sat) by hmh (subscriber, #3838) [Link] (2 responses)

X-AI-Assisted: review, bug-hunt
X-AI-Assisted: vibe-coding

etc.

Would likely disclose in a machine-readable format what is really relevant. Nobody really cares *which* AI and mode you used, other than the AI companies themselves.

OTOH, if you could get a massive token-credit for use on FLOSS-only projects in exchange for actually disclosing which AI model helped you, *then* I can see a decent reason to mention which AI model was used (and there could be more than one).

Details of disclosure

Posted Jun 22, 2026 9:23 UTC (Mon) by taladar (subscriber, #68407) [Link] (1 responses)

Why do you think nobody cares? Both good results (e.g. seeing a task you know another model couldn't handle) and bad results (e.g. subtle bugs) could make that information useful. Frankly what nobody cares about is trying to split up tasks into coding and bug-hunt or similar splits.

Details of disclosure

Posted Jun 22, 2026 10:04 UTC (Mon) by coriordan (guest, #7544) [Link]

I think both sets of info could be useful.

1. "Initial code generated by DubiousLLM3.0"

2. "Initial code generated by KnownGoodLLM3.0"

3. "Code checked by LLMwhichISnotFORcheckingCODE3.0"

4. "Code checked by KnownGoodLLM3.0"

These could cause the project to react:

1. "Hey, do you realise that DubiousLLM3.0 often does this job poorly?"

2. "Ok, glad to hear you used a tool that has indeed worked well in the past. Our policy is...."

3. "That tool or version is not good for checking code, so the check is mostly worthless"

4. "Thanks for having checked your code before submitting"

Details of disclosure

Posted Jun 23, 2026 2:08 UTC (Tue) by cypherpunks2 (guest, #152408) [Link]

I don't think that's equivalent at all. No one is going to see an impressive, sophisticated patch and think that's an endorsement of GMail because they know the email has nothing at all to do with the patch's contents. But now imagine if every single impressive patch mentioned one particular LLM vendor.

Details of disclosure

Posted Jun 19, 2026 11:55 UTC (Fri) by mchehab (subscriber, #41156) [Link]

> I am conflicted on this specific recommendation.

Me too. In particular, I'm concerned with this:
"LLM-gen-AI users should keep detailed and accurate records of their interaction and save those meta-artifacts for posterity. "

A proper-written LLM assisted code, as described at the recommendation, requires a careful human review of whatever LLM code was generated, which usually means that the actual patch would be just taking suggestions from what LLM proposed. This is not much different than using a web browser to search for some coding information.

Well, people don't save for posterity browser interactions until they get something useful. At most, when there is, for instance, a superuser.com article that has a high match, they could add a URL with it at the patch description. Also, I don't see, on most cases, much value on preserving such interactions for posterity.

Details of disclosure

Posted Jun 19, 2026 19:46 UTC (Fri) by ballombe (subscriber, #9523) [Link] (2 responses)

Also this information is useless unless the LLM is semi-reproducible which is almost never the case.

Details of disclosure

Posted Jun 21, 2026 21:33 UTC (Sun) by joey (guest, #328) [Link]

I was recently reviewing commits to a dependency and found meta-information which included LLM prompts. One of which was "go look at the code of <other repository> and generate $foo". That *is* useful, since, as these recommendations state in point #9, that makes the LLM's output be affected by the license of that other repository.

(I am now in the process of replacing the tainted dependency with something else and have pinned it to a non-tainted version in the meantime.)

Details of disclosure

Posted Jun 22, 2026 9:19 UTC (Mon) by taladar (subscriber, #68407) [Link]

It is entirely plausible that specific models will have a tendency to produce specific types of bugs so which model is used could be useful in the long-term to find those bugs.

Details of disclosure

Posted Jun 19, 2026 20:18 UTC (Fri) by aphedges (subscriber, #171718) [Link] (4 responses)

I personally feel that OpenAI, Anthropic, etc. get discussed so often in mainstream news that any advertising benefit from showing up in a commit message is negligible. I'd rather have the record of what generated the code.

Details of disclosure

Posted Jun 19, 2026 21:52 UTC (Fri) by ballombe (subscriber, #9523) [Link] (3 responses)

LLM are changing every day and you cannot reproduce the generation. So what does this actually tell you ?

Details of disclosure

Posted Jun 19, 2026 21:56 UTC (Fri) by aphedges (subscriber, #171718) [Link] (2 responses)

It tells you the commit is LLM-generated, and many people generating code with LLMs don't sufficiently read the patches produced. It could be a signal for more thorough review than for human-created patches.

It's also possible that a model is found to be malicious, in which case commits generated with them might require further scrutiny.

Details of disclosure

Posted Jun 23, 2026 4:18 UTC (Tue) by mvollrath (subscriber, #183387) [Link] (1 responses)

A funny thing about tagging LLM use. Most of the tags you put on a commit *increase* confidence in the commit as it traverses the development pipeline, indicating that more people have seen and approve of the work. The email address may have some weight on how much. An Assisted-by tag is more likely to *decrease* confidence in the commit. The model may have some weight on how much.

In this way, using the tag voluntarily is disincentivized. Why would you taint a two line commit as assisted, when nobody will ever be able to tell it was automated in discovery, implementation and/or self-review? As long as you write your own commit messages, many stable patches would be untraceable to an LLM because the solutions are obvious, they were just waiting to be discovered.

Now you're taking credit for technique which you may not be able to demonstrate without your fancy tools. Personally I want to be able to do everything with the stock vim that comes with my distro, because I've spent so much time working on remote machines. Others will try to fake it until they make it, and it's not clear what can or should be done about that.

Details of disclosure

Posted Jun 26, 2026 22:07 UTC (Fri) by aphedges (subscriber, #171718) [Link]

Contributors might be disincentivized to use the Assisted-by tag for the reasons you mentioned, but at the end of the day, commit provenance is still an honor system. We can't force people to be honest, but we can encourage it by requesting they tag appropriately.

It would be dishonest to take credit for work that is not my own, so I just don't. If an automated tool (e.g., a linter) or a person contribute to a commit in a significant way, I credit them. I've never used the Assisted-by tag because it's relatively new and its scope is unclear, but I provide appropriate context in commit messages to make clear what the extent of the contribution was.

The document title on LWN is wrong. Correct title begins "Recommendations when", not "Recommendations for"

Posted Jun 19, 2026 7:23 UTC (Fri) by IanKelling (subscriber, #89418) [Link]

I will email too, but I felt this was worth immediately correcting in public, as the difference is significant.

Preamble lacks insight

Posted Jun 19, 2026 7:58 UTC (Fri) by dvdhrm (subscriber, #85474) [Link] (2 responses)

[Preamble]
> Some FOSS project leaders have taken a zero-tolerance approach to any LLM-gen-AI contributions to their projects. We support leaders who make such decisions. FOSS project leaders deserve our sympathy and understanding regarding the volumous onslaught of new contributions.

What irks me most is that this is the first, the primary, and the only argument the preamble lists for maintainers rejecting LLM-gen-AI contributions. Is that really the case? Yeah, the increased workload is menacing, but I have never seen any maintainer close down their project due to a manually made "volumous onslaught of new contributions". Most maintainers even strive once their project takes off and they get many contributions, even if it means they cannot personally keep pace.

Isn't it rather due to the low quality of contributions? The lack of human interaction? The questionable sourcing of LLMs? The dehumanizing conditions behind manual LLM training? The gatekeeping of LLM companies? The exorbitant energy requirements? You name it.

The preamble reads like maintainers mainly struggle due to the alleged increased productivity of the software world. I reject that premise. And it puts the otherwise laudable effort of that list into a bad light.

Preamble lacks insight

Posted Jun 19, 2026 17:17 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

> but I have never seen any maintainer close down their project due to a manually made "volumous onslaught of new contributions".

Maybe machines can have much higher "volumes" than humans? That's certainly what we've heard happening in many projects.

> Most maintainers even strive once their project takes off and they get many contributions, even if it means they cannot personally keep pace.

Source for "Most"? There are many stories about orphaned projects too.

> The preamble reads like maintainers mainly struggle due to the alleged increased productivity of the software world. I reject that premise.

Software productivity is measured in terms of features added and bugs fixed - AFTER careful review, testing and release without backslash. Not in terms of lines of code merely submitted.

In fact, _reducing_ code size (while not removing or regressing any feature) thanks to de-duplication and code-reuse is always the most productive thing. Assuming good test coverage, these submissions are the easiest to review. How good are LLMs for those?

Preamble lacks insight

Posted Jun 20, 2026 10:50 UTC (Sat) by malmedal (subscriber, #56172) [Link]

I've had good results by asking them to find ways to make the code clearer by reducing redundancy. With emphasis on clearer, you don't want the LLMs to play code-golf...