I want to start this reply with 3 points I do not think should be controversial as its our responsibilities as PMCs.
Our job is to maintain and foster the community Our job is to help grow new maintainers "The community welcomes contributions from anyone who acts in good faith and in a respectful manner, and who adds value to the project." Several of the points listed I feel violate either 1 or multiple of these responsibilities. > Core code changes made by LLM may only be proposed by contributors with > demonstrated expertise > This to violates fostering the community and growing new maintainers. Why? We start our interactions with someone new and excited to contribute to the project saying that their contribution isn't welcome if they used AI. This could be a Cassandra DB admin who is trying to address a pain point; we are directly saying their contribution is not welcome because they have not "demonstrated expertise". This also violates the apache model as a "good faith" actor sent a valid contribution which we turn away because of our own biases. > Core code changes made by LLM require an additional reviewer > This violates fostering the community as it directly impacts every member who wishes to use AI to help submit a patch. This pushes contributors into 2 classes: those that author by hand, those that were aided by AI. I do not feel creating a second class of people is a great way to foster a healthy community. There are 2 recent examples that I assume inspired this thread: Bug fix patch for cursor compaction - the feedback post merge was never about the quality of the code, people disliked the fact opus 5 left comments in its own opus 5 way CEP to improve ZCS - the general feedback is positive but one push back is that the work allegedly used AI... the technical aspects of the patch were not the focus In both cases the authors of such contributions are PMC members and we rely on public shaming them for usage (or perceived usage) of AI. Is this really a good way to foster a healthy community or does it push contributors away? Personally I see the contribution as the contribution and the fact AI was used is irrelevant. Are we encouraging excitement to contribute to our project? Does the contribution add value? Are we fostering the community? If these answers are yes, why does it matter if someone used AI? I am not impacted by that call as I assume reviewers will make sure the contribution is up to our standards and conforms to the way Cassandra does things. > All public prose must be human authored. This includes inline comments, docs, > posts to Jira etc. > It feels like opus 5 has really tainted things... that was such a horrible model... and it only lived for 8 weeks as it got replaced the same day this thread started! Claude models have their claudism and take more work to create docs worth a humans time to review; but you can still get to the point where the output is quality for the community... Other models are much better: kimi is known for being much better at document writing, and my usage of gemini is so refreshing after using opus 5... my eyes are no longer bleeding! If we have personal feelings about how documents should be written we should... document those feelings? This can then be fed into the AI models so they can try to comply with our feelings. Flat rejecting feels like a hasty generalization and short sighted. This also violates fostering the community and all contributions are welcome as long as they were in good faith. Historically our docs have been neglected, and now people are excited to bring life to them and to really make sure we have good quality docs (Lorina was only able to do so much). Telling contributors that their contribution isn't welcome even if the quality of the contribution is high, just because it used AI; I do not think this is healthy for the community. > Break the community and knowledge-building aspect of patch review, since the > contributor is not clearly learning from the feedback process > I partially agree with you and do think for personal growth the usage of AI can/will hurt you; but is this justification for a policy that everyone must comply with? I try to encourage people not to use AI for their own personal growth and have been trying to find ways to soften the "no ai" mantra... its something i currently struggle with leading a team. When trying to step back and ask about policy changes I have to find places where I feel a counter example breaks the rule. A recent example that involves me is CASSANDRA-21412; my goal is to get CI stable, not to learn Journal. During shutdown there was a race condition in Journal that had a use-after-free which lead to the JVM hard crashing, I wanted this fixed to have a more stable CI so used AI to add reference counting to it. Aleksey reviewed the patch and pointed out that journal does this code path single threaded so the race must happen during shutdown so reference counting isn't needed and better coordination during shutdown is the better architectural solution; given this feedback I resent the patch and got his +1. I sent a "good faith" patch to someone far more knowable in the specific code base than myself, listened to feedback, and got the patch to the desired state (not merged due to failing tests I have to triage... its so painful living in a world where CI is constantly failing... I do my job and triage each and every test, its a slow and manual process... for a background task that isn't my priority); why does it matter that I used AI to write the patch for me? As stated again, my goal is not to learn Journal so "the contributor is not clearly learning from the feedback process" is true for me; i'm not trying to learn Journal, i'm trying to have a passing CI. Under the "restricted" section of the first email there is "and area" which says that my contribution is not welcome; I am not a expert in Journal nor do I want to be, there for my contribution is not welcome... that is the message I am getting. > Does not demonstrate expertise, commitment or that they can or will maintain > the patch > I do not agree with this take at all. I think Mitchell Hashimoto said it best [1] > The "whiteboard defense:" I should be able to pull you aside at any moment > and ask you to explain any customer-facing system you've shipped. You should > be able to clearly explain how it works and defend the decisions you made. > This is my benchmark for responsible AI usage. > If the AI wrote 100% of the code, but the author fully understand it and can argue any aspects of it; why does it matter? If the author listens to feedback, and is sending different patches over time; why does it matter that they used AI? You can have AI write 100% of the patch, show expertise in it, show commitment to the patch and the community, and show that you can maintain the patch... the usage of AI does not disprove these nor does it give you information about the human behind the keyboard pressing buttons. This reply was written by hand without the use of AI. I also intentionally choose not to have AI review this response so its as "human authored" as possible. Sources: [1] https://x.com/mitchellh/status/2100249348345057389 https://apache.org/foundation/governance/pmcs https://community.apache.org/pmc/responsibilities.html https://community.apache.org/pmc/adding-committers.html https://community.apache.org/apache-way/apache-project-maturity-model > On Sep 23, 2026, at 4:34 AM, Shailaja Koppu via dev > <[email protected]> wrote: > > Benedict, > > Thanks for clarifying. My concern still remains. This criteria would be > difficult to define and apply consistently. What counts as “similar” scope or > area, “mostly correct,” or sufficiently independent work? More importantly, > how do we prevent such vague criteria from creating an informal hierarchy > where some contributors work is routinely accepted while others is routinely > rejected? > > If the intent is to limit AI-assisted code changes to Cassandra contributors, > or to contributors who have previously worked in that component without AI, > that would at least be clear and enforceable. > > > > >> On Sep 23, 2026, at 12:01 PM, Benedict Elliott Smith <[email protected]> >> wrote: >> >> Core code changes >> Chris: Do you object to the first or second line you quote? Because the >> first line is effectively motivation for the second line, and can be removed >> (or more clearly combined). If it’s the second line, then I do not think >> this is an unreasonable expectation, and we can get into a proper debate >> about it. >> >> Shailaja, since you only snipped the first sentence, your concerns might >> also be mostly answered by this clarification? “Minimal third-party >> guidance” implies you have some concerns about the second line, but all of >> our policies have some ambiguity because legalese is even worse. I don’t >> think the ambiguity here would be challenging to navigate though we can >> certainly refine it. This specific snippet is meant to convey an expectation >> that a contributor has autonomously produced patches of similar scope that >> were mostly correct, so that they have demonstrated the level of >> understanding necessary to guide another party to a successful patch (i.e. >> an LLM in this case). >> >> >> On 2026/09/23 10:54:16 Benedict Elliott Smith wrote: >>> Thanks everyone for your input so far. I’ll respond in brief to the main >>> themes, in (mostly) separate emails so they can each have their own debate >>> chain. >>> >>> Should we have a policy (Blake/Josh*/Jon/Dinesh) >>> I think we would all agree that LLMs represent the biggest change to this >>> community (and software more generally) since its inception, and we all now >>> have enough experience with the technology to have formed opinions about >>> how it is best managed. We also evidently have not all arrived at the same >>> conclusions. In this situation, it would be an abdication of our >>> responsibilities as a management committee to not agree *some* policy. >>> >>> I intend to conduct straw polls as the discussion evolves, so if you prefer >>> an alternative policy - or modifications to this policy - I would encourage >>> you to make those alternative proposals. >>> >>> *Veto/Consensus (Josh) >>> It was fair to call out my poor use of language on this topic, so let me >>> rephrase a little. The community is built on consensus, and work should not >>> be merged when there are outstanding concerns to address. The explicit -1 >>> should only be used rarely, because the prior expectation should prevent it >>> ever being needed. I (and others) have outstanding concerns on LLM >>> generated work that can only be addressed through this process right here, >>> so to merge such work while maintaining the community’s consensus we must >>> agree some policy. >>> >>> >>> >>> On 2026/09/23 09:58:27 Shailaja Koppu via dev wrote: >>>> I am strongly -1 on this >>>> - Core code changes made by LLM may only be proposed by contributors with >>>> demonstrated expertise >>>> That creates a new, subjective privileged class of contributors and turns >>>> a tool choice into an eligibility test. Who decides whether expertise has >>>> been “demonstrated,” what counts as “minimal third-party guidance,” and >>>> how could those judgments be applied consistently or fairly? >>>> >>>> Apache already has a better model, anyone may contribute, trust and >>>> additional repository privileges are earned transparently over time. The >>>> ASF describes its communities as flat, and says that newcomer ideas have >>>> as much input as those from original creators. We should not add a >>>> separate, informal hierarchy in which certain people may use common >>>> development tools while others may not. >>>> >>>> >>>> >>>> >>>>> On Sep 23, 2026, at 6:33 AM, Chris Lohfink <[email protected]> wrote: >>>>> >>>>> >>>>> - 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 >>>>> >>>>> I really don't like this one or its wording. Definitely too "the peasants >>>>> are getting uppity lets build a wall". Lets not let a subjective thing >>>>> like demonstrated expertise (who decides that?) be if it's ok or not. >>>>> Hold the same standards for code quality and process for it all. I don't >>>>> want this to be: only people on the storage team in Apple can use AI. >>>>> >>>>> Chris >>>>> >>>>> On Wed, Sep 23, 2026 at 12:16 AM <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>>> I agree with Stefan and think this is both a reasonable and thoughtful >>>>>> proposal. >>>>>> >>>>>> Here are some things I like about it: >>>>>> >>>>>> – It outlines areas where LLM usage is unambiguously useful to the >>>>>> project’s developers and users. >>>>>> – It defines a spectrum of recommendations and cautions. >>>>>> – The only prohibited areas are extremely narrow and say nothing about >>>>>> code at all. >>>>>> >>>>>> Some in this thread are responding as if this proposal seeks to prohibit >>>>>> or sharply limit use of LLMs. In fact, it’s one of the most open and >>>>>> welcoming I’ve seen for an OSS project of our size where many are >>>>>> adopting policies that simply ban them entirely. I’ve re-appended the >>>>>> proposal below my message as it seems to have been lost in threaded >>>>>> replies, and would encourage folks to give it a second read. >>>>>> >>>>>> Some brief thoughts based on my own use of LLMs: >>>>>> >>>>>> – I find them fantastically useful for reviewing and identifying >>>>>> problems that have slipped through review - primarily via Alex Petrov’s >>>>>> /deep-review skill, which I have running in a VM in a loop executing >>>>>> over every new commit in the project as of a few days ago. I will be >>>>>> posting a few hand-authored Jira tickets based on findings that appear >>>>>> legitimate to me. For now, the loop is posting them as issue drafts for >>>>>> my own review on my personal fork which you can find here: >>>>>> https://github.com/cscotta/cassandra/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug >>>>>> – They’re great for enabling use of model checkers and formal methods >>>>>> where such work would have previously been prohibitively expensive, such >>>>>> as Blake’s work on a TLA+ proof of aspects of Mutation Tracking and >>>>>> Benedict/Fedor’s work on a machine-checkable proof of the Accord >>>>>> protocol in Lean. >>>>>> – They are stunning for allowing me to experiment with ideas that would >>>>>> have otherwise been a summer internship’s scope of work. Some examples >>>>>> include an io_uring prototype, exploring the impact of page-aligned >>>>>> compressed chunk sizes, an API shim bridging the 3.x and 4.x Java >>>>>> Drivers, and potential enhancements to Zstandard. >>>>>> – And they shine when given grunt-work that is critical to the project >>>>>> but a miserable labor for humans, such as triaging, reproducing, and >>>>>> root-causing flaky tests, which David Capwell now has running in a loop >>>>>> to help us improve CI stability in the project. >>>>>> >>>>>> I never thought I’d be so positive on what’s possible via language >>>>>> models a year ago. At the same time, I also agree that they present >>>>>> challenges and risks that can be managed through thoughtful discussion >>>>>> and policy. Some of the concerns that I think are important to guard >>>>>> against include: >>>>>> >>>>>> – Asymmetry of effort between author and reviewers: As token-generating >>>>>> machines, LLMs can generate diffs of extraordinary size very rapidly. >>>>>> /deep-review is great for chewing through diffs and identifying defects. >>>>>> But it should be used by the contributor themselves to identify issues – >>>>>> not to replace the role of the reviewer with more electricity. The role >>>>>> of the reviewers extends beyond identifying and highlighting defects. It >>>>>> encompasses architecture, harmony with the existing codebase, thinking >>>>>> ahead to future evolution of the project, and replicates context on the >>>>>> project as new code is committed. These functions cannot be automated >>>>>> away. >>>>>> – Hesitancy of authors to engage manually with code they have generated: >>>>>> This is not specific to Cassandra, but it is a behavior that I have seen >>>>>> in several “highly-electric” projects. There’s a bimodal tendency toward >>>>>> code that is entirely generated or entirely human-authored - but it is >>>>>> rare for someone to prepare an AI-authored patch to take an offramp and >>>>>> spend a significant amount of time refining the work by hand in an IDE. >>>>>> This hesitancy toward human participation in authorship of LLM-generated >>>>>> code is very concerning to me. >>>>>> – Harmony with the existing codebase: Due to the tunnel-vision of >>>>>> context windows, LLMs are generally unaware of conventions and norms >>>>>> present in codebases and very frequently reinvent concepts in a >>>>>> generation turn to suit a goal without view of the project’s overall >>>>>> architecture. This results in a profusion of messy and duplicated >>>>>> concepts that gradually sprawl about a codebase. >>>>>> >>>>>> Again, none of these are grounds for prohibition of usage of language >>>>>> models in developing the project. They’re just problems we need to bear >>>>>> in mind and guard against – and I think the proposal is designed to do >>>>>> just that. >>>>>> >>>>>> I’m thrilled by the potential of LLMs to improve Apache Cassandra and we >>>>>> already see it happening through a vast number of issues that are being >>>>>> reported and fixed. But there’s also danger in taking ATVs down a hiking >>>>>> trail full of people. >>>>>> >>>>>> Regarding the prohibition on prose, I’ll simply say: I recently found >>>>>> myself in a scenario where I found a Claude-authored document so >>>>>> inscrutable that I piped it back into a model, directed it to rewrite it >>>>>> in ASD-STE100, read it myself, and responded based on the summarization. >>>>>> As a humanities grad, this is probably the worst language crime I have >>>>>> committed. But it was in response to language that was itself so >>>>>> idiosyncratic that it was unreadable to me in its original form. I hope >>>>>> this never happens in the Apache Cassandra project. >>>>>> >>>>>> I’ll close with a quote from an excellent article written by Colin >>>>>> Breck, an engineer who works on large-scale data systems: >>>>>> https://blog.colinbreck.com/i-dont-want-to-read-what-you-didnt-write/ >>>>>> >>>>>> Colin wrote: >>>>>> >>>>>>> I don’t want to live in a world where you use AI to summarize something >>>>>>> important into unreadable text, and then I use AI in an attempt to >>>>>>> decipher it. I want to hear you, imperfections and all. I want your >>>>>>> interpretation of aesthetics, beauty, quality, relationship, time. I >>>>>>> want to know how you feel. I want you to cut through and tell me what >>>>>>> really matters. >>>>>> >>>>>>> Intentional writing will likely become more valuable. People who write, >>>>>>> and write to think, to think deeply and carefully, or to create, to >>>>>>> share, or to capture something important without explicitly expressing >>>>>>> it will continue to write and produce original work. The people who >>>>>>> never were writers will use AI to produce lots of text. >>>>>> >>>>>> I hope that our culture can remain one of intentional writing and >>>>>> intentional engineering. I enjoy reading the voice of the author in >>>>>> comments, code, and tickets in Cassandra – the different ways we use >>>>>> language based on where we grew up and how we learned English, the >>>>>> translated idioms from our various backgrounds, and terse comments that >>>>>> recognize the difference between code whose function is obvious and what >>>>>> warrants genuine exposition. When I read code in Cassandra, it’s a >>>>>> delight to recognize the author based on their writing style before >>>>>> flipping on `git annotate` to reveal the origin. >>>>>> >>>>>> I’d encourage folks to re-read the original proposal below. It is very >>>>>> permissive. The guidance strikes me not just as reasonable, but >>>>>> genuinely important to maintaining the health of the project. >>>>>> >>>>>> – Scott >>>>>> >>>>>> ===== >>>>>> 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>" >>>>>> ===== >>>>>> >>>>>>> On Sep 22, 2026, at 9:13 PM, Dinesh Joshi <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> On Tue, Sep 22, 2026 at 3:28 AM Benedict <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> 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 >>>>>>> >>>>>>> I am -1 on this. This sounds like gate keeping attempt. It narrowly >>>>>>> limits the pool to a few people on the project that have historically >>>>>>> contributed to certain parts of the codebase. This policy will prohibit >>>>>>> skilled software engineers with domain expertise from proposing LLM >>>>>>> assisted changes simply because they have not contributed to the >>>>>>> project. This is unrealistic and a net negative for the project to >>>>>>> attract talent and grow our community. >>>>>>> >>>>>>>> - Core code changes made by LLM require an additional reviewer >>>>>>> >>>>>>> Can you be more precise what is this in addition to? How many total >>>>>>> reviewers do you expect and what is the purpose of additional reviewer? >>>>>>> and why? >>>>>>> >>>>>>> Taking a step back - what are you trying to solve here? >>>>>>> >>>>>>> Dinesh >>>>>>> >>>>>> >>>> >>>> >>> >
