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
