This is something I could support as well.
Our docs tend to be neglected. While ideally our docs would be 100% human generated, they’re mostly just not generated at the moment. While not ideal, I think relaxing the rust LLM policy as it relates to docs would be a net positive for users, provided they’re human reviewed and edited.
How would we handle the “Non-critical” part of the experimental section? The policy exempts rust-lang members from that… does this mean we’d exempt committers but not non-committers. What’s the Cassandra analog of the non-critical section?
I've gone over the the Rust policy. I am in support of the Rust
version with the tweaks proposed by Caleb.
Best,
- Francisco
On 2026/09/28 18:45:03 Aleksey Yeshchenko via dev wrote:
> Some last minute amends to the suggested policy's TL;DR, with Caleb's approval:
>
> - It’s fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review.
> - LLMs work best when used as a tool to write better, not faster.
>
> "But not to create." bit is covered in detail by the full policy and is impossible to summarise well in two words.
>
> With other changes as outlined by Caleb in the quoted email, I would be happy to support this fine-tuned version of Rust's policy.
>
> --
> AY
>
> >
> > To clarify, I would remove the "Experimental" tag and make that section apply to all contributors. (In other words, encourage attribution, quality, and human decision-making for all of us.)
> >
> > The spirit of this is really a one line change to the Rust policy:
> >
> > > It’s fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.
> >
> > ...becomes...
> >
> > It’s fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to decide.
> >
> >
> >
> >> I finally read the Rust and Lucene policy docs in more detail...
> >>
> >>
> >> I think I agree with a lot of what's written in both, and they overlap quite a lot, especially around communication (docs, issue comments, etc.) that should be primarily human-to-human. Everything useful in the Lucene policy is already included in the Rust policy though. If we could take the Rust policy, generalize away the Rust-specific things, simplify it, and remove the "Experimental" tag (and probably the "non-critical" qualifier) on the "LLM-created code changes intended of review" section, I think that's something a large majority of us would be able to live with.
> >>
> >> If we can get this right, it's simply clarifying the set of things contributors (including existing committers) can do to have the best chance at getting engagement from reviewers.
> >>
> >> I don't know how much appetite there is out there for a formal draft of this, and we already have 3-4 proposals, but I could attempt it if that would be useful...
> >>
> >>
> >>> A clarification from my side, I asked "what is wrong with this" in my
> >>> latest email:
> >>>
> >>> "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"
> >>>
> >>> It is "almost fine", the part of "similar patches without the use of
> >>> AI" should not be there. It should stop before that.
> >>>
> >>> Otherwise this is going to exclude people who have a decade of
> >>> experience with Cassandra and contributed countless patches of various
> >>> size and complexity while according to that exact wording, they would
> >>> not be eligible to contribute an AI patch. That is silly. I think this
> >>> is wrong. It does not matter how it was produced. What is important is
> >>> established trust and if a patch is correct. What does even the size
> >>> of a patch have in common with that? Expertise and commitment! Not
> >>> "the series of patches this committer ever produced was not complex
> >>> enough so we can't take that code in".
> >>>
> >>> Also, who is exactly going to measure that anyway? What are the
> >>> _objective_ criteria who qualifies? Somebody might come and say "while
> >>> based on my criteria, (because I do not like this person), I do not
> >>> think that the patches of this person qualify, because ...". We need
> >>> hard data on whether it can be merged or not, performance improvement,
> >>> stability ...
> >>>
> >>> I think this particular wording would need to be refined further.
> >>>
> >>> On Mon, Sep 28, 2026 at 4:34 PM Štefan Miklošovič
> >>> >
> >>> > Right ... for that reason I don't think we should restrict anybody to
> >>> > create a PR or anything like that, putting some artificial constraints
> >>> > people will eventually bypass anyway. We don't have that under
> >>> > control. What we have under control is the review part of that. A
> >>> > patch not merged will not be released. The review itself is the
> >>> > "gate".
> >>> >
> >>> > If a PR, even done by AI, is up to standards, has everything it should
> >>> > have and it is technically correct, then I can not reject to merge
> >>> > that only on the basis it was AI-generated. A patch like a patch. The
> >>> > code speaks. The ultimate gate is if a patch is correct or not, not
> >>> > how it was produced.
> >>> >
> >>> > Do I gravitate with my trust more towards established members of the
> >>> > community? Definitely. The trust is earned over the years. Implicitly,
> >>> > I am trusting a newcomer less. Sorry but not sorry. If somebody calls
> >>> > this "gating", I don't think they see the nuances enough. Yeah, call
> >>> > it a gate if you want ...
> >>> >
> >>> > That is why I agree with Benedict here, he said:
> >>> >
> >>> > "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".
> >>> >
> >>> > What is wrong about this?
> >>> >
> >>> > Look at this contributor (1). This is an excellent example. 10 patches
> >>> > in fast cadence three weeks ago. We never heard about this person
> >>> > before nor after the patches were created. What about hitting a ML
> >>> > saying "hey, guys, I have a set of patches which scratch my itches,
> >>> > can you take a look, please?". I don't know ... just be a bit ...
> >>> > human about all of this? The maintainers are people too. I am not
> >>> > obliged to take in and cooperate with whoever comes by, dumps their
> >>> > stuff and then they ... wait. Well, so wait. See where you got three
> >>> > weeks after? Nowhere.
> >>> >
> >>> > Caleb put it nicely, we are "only" humans.
> >>> >
> >>> >
> >>> > On Mon, Sep 28, 2026 at 2:51 PM Shailaja Koppu via dev
> >>> > >
> >>> > > Hi Stefan,
> >>> > >
> >>> > > From personal side, I completely agree with you. I am giving potential options only to address concerns like - new contributors overwhelming the community with AI generated PRs just to show as add-on in their profile and vanish after that, or purely AI opened PRs without developer review or understanding. But the later can happen with anyone including committers due to workload/deadlines or misled by AI etc. Also, someone can copy a AI generated patch line by line skipping comments, which looks like a handwritten code.
> >>> > >
> >>> > >
> >>> > > Thanks,
> >>> > > Shailaja
> >>> > >
> >>> > >
> >>> > >
> >>> > > >
> >>> > > >> - Only Cassandra committers may submit AI-assisted PRs. This would mean new contributors first write and understand code without AI before becoming committers; or
> >>> > > >> - Contributors may submit AI-assisted changes in a component/subcomponent only after they have submitted at least one non-AI PR in that component/subcomponent.
> >>> > > >
> >>> > > > I am not sure if I am missing something but can you all explain in
> >>> > > > simple terms how is this actually enforceable in practice?
> >>> > > >
> >>> > > > "Only Cassandra committers may submit AI-assisted PRs" - there is no
> >>> > > > restriction who can create a PR and how. It is not like we see that a
> >>> > > > PR is created with heavy AI usage, then we check if a contributor is a
> >>> > > > committer and when they are not we comment on that PR saying - "hold
> >>> > > > your horses mate, we checked the list and you are not a committer,
> >>> > > > sorry, we have to close this".
> >>> > > >
> >>> > > > If a PR is crafted "carefuly" then it might look like a completely
> >>> > > > legitimate piece of work while it is still 100% prompted and the
> >>> > > > author does not have a clue what they did. I mean ... how do you make
> >>> > > > the difference between what is "real" and what is AI-driven 100%? I
> >>> > > > think that even if we "guessed" which one is which, the possibility to
> >>> > > > see this is being progressively erased as this tech is evolving and we
> >>> > > > will eventually not have a clue.
> >>> > >
>
>
