What sort of AI related problems is the project dealing with that these policies are intended to address?
Aside from an uptick in nonsensical security reports (which wouldn’t be addressed by these policies anyway) I’m not aware of an influx of low quality ai generated patches that would justify adding a bunch of restrictions to the contribution process. This should start by defining some concrete problems we are trying to address. On Tue, Sep 22, 2026, at 7:33 AM, Isaac Reath wrote: > Adding to Dmitry's examples above, the Lucene AI Policy: > https://github.com/apache/lucene/blob/main/AI_POLICY.md > > What resonates most with me with this policy is its focus on contributor > understanding and its accountability for that understanding. Whether or not > an LLM is used to derive that understanding is secondary to the fact that the > contributor must have it. > > I am +1 to LLM usage being restricted for communications, especially for > writing inline comments / javadocs. For a larger document like a CEP or usage > documentation, I think LLMs still have a place; not necessarily to generate > the entire document, but to act as an initial reviewer to ensure that the > ideas in it are fully fleshed out before publishing for a wider audience. > > On Tue, Sep 22, 2026 at 9:05 AM Dmitry Konstantinov <[email protected]> > wrote: >> >> Hi Benedict, thank you for starting the discussion. >> >> The initial version looks solid to me. >> >> I would relax this part a bit: *“All public prose must be human authored. >> This includes inline comments, docs, posts to Jira, etc.”* I don't see a big >> issue with using AI to generate appendix-like structured material such as >> test/perf result tables, dependency usage analysis, comparisons, reference >> data, invocation tracing, etc., as long as it is prefixed with a >> human-written introduction explaining it. >> >> I've also looked through similar policies for other projects. It seems to me >> that the amount of restriction/control tends to correlate with how low-level >> the project is in the overall stack. >> >> From my point of view, we shouldn't be as strict as programming >> language/compiler projects, but neither should we be as relaxed as business >> application projects. In other words, we need a balance between stability >> and maintainability vs development speed. >> So I don't like either a complete ban or a Wild West approach. >> >> At the lowest level I see programming languages and compilers, the rules are >> generally pretty strict here: >> * JDK: https://openjdk.org/legal/ai (AI for testing/debugging/analysis is >> ok; generating code/contributions is restricted) >> * Zig: https://ziglang.org/code-of-conduct/#strict-no-llm-no-ai-policy (no >> LLM/AI for patches, issues, or bug-tracker comments) >> * Rust: https://forge.rust-lang.org/policies/llm-usage.html >> (analysis/review/suggestions are ok; creating public code/docs/comments is >> heavily restricted, with limited exceptions and disclosure requirements) >> * GCC: https://gcc.gnu.org/ai-policy.html >> (research/analysis/debugging/review are ok; legally significant AI-generated >> contributions are generally not accepted; some test cases are exempt) >> * LLVM: https://llvm.org/docs/AIToolPolicy.html (AI use is allowed with >> human review/accountability; substantial AI-generated contributions should >> be disclosed) >> * Clojure: https://clojure.org/community/contributing#_no_generated_code >> (AI-generated code is not accepted) >> >> The next level is OSes, databases, container environments, etc (I would >> classify Cassandra into this category): >> * Linux kernel: https://docs.kernel.org/process/coding-assistants.html >> (AI-assisted contributions are allowed, but require human >> review/accountability and appropriate attribution) >> * Fedora: >> https://docs.fedoraproject.org/en-US/council/policy/ai-contribution-policy/ >> (AI assistance is allowed with human accountability; significant AI >> assistance should be disclosed) >> * Kubernetes: >> https://www.kubernetes.dev/docs/guide/pull-requests/#ai-guidance >> (AI-assisted PRs are allowed with disclosure and human verification; large >> AI-generated PRs and AI-generated commit messages are not allowed) >> * TigerBeetle: https://x.com/jorandirkgreef/status/2045121119326285866 >> (strongly human-centric; code is handcrafted/reviewed, and LLM-authored >> contributions are rejected) >> * Postgres: I found no established policy; there have been a few AI-drafted >> patches with human refactoring on top >> * ClickHouse: >> https://github.com/ClickHouse/ClickHouse/blob/master/AI_POLICY.md (AI use is >> broadly allowed; disclosure is not required; contributors are expected to >> filter out low-quality output) >> >> >> On Tue, 22 Sept 2026 at 12:51, Štefan Miklošovič <[email protected]> >> wrote: >>> I do not see anything controversial here and I can +1 this with no >>> objections. >>> >>> I am of the opinion that AI is a good helper when used appropriately >>> but a human should always be at the front seat otherwise it will >>> eventually atrophy into a blob of something nobody really has a grasp >>> of nor have a relationship with. A review is a good place to see if an >>> author actually understands what they wrote and if they are receptive >>> to a change when suggested. As somebody who is looking into the open >>> PRs on a daily basis, the sure way to identify a contributor who is >>> using AI heavilly without constraints is when they create a handful of >>> PRs in a fast cadence and we never hear from them anymore. >>> >>> On Tue, Sep 22, 2026 at 12:28 PM Benedict <[email protected]> wrote: >>> > >>> > Hi everyone. Let me preface this by saying that we need a policy on this, >>> > and we will probably struggle to reach a consensus. So to focus minds, I >>> > will remind everyone that the project rules permit unilateral vetoes on >>> > contributions, and in the absence of any policy on the matter that >>> > includes AI generated contributions. >>> > >>> > My proposal in brief is that LLM usage is >>> > >>> > ===== >>> > Encouraged: >>> > - Reviewing and otherwise validating human-authored patches before >>> > submission >>> > - Debugging, diagnosing etc >>> > >>> > Permitted: >>> > - Generating or modifying tests, scripts, tooling or any other non-user >>> > facing changes >>> > - Minor changes to human-authored patches that are carefully reviewed by >>> > the author >>> > >>> > Restricted: >>> > - Core code changes made by LLM may only be proposed by contributors with >>> > demonstrated expertise >>> > - Must have produced similar patches in size, scope and area >>> > unassisted and with minimal third-party guidance >>> > - Core code changes made by LLM require an additional reviewer >>> > - LLM review is not a substitute for human review, and must be used only >>> > to augment a complete and independent human understanding of the patch. >>> > >>> > Prohibited: >>> > - All public prose must be human authored. This includes inline comments, >>> > docs, posts to Jira etc. >>> > >>> > All LLM generated changes MUST be disclosed: >>> > - Outlined to any reviewer; >>> > - Summarised in the commit message; >>> > - Large blocks or files must be individually marked with some agreed >>> > message like "created by <some AI>" >>> > ===== >>> > >>> > I will keep my argumentation brief. >>> > >>> > LLM generated changes: >>> > - Break the community and knowledge-building aspect of patch review, >>> > since the contributor is not clearly learning from the feedback process >>> > - Flips the asymmetry between author and reviewer/maintainer: it is >>> > now cheaper to write than review or maintain >>> > - Does not demonstrate expertise, commitment or that they can or will >>> > maintain the patch >>> > >>> > For these reasons, it should be expected that the person producing the >>> > patch has already demonstrated their expertise and commitment by >>> > producing and maintaining similar patches without the use of AI >>> > >>> > Authoring a patch results in deeper understanding. To offset the reduced >>> > collective knowledge of LLM generated changes, and improve our ability to >>> > confidently maintain it, we should expect changes to be more widely >>> > socialised through an additional review. >>> > >>> > Finally, LLM comments are worse than no comment. An author must ensure >>> > their reader's time is valued, by investing their own time crafting a >>> > message with a proper understanding of its intended audience. LLMs may >>> > assist in preparation, but must not produce the content itself. >>> > >>> > I don't believe this fully accounts for all of the risks posed by AI >>> > usage in the project, especially regarding maintainability of the >>> > codebase and maintaining the community. But I hope this middle-ground >>> > policy will prove to be acceptable to enough of the community. >>> > >> >> >> -- >> Dmitry Konstantinov
