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č <[email protected]> wrote: > > 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. > > (1) > https://github.com/apache/cassandra/pulls?q=is%3Apr+state%3Aopen+author%3Acheeeee > > On Mon, Sep 28, 2026 at 2:51 PM Shailaja Koppu via dev > <[email protected]> wrote: > > > > 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 > > > > > > > > > On Sep 28, 2026, at 12:23 PM, Štefan Miklošovič <[email protected]> > > > wrote: > > > > > >> - 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. > >
