Open source maintainership in the age of AI (Kubernetes blog) [LWN.net]

The Kubernetes project has published a blog post explaining its AI policy:

The main problem is that AI has made generating code fast but there has been very little improvement in maintaining code bases. In this post, we will highlight the ways the Kubernetes community is adapting to the world of AI assisted coding.

The first step of this journey was to develop an AI policy. This seems mundane and bureaucratic but there were many PRs that derailed into discussions around AI usage. The AI policy helps steer the conversation around the project's stance on AI and provides a clear signal to contributors on how to use these tools responsibly.

Of note, the project requires disclosure when AI tools have been used to assist in the creation of a contribution but forbids the use of listing AI as a co-author or including "assisted-by" or "co-developed" trailers to attribute work to an LLM tool.

to post comments

"assisted-by"/"co-developed"

Posted Jun 30, 2026 0:20 UTC (Tue) by wbn (subscriber, #179485) [Link] (11 responses)

Come to think of it, is there any good argument to make in favor of including these extra tags on commits? They primarily seem to function as free advertising. I’m in favor of their removal because I just don’t see them as serving any useful purpose, but I'd be interested to hear arguments otherwise.

"assisted-by"/"co-developed"

Posted Jun 30, 2026 0:46 UTC (Tue) by corbet (editor, #1) [Link] (4 responses)

Co-developed-by indicates authorship by a human; it is essentially a shared form of Signed-off-by, so yes, we need it.

For Assisted-by, the thinking (in the discussions I was part of, anyway) was that documenting the tools used can be helpful for a few reasons. It lets others know how a patch was developed, and if any given tool, say, proves overly prone to creating certain types of security problems, people will know which patches need to be re-evaluated.

"assisted-by"/"co-developed"

Posted Jun 30, 2026 2:41 UTC (Tue) by wbn (subscriber, #179485) [Link] (3 responses)

Ah, I seem to have stumbled over a distinction between "Co-developed-by" (which has been used in the kernel project since ~2017 to mark co-authorship by humans) and "Assisted-by" which is only for LLMs and other tools. I'm only considering the case where the right-hand side of the tag contains the name of some LLM and its version string. Using these tags to credit humans has obvious benefits that I didn't mean to call into question. Using "Assisted-by" to include tool information has, I suppose, some use for security researchers. But how are we supposed to assess the likelihood of a bug introduced by an LLM given only its model name and version? This is going to be highly dependent on context, tool use, sampling parameters, etc. which are impractical to include in a commit tag.

"assisted-by"/"co-developed"

Posted Jun 30, 2026 7:50 UTC (Tue) by taladar (subscriber, #68407) [Link] (1 responses)

Actually given how likely humans (including myself) are to forget details of code we have written mere months later I see very little benefit of including the name of the human for actual development purposes. All it really does it advertise that that human has done some work but the practical use is relatively low beyond maybe the first few weeks.

"assisted-by"/"co-developed"

Posted Jun 30, 2026 11:09 UTC (Tue) by alx.manpages (subscriber, #145117) [Link]

I've been able to contact authors and co-authors of patches 20 years later, and they were able to clarify the commit. This is very very useful information.

Of course, you may find cases where it is not, but there are cases where it is, so including it always increases the usefulness on average, and it doesn't have any downsides (other than a bit of noise in the commit message).

"assisted-by"/"co-developed"

Posted Jun 30, 2026 12:41 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

> Using "Assisted-by" to include tool information has, I suppose, some use for security researchers. But how are we supposed to assess the likelihood of a bug introduced by an LLM given only its model name and version?

When a coworker submits a patchset for inclusion in a project, I have some prior of where they tend to miss things (e.g., maybe they skimp on docs, don't consider Windows or MSVC support, etc.). If I see the patches have an LLM involved, I know to toss such priors out the window and know that it's probably going to need a finer-tooth review than normal.

"assisted-by"/"co-developed"

Posted Jun 30, 2026 1:03 UTC (Tue) by timrichardson (subscriber, #72836) [Link] (4 responses)

I remember doing this, co-authored attribution, back in the day (12 months ago) because I though it was ethical to flag this, given concerns about code quality.

Some maintainers were very uncomfortable on the grounds of copyright (which I had not considered).
Those concerns don't really go away by not flagging co-authorship, instead you get "deniability". Using "co-authorship" or not doesn't change the question of copyright.

The Kubernetes blog post and policy doesn't mention the question of copyright; maybe it is now a completely settled question.

"assisted-by"/"co-developed"

Posted Jun 30, 2026 5:54 UTC (Tue) by zdzichu (subscriber, #17118) [Link]

It's not settled, but majority of people do not care about copyright issues.

"assisted-by"/"co-developed"

Posted Jun 30, 2026 18:57 UTC (Tue) by Karellen (subscriber, #67644) [Link] (2 responses)

Kubernetes requires contributors to have signed a CLA, where you warrant that your contributions are your original creations, and that you have the right to license them to the project.

My guess is that if output from the spicy autocomplete machine does turn out to be a copyright-encumbered mechanical transformation of its training data inputs, deniability for Kubernetes is already built in to the CLA because they have it on record that you said you had the right to give them the code. If you got the legal status of your contributions wrong, that's on you, not them, irrespective of the presence/absence of any "Assisted-By" tags.

https://github.com/kubernetes/community/blob/main/CLA.md

https://github.com/cncf/cla/blob/main/individual-cla.pdf

"assisted-by"/"co-developed"

Posted Jul 2, 2026 9:25 UTC (Thu) by mpsk (subscriber, #183534) [Link] (1 responses)

It might save them from legal troubles (which is a valuable thing, but what about the actual cobtribution? In case somebody proves that some piece of code in the project consists a copyright breach, won't they be required to delete it? And if yes, then not only they'll have to deal with a hole in their source (which means missing features or even core functionalities), but also rewrite their VCS history, retract and delete archived versions, etc...

But that's actually not LLM-specific, it's something a human could cause too (copying a copyrighted code or manually rewriting it in an almost identical form). Are there precedents of large Open Source projects dealing with justified copyright claims that ended with them deleting a substantial part of the code?

"assisted-by"/"co-developed"

Posted Jul 2, 2026 10:34 UTC (Thu) by kleptog (subscriber, #1183) [Link]

> Are there precedents of large Open Source projects dealing with justified copyright claims that ended with them deleting a substantial part of the code?

Well sure, many. Except most of the cases are about licensing issues (did the submitter have the right to licence the code). Apparently FFmpeg and the kernel have deleted modules where the providence was not clear. AFAIK nobody bothers removing it from Git history. You can argue about "justified" since none of these cases go to court. SCO being the well-known outlier.

I'm not really clear were we'd likely run into issues of LLMs possibly copying code written elsewhere to an extent where it might be a copyright issue. At least where I use it I doubt the code I'm writing has sufficient originality to be copyrightable anyway. This makes software very different to other literary works: stuff that has to get the same results has significant constraints in how it can be written, so copyrightability is less an issue. There are only so many ways you can write QuickSort, even if you take into account indentation, variable names and comment variations. "Best practices" drastically reduce the variations.

"assisted-by"/"co-developed"

Posted Jun 30, 2026 11:06 UTC (Tue) by alx.manpages (subscriber, #145117) [Link]

To me, it's a big red sign saying "this commit has higher chances of being bad; review very very carefully".

Accountability!?

Posted Jun 30, 2026 11:18 UTC (Tue) by marcH (subscriber, #57642) [Link]

> A simple statement in the PR description such as "This PR was written in part with the assistance of generative AI" is sufficient. This transparency helps reviewers understand the context and apply appropriate scrutiny.
>
> Human accountability
> While AI tools can assist, the human contributor remains fully responsible for every change. The policy explicitly prohibits:
>
> - Listing AI as a co-author on commits
> - Using AI co-signing on commits
> - Adding trailers like "assisted-by" or "co-developed" that attribute work to AI
> This isn't about diminishing AI's role as a tool—it's about maintaining clear accountability.

So, what "maintains clear accountability" is ... making the information harder to parse from the commit message!?

I understand banning "Co-authored-by" but banning "Assisted-by" seems ridiculous.

I honestly don't know whether making AI assistance parsable in commit messages is important or not. I tend to think that in doubt, might as well. Better safe than sorry later down the road. But I'm not sure.

On the other hand, it's pretty obvious that parsability is completely unrelated to accountability.