Replies: 28 comments 28 replies
-
|
This is a nice clear example of how another project is handling it (HT @geakstr for pointing this out) |
Beta Was this translation helpful? Give feedback.
-
|
Credit and legal implications 🧵
The current approach in the Cilium project is that we rely heavily on DCO and trust in contributors to read this document and sign off that they are following its steps. Parts (a) or (b) seem quite difficult to honestly certify without either creating the contribution yourself or building on work from a reputable website like GitHub that clearly denotes the appropriate licensing. Part (c) is of course a delegation to someone else who certified one of (a) or (b). Do we know of any LLM tools that limit the training data to licenses compatible with the project? Is there an audit trail of the source material to provide a reasonable basis to state that the work is covered by an appropriate open source license? |
Beta Was this translation helpful? Give feedback.
-
Yes. One possible approach: Include a checkbox in the PR template with language that reflects a default assumption that someone is using LLM tooling. Ensure that contributors must take explicit action to certify that an LLM was not used. |
Beta Was this translation helpful? Give feedback.
-
One idea is to require high context before reviewing a PR. That is to say, reviewers should do an initial 2m triage of the motivation for the PR before reviewing the work. If the context is insufficient, request context and move on. In cilium/cilium we often go through this pattern anyway just as a way to assist reviewer workload, since we already face similar problems with sharing the understanding between contributors and reviewers. |
Beta Was this translation helpful? Give feedback.
-
I don't have a full answer, here, but I have some thoughts. Your question highlights in particular a category of contributors: those who are unaware of the norms, expectations and policies of the project. On that note I think it would help if the project has a clear policy that states what is acceptable behavior with respect to the use of AI/LLM tooling so that we can take action on an objective basis as situations arise. As a broader discussion point, we should not assume any level of trust as a baseline from new contributors. I'll pull in references to the University of Minnesota debacle with the Linux kernel (TechCrunch coverage) and the xz-utils exploit (Ars Technica coverage) here for some examples of misplaced trust in the open source world. These are not AI/LLM examples, but they provide some broader context. We could consider taking inspiration around the handling of these incidents from these other projects. |
Beta Was this translation helpful? Give feedback.
-
|
Using LLMs to summarize code in order to make it easier to start working on Cilium 🧵 Someone shared with me a workflow where they interactively analyzed logic in the Cilium tree using some modern LLM-based tooling. This was not for drafting content changes for the project, but rather to inquire about how something works in Cilium and to locate the relevant code. For newer contributors who are not familiar with the Cilium architecture, how to navigate the codebase, or how to answer questions they have about how Cilium operates, it seems like this may provide a way to "rubber duck" and explore the codebase more easily. |
Beta Was this translation helpful? Give feedback.
-
|
I personally use Copilot regularly and I find it very helpful. I do think that it is important to clarify how I use it, which is essentially as a better form of auto complete (which I realize is the most basic way to use LLMs). It helps me type out verbose and predictable parts of my code such as function signatures, error handling and similar additions to code which I want to write already, but instead of doing it manually I press . I feel that the way I use tools like this does not effect the quality of my code, since I will always end up with what I had in mind. The same goes for copyright, concerns. Output is similar if not exactly the same to what I would have typed manually, just faster. LLMs are a tool, which like any other can be used for good and evil, it all depends on the user. I personally feel that outright banning LLMs is not the way to go. I would rather hold people accountable for all code they submit no matter how they made it. |
Beta Was this translation helpful? Give feedback.
-
|
This is my suggestion for a policy: To maintain the high quality and trustworthiness of contributions to the Cilium project, we provide the following guidance on the use of large language models (LLMs), such as GitHub Copilot, ChatGPT, or similar tools: Acceptable UseWe recognize that LLMs can be helpful tools, for example:
These uses are acceptable provided the contributor:
Unacceptable UseIt is not acceptable to:
Transparency & AttributionWe do not require contributors to declare when LLMs were used for basic productivity support. However, if LLMs were used to generate non-trivial text or code (e.g., new features, documentation pages, complex design proposals), contributors are encouraged to note that LLMs were used and explain the human review process applied. DCO and LicensingThe Developer Certificate of Origin (DCO) still applies. AI tools often lack transparency into their training data and may produce copyrighted output. If you submit AI-assisted code, you are certifying that it does not infringe on any licenses and that you have the right to contribute it under the project's license. If you’re unsure, don’t submit it. Guiding PrincipleCilium is a community-driven project that values expertise, clear communication, and personal responsibility. Whether or not an LLM was involved, contributors are fully accountable for the correctness, security, and clarity of their contributions. |
Beta Was this translation helpful? Give feedback.
-
|
Contributors must take responsibility for the full content they submit in a PR 🧵
The first and last points are a bit tricky here: I agree to some degree around the sentiment, but I think it's not a very practical position to take. For the sake of discussion, let's take LLM tooling out of the picture and just consider contributions more generally. It is somewhat common that someone does not fully understand the codebase or their own contribution. They may not be able to fully explain / justify the code. Part of the point of the review process is to identify gaps where the contributor may lack context or may not fully understand the project and have a discussion about the abstractions, shape of the problem, possible solutions and so on. Although I think it would be ideal if everyone had a full picture of what changes need to be made and could explain the contribution all the way, this is a high bar to set. We need to recognize that there will be contributors with different experience levels and we'll need to meet those contributors where they're at. Ideally that interaction will develop the contributions to the point that they generally improve the project and do not create significant problems, and while we're at it, provide a positive experience for the contributors to help motivate them to continue to contribute in a healthy way. The most practical response to my feedback above would be to loosen the language a little bit to set expectations that when you submit a change, you are trying to improve something in the project to the benefit of the community, and that you will honestly engage in the review process to the best of your ability. Something I would be happy to see written as unacceptable would be to use LLMs as part of review discussion.
We've already seen people violate this without even knowing. We can state that this is the policy, but I think we have to recognize that if we set expectations that LLM usage is generally OK, there will be submissions in this category that everyone will miss. Maybe if we're lucky that will not cause an incident, but I have very little interest in having to deal with such an incident because we set a policy that is too liberal. I guess to summarize.. I agree with this sentence, but I think the only practical way to enforce it is to ban non-trivial use of LLMs (probably, anything more than a line or two here or there). |
Beta Was this translation helpful? Give feedback.
-
|
Contributors should not use LLMs to engage in pull request discussion 🧵 via @xmulligan
I'd like to share another experience I've had in the Cilium community recently. A new contributor submitted a pull request to fix a "good first issue". When I reviewed the submission, I asked a specific technical question and provided a reference link to what I was talking about so that the contributor could understand the basis of my question. I was curious to learn about the technical solution, but I also wanted to check whether the contributor had experienced the issue they were fixing and whether they were doing a drive-by contribution or whether there is potential to mentor the contributor to become a regular contributor. The contributor responded to my question with some text that was clearly generated by an LLM. The response did not make sense, and it did not match the communication style that the contributor used elsewhere in the PR. I asked the contributor whether they used an LLM to generate the answer as the response was very clearly not written by them. The contributor responded in their own voice that they had not used an LLM. That is to say, they directly lied in response to my question. We currently do not have a policy regarding LLM usage, so if the contributor acknowledged usage and engaged in discussion directly then I think we might have been able to navigate the pull request process. However, I think now it is a matter for the code of conduct. I feel that there is a trend recently where developers are trying to generate a good-looking CV/Resume by flooding OSS projects with low-quality submissions. These contributors attempt to get involved in the project not for the benefit of the community but only for their own enrichment. As we are starting to see abuse of the Cilium community of this kind, I would like to see clear guidance in place that highlights that such behavior is unacceptable, and provides guidance to the maintainers and committers about how to respond to such incidents. I recognize that this incident is not caused by the use of LLM, but that LLM tooling lowers the cost for abusive behavior in OSS communities. From my perspective if the project has a blanket rejection on accepting content created using LLM tools, then the line is crystal clear about whether such submissions cross the line and I could point to the policy and close the PR. |
Beta Was this translation helpful? Give feedback.
-
|
Are we trying to define the "Turing Test"? I would be in favor of accepting anything regardless of its origin as long as the intent of the PR is clear, no low effort (typos etc), no huge 'automatic' refactoring like change |
Beta Was this translation helpful? Give feedback.
-
|
I honestly don't think this one is too bad either https://github.com/agentgateway/agentgateway/blob/main/CODE_OF_CONDUCT.md |
Beta Was this translation helpful? Give feedback.
-
|
Additional project proposals around AI usage: |
Beta Was this translation helpful? Give feedback.
-
|
Airflow has an AGENTS.md https://github.com/apache/airflow/blob/main/AGENTS.md "Somehow I have a feeling that quality of the contributing docs is nowadays super important - precisely because the AI agents that people use actuallly read those instructions - as opposed to many humans who often did not read instructions before contributions." |
Beta Was this translation helpful? Give feedback.
-
|
I also quite like this one from OTel https://github.com/open-telemetry/community/blob/main/policies/genai.md |
Beta Was this translation helpful? Give feedback.
-
Seems like Harbor has an https://github.com/goharbor/harbor/pulls?q=is%3Apr+author%3AArvindhworks+is%3Aclosed |
Beta Was this translation helpful? Give feedback.
-
|
The git Summer of Code AI guidelines are pretty well written and clearly outline many of the aspects of the problem space: https://git.github.io/General-Application-Information/ |
Beta Was this translation helpful? Give feedback.
-
|
I quite like the way that RedHat frames the issues here https://www.redhat.com/en/blog/ai-assisted-development-and-open-source-navigating-legal-issues |
Beta Was this translation helpful? Give feedback.
-
|
Saw this elsewhere and I agree with the sentiment: Our big concern right now is AI-led contributions, not the AI-assisted ones. We have tons of people who see our issues and think they can just delegate 99% of the work to the AI and arrive at a good result. |
Beta Was this translation helpful? Give feedback.
-
|
I kind of like this line "Human review is required for all code that is generated or assisted by a large language model." |
Beta Was this translation helpful? Give feedback.
-
|
I like how Zulip focuses on the why not the how and succinctness https://github.com/zulip/zulip/blob/main/CONTRIBUTING.md#ai-use-policy-and-guidelines |
Beta Was this translation helpful? Give feedback.
-
|
Python splits it clearly into "acceptable uses", "unacceptable uses" and "considerations for success": |
Beta Was this translation helpful? Give feedback.
-
|
In light of security incidents like camoleak, I think we should strongly recommend against committers from using generative AI tools. The lack of determinism in the tooling combined with classic security bugs presents a risk that is greater than the benefits of the tooling. If committers take responsibility for those risks, they must have at least one secondary deterministic control to limit the risk. For instance, when granting GitHub API access, create a token with read-only permissions only on the required repositories. I note that while this would mitigate problems associated with write tokens, it could still leak content of private repositories through read access. It would also be very easy to misconfigure this to grant too much access, so this should not be taken lightly. If the tooling doesn't provide secondary controls, the tooling must not be used. Any actions undertaken by generative tooling must be reviewed by the user of those tools (for instance if generating text, the contributor must review the content). While the camoleak exploit has been patched by GitHub, I don't currently see the ability to configure secondary controls in GitHub Copilot today, so I think we should avoid all Copilot use through the GitHub website. |
Beta Was this translation helpful? Give feedback.
-
|
Overall like a lot of the sentiment in this write up |
Beta Was this translation helpful? Give feedback.
-
|
Could be an interesting talk here too |
Beta Was this translation helpful? Give feedback.
-
|
Relevant issue: cilium/cilium#43656 |
Beta Was this translation helpful? Give feedback.
-
|
Not a bad take either ghostty-org/ghostty#10412 |
Beta Was this translation helpful? Give feedback.
-
|
Seems like we are starting to coalesce on some themes. I'll ask to add this to the Cilium Dev Summit to discuss there. Maybe we can come up with a policy we can all agree on later this year. |
Beta Was this translation helpful? Give feedback.


Uh oh!
There was an error while loading. Please reload this page.
-
We currently have no written policy around the use of generative AI in code contributions. We may want to establish a policy that does things like require contributors to disclose when AI tooling was used, holding AI-assisted submissions to the same standard of originality, quality, and attribution as any other contribution,
and encourages contributors to learn, understand, and reason through the code they're submitting, rather than deferring entirely to tooling.
AI tooling in general can be a useful accelerant but if a contributor cannot explain the code they’re submitting, or isn’t able to reason through feedback, that’s a red flag.
A few things we might want to consider when developing:
How do we ensure contributors appropriately credit prior work, whether human- or AI-generated?
Should we require contributors to disclose if AI tools were used? If so, how do we define acceptable usage?
How do we handle low-context, potentially AI-generated PRs that add to the review burden and may reflect limited understanding of the codebase?
How do we handle cases where trust is broken through copy-paste or AI-mediated submissions, particularly when the contributor appears early in their OSS journey?
Beta Was this translation helpful? Give feedback.
All reactions