[ANNOUNCEMENT] Updates to the AI usage policy

155 views
Skip to first unread message

Kat Cosgrove

unread,
1:06 PM (4 hours ago) 1:06 PM
to dev, stee...@kubermetes.io, le...@kubernetes.io

Kubernetes Contributors,

We have recently published an update to the project’s policy on the use of AI tools. We want to make sure contributors are aware of this change, and also explain why these changes were necessary.

The AI use policy is as follows:


Using AI tools to help write your PR is acceptable, but as the author, you are responsible for understanding every change. If you used AI tools in preparing your PR, you must disclose this in the description of your PR. Listing AI tooling as a co-author, co-signing commits using an AI tool, or using the `assisted-by`, `co-developed` or similar commit trailer is not allowed.


All contributions must follow the contributions policies and use commit messages that align with the policy. Large AI-generated PRs and AI-generated commit messages are not allowed.


Do not leave the first review of AI generated changes to the reviewers. Verify the changes (code review, testing, etc.) before submitting your PR. Reviewers may ask questions about your AI-assisted code, and if you cannot explain why a change was made, the PR will be closed.


When responding to review comments, you must do so without relying on AI tools. Reviewers want to engage directly with you, not with generated responses. If you do not engage directly with reviewers, the PR will be closed.


The up-to-date version of the policy is available at https://www.kubernetes.dev/docs/guide/pull-requests/#ai-guidance


We understand that some companies now require the use of an AI coding assistant and mandate disclosure in certain ways. We don’t object to the use of AI, but we do require that you disclose its use specifically in the PR description. 


Kubernetes cannot and will not allow co-authoring PRs or co-signing commits with AI for the simple reason that the AI cannot sign a CLA; this is a legal requirement. For this reason, we cannot allow disclosure via co-authoring or co-signing. Previously, EasyCLA has not run CLA checks against co-authors. That functionality has now been enabled for Kubernetes repositories.


Use of `assisted-by` or `co-developed` commit trailers was suggested as a way to disclose AI use and keep it in the git metadata, but it introduces another problem: the ability for third parties to use the Kubernetes project for marketing (more than they already do). While we trust that most companies will behave, many will not, and allowing this runs the risk of any company who gets a PR merged using the `assisted-by` trailer or similar publicly advertising that the Kubernetes project uses and endorses their paid tool. This trend has already been observed within the project. It is a necessary first step to ensure project standards for code quality and community are met. This policy will evolve over time, as new tools and strategies are made available to us.

Thanks,

Kubernetes Steering Committee

Brendan Burns

unread,
1:52 PM (3 hours ago) 1:52 PM
to dev, kat.co...@gmail.com, stee...@kubermetes.io, le...@kubernetes.io
Fwiw, we allow PRs from dependabot to go through the CLA check. Why is accepting PRs from the github copilot user any different?

The ability to assign issues to copilot via the github UX is quite useful, having to re-create the PR just to have the commits come from my user is just busy work, why should we require it?

--brendan

From: Kat Cosgrove <kat.co...@gmail.com>
Sent: Friday, April 10, 2026 10:06 AM
To: dev <d...@kubernetes.io>
Cc: stee...@kubermetes.io <stee...@kubermetes.io>; le...@kubernetes.io <le...@kubernetes.io>
Subject: [EXTERNAL] [ANNOUNCEMENT] Updates to the AI usage policy
 
--
You received this message because you are subscribed to the Google Groups "dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@kubernetes.io.
To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/dev/2a0b85f2-9bad-4742-a94d-1317fbcc6568n%40kubernetes.io.

Benjamin Elder

unread,
3:30 PM (2 hours ago) 3:30 PM
to bbu...@microsoft.com, dev, kat.co...@gmail.com, stee...@kubermetes.io, le...@kubernetes.io
Fwiw, we allow PRs from dependabot to go through the CLA check. Why is accepting PRs from the github copilot user any different?

Speaking purely as myself and not formally on behalf of the committee:

1. Generally, the CNCF is responsible for the CLA policy, including implementing, configuring, and running the service.

2. *All* co-authors, including humans, now have the CLA check enforced. No Copilot-specific changes have been made. Failing to check co-authors was a misconfiguration.

3. The CNCF has told us that they need the copyright assignment / CLA to refer back to a human for legal purposes.

4. I **presume** since Dependabot updates are entirely mechanical with no alternate way to implement them (i.e., no creative work) they've been deemed acceptable. This seems distinct from other types of changes.

I am not a lawyer, the CNCF handles legal concerns for the project.

We can certainly continue to discuss this space with the CNCF.

- Ben

Brendan Burns

unread,
4:19 PM (1 hour ago) 4:19 PM
to Benjamin Elder, dev, kat.co...@gmail.com, stee...@kubernetes.io, le...@kubernetes.io
To be clear, I fully understand the concerns about the CLA, my feedback is mostly about the mechanics.

If I use the integrated github copilot experience today with Kubernetes issues, I need to take the PR that is created, take the commits, re-author them to me, close the copilot PR and re-open one of my own, presumably pointing back to the copilot one to acknowledge the AI experience.

Similarly, I will need to re-author all commits that I co-author with copilot via @copilot comments on PRs.

The mechanical details of what a user will need to do in these workflows just feels like busywork.

I get that CNCF adminsters the CLA and likely needs to update their bot, but I hope we can show them how the current policy is interfering with developer experience for no real benefit.

We can (for example) introduce a prow comment that says `/cla brendandburns` or something like that to achieve the CLA without breaking the workflow.

--brendan

From: Benjamin Elder <benth...@google.com>
Sent: Friday, April 10, 2026 12:29 PM
To: Brendan Burns <bbu...@microsoft.com>
Cc: dev <d...@kubernetes.io>; kat.co...@gmail.com <kat.co...@gmail.com>; stee...@kubermetes.io <stee...@kubermetes.io>; le...@kubernetes.io <le...@kubernetes.io>
Subject: Re: [EXTERNAL] [ANNOUNCEMENT] Updates to the AI usage policy
 

Antonio Ojea

unread,
4:45 PM (25 minutes ago) 4:45 PM
to Brendan Burns, Benjamin Elder, dev, kat.co...@gmail.com, stee...@kubernetes.io, le...@kubernetes.io
It seems we found a loophole ... 

and we need to figure it out a solution  ` /cla <@handle>`  sounds a good idea IMHO

You received this message because you are subscribed to the Google Groups "steering" group.
To unsubscribe from this group and stop receiving emails from it, send an email to steering+u...@kubernetes.io.
To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/steering/DS0PR21MB597948C27D9E5DBC51FCD183DB592%40DS0PR21MB5979.namprd21.prod.outlook.com.

Kat Cosgrove

unread,
4:58 PM (13 minutes ago) 4:58 PM
to dev, Antonio Ojea, Benjamin Elder, dev, kat.co...@gmail.com, stee...@kubernetes.io, le...@kubernetes.io, Brendan Burns
This is a loophole easily closed by scoping the policy to code and documentation contributions.

Any possible future where the AI policy is adjusted to allow direct commits from an AI tool, Copilot or otherwise, will require extensive discussion. Currently it does not. We intentionally require that commits come from a human who has signed the CLA. This is, in part, a direct requirement from LF Legal and is out of our hands.
Reply all
Reply to author
Forward
0 new messages