[ANNOUNCEMENT] Updates to the AI usage policy

[Kat Cosgrove]

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

[Benjamin Elder]

> 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

On Fri, Apr 10, 2026 at 10:52 AM 'Brendan Burns' via dev <d...@kubernetes.io> wrote:

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.

--
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/DS0PR21MB597974CD663BCC4C87027CB9DB592%40DS0PR21MB5979.namprd21.prod.outlook.com.

[Antonio Ojea]

It seems we found a loophole ... 

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

On Fri, 10 Apr 2026 at 22:19, 'Brendan Burns' via steering <stee...@kubernetes.io> wrote:

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

 

--
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]

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.

[Antonio Ojea]

I see, ACK to the problem , it is clear that we are facing new challenges that require more extensive discussion

Thanks 

[Brendan Burns]

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

 

[Michael Roach]

Hi Brendan,

I hope you are doing well.

I wanted to weigh in on the discussion regarding the AI usage policy, specifically concerning the comparison between Dependabot and AI-generated contributions. In my view, Dependabot serves essentially as a dependency announcement; ultimately, a human must still review and take full ownership of those changes before they are merged. This direct human accountability seems to be the key distinction from the more creative or generative work produced by AI tools.

Best regards,

Michael D. Roach

Michael D. Roach | Atlanta, GA 30132 | roach.d...@gmail.com

On Fri, Apr 10, 2026, 1:52 PM 'Brendan Burns' via dev <d...@kubernetes.io> wrote:

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

 

Kubernetes Contributors,

--

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.

[Brendan Burns]

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

 

Kubernetes Contributors,

--

[Natali Vlatko]

"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."

The experience that isn't being acknowledged in this framing is the maintainer experience. Many current maintainers of Kubernetes, plus other CNCF projects, have seen an increase in AI-assisted contributions that hallucinate issues, duplicate work, and dump giant lumps of code or documentation into our reviewer pools that don't make sense and have not been reviewed by the person submitting it. At Maintainer Summit EU in Amsterdam a few weeks ago, we ran an unconference (as the most highly voted on the day) specifically addressing how maintainers should deal with the increase of this behaviour, where the tightening up of the AI policy was one of the many suggestions. I want to thank the Steering Committee for hearing the maintainer community on our concerns with contributors who cannot understand what they're submitting, and who have our interests in mind – even alongside those of us who also use AI tooling to assist with our work.

Rather than framing the mechanical details of what a user has to do to open a PR as "busywork", reframing this requirement as a way to help protect maintainer time, alongside forcing a contributor to actually interact with their AI-generated work, is what I believe we can see as the benefits of this policy, regardless of the legal implications needed.

To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/dev/CABBp76s9zjAt%3DcoWjccKcyEqjPS4G6ZhR%3D568JGDNc24h_OouQ%40mail.gmail.com.

[Sean McGinnis]

Take this as just some community feedback...

I do think this policy makes sense. And I'm glad we have something official in place. Thanks to everyone for getting this written down. Hopefully this will help reduce some of the low quality PRs we've been getting lately, and help lead some contributors towards making thoughtful contributions.

The only thing that doesn't quite make sense to me is the requirement to disclose the use in the PR description.

With or without the use of AI, there are usually a lot of tools that are used when working on updates. We don't need to disclose what LSP was used, what IDE, what OS. AI is just another tool someone can utilize to help them write changes. Yes, it goes far beyond what code completion does, but if it's used correctly in the way we're saying it should be used with the contributor understanding and reviewing the changes before submitting anything, it's just a helper for them.

With the integration of AI tooling everywhere, it's probably going to be the case that AI was used more often than not.

There's also a risk this could cause issues for some contributors. What use is a policy if it's not enforced? If we get a PR that does not say it used PR, how do we respond to that if we think it did? And if we think it did but it actual did not, we've already seen some contributors taking offense by others alleging they are an AI bot.

My personal preference would be to drop that part of the policy. As a maintainer I am just going to always assume that AI may have been used in the creation of someone's PR. That won't really change the need to review it for correctness.

But like I said, just some feedback and my 2 cents. It's great to have something in place to point people to when we get slop.

Sean

[Kat Cosgrove]

Sean,

Requiring disclosure when generative AI is used is the responsible thing to do. We are not the only ones who think so; many large companies require the same internally. We understand that many contributors use generative AI and may ignore the disclosure requirement, but we are not flexible on this.

This policy will be enforced. It has already been enforced in its previous form. I've closed a PR for undisclosed use of AI myself within the last few weeks. Requiring disclosure gives reviewers and approvers an important tool to reduce the amount of time wasted reviewing low-quality PRs by providing a clear-cut reason to close a PR if proof of undisclosed AI use is found. There are ways to ask a contributor whether or not they have used generative AI without being confrontational, insulting, or accusatory. I would suggest asking politely and directly, for example, "Could you please clarify whether this PR or your replies were written using an AI tool?"

- Kat

[Verónica López]

I fully understand the intent, however, this feels driven unilaterally by legal/policy framing vs. how people who write/review code actually work day to day. Consequences like the re-authoring flow someone mentioned earlier add mechanical overhead without necessary improving quality. 

I was just reading the Linux kernel's approach to this; while it also operates under a legal model (DCO), it treats the signer as the single point of (legal) responsibility. The human signs and takes full ownership for the change, regardless of whether AI or other tools were involved. Maybe something like that could be discussed in future iterations of this initiative :)

On Saturday, April 11, 2026 at 8:40:01 AM UTC-6 Maurizio Vitale wrote:

It seems to me that assuming all PRs are in part or in full AI generated should be a better default going forward. If 99% of PR contains AI attributions, this will quickly become noise and reviewers will not pay any attention to it and maybe even stop checking. It seems almost more useful to require a disclosure that a PR is purely human.

--

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/CABHW_BeFqPxMY7%3DhSHNnFjGtr7kqxHNMQatpDWBhd_k4GPWBuA%40mail.gmail.com.

[Kat Cosgrove]

This was primarily driven by real maintainer concerns and inspired by suggestions from maintainers, extensively discussed in person at the Maintainer Summit, on Slack, and on the PR for the previous iteration of the AI use policy. It is not primarily driven by the legal grey area around AI commits. Our primary concern with this iteration of the AI use policy is reducing the number of low-quality PRs that are high-effort for maintainers to review. Allowing direct commits from AI tools would not achieve that goal.

The policy will evolve over time. Anyone is welcome to attend the public steering meetings to discuss how it might evolve in the future as new tooling and strategies are available to us.

[Verónica López]

Right, there's obvious consensus on taking measures to reduce AI-slop contributions. I was referring to the legal aspects of the policy regarding CLA signature.

[Maurizio Vitale]

It seems to me that assuming all PRs are in part or in full AI generated should be a better default going forward. If 99% of PR contains AI attributions, this will quickly become noise and reviewers will not pay any attention to it and maybe even stop checking. It seems almost more useful to require a disclosure that a PR is purely human.

On Sat, Apr 11, 2026 at 10:19 AM Kat Cosgrove <kat.co...@gmail.com> wrote:

--