+1 on the proposal, but I would also prefer to adopt something like Rusts policy
/Marcus On Wed, Sep 23, 2026 at 10:08:36PM +0100, Aleksey Yeshchenko via dev wrote: > This day was bound to come *eventually*, but this does need to be settled. > > I have a lot of opinions on this subject, like everyone else does (and their > moms). And none of them are fresh and novel. Just as tired as everyone else's. > > That said, I'll try to compose a proper response with some of the less tired > ones by the end of the week. > > In the meantime, I am +1 on this proposal, though my preferred option would > be to adopt Rust's, which is stricter, more or less as is > (https://forge.rust-lang.org/policies/llm-usage.html). > > -- > AY > > > On 23 Sep 2026, at 21:39, Caleb Rackliffe <[email protected]> wrote: > > > > > My understanding is that we don’t actually require that any reviews are > > > performed by committers. Only that two committers +1 a patch, confirming > > > they believe the relevant standards have been met, which could be via > > > purely non-committer reviews that they each trust to have done the work. > > > > That's interesting. My understanding of this has always been that 2 > > committers had to have an understanding of the patch, either via authorship > > or review (aided by AI or not). > > > > On Wed, Sep 23, 2026 at 2:16 PM Patrick McFadin <[email protected] > > <mailto:[email protected]>> wrote: > >> I was waiting for this moment to hit our project and I'm glad we're here. > >> I am deeply concerned for our project and its future, as we have > >> increasingly made it difficult to contribute. I had hoped that this new > >> era of software tools powered by AI would expand the project's reach and > >> bring more diverse thoughts and ideas. This policy proposal is the exact > >> opposite of what we need. We have been sitting on a Cassandra 6 release > >> alpha for months. We need to accelerate and embrace new ways of being or > >> be left behind. As I read that policy, my first and gut level reactions: > >> > >> - It comes across as elitist and class protectionism. Committer should > >> not be special but this proposal makes that designation even more sacred. > >> - It signals that our project is so fragile that only a few people > >> "Really understand it" That's some SQLite vibes right there. > >> - Trying to fix a problem that doesn't exist > >> > >> Sadly, i think this policy change would also exclude a lot of comitters. > >> > >> We aren't alone in this moment. The Linux project just went through this. > >> You can find the thread with a simple Google, but similar hard feelings > >> were being expressed "AI is going to ruin our project!", "The unwashed > >> masses are going to contribute terrible code!", "We have to protect our > >> precious status as Linux maintainers!" Linus being Linus, was deeply > >> invloved and they adopted a super simple statement that covers all bases. > >> Human or Human using AI. “You are expected to understand and to be able to > >> defend everything you submit.” Love that. > >> > >> In the larger picture, I'll restate. I'm worried for our project. In late > >> 2025(Opus 4.5 IYKYK), early 2026, AI coding LLMs turned a real corner and > >> in the hands of somebody that knows how to build software, this tool is > >> like jet fuel. Here's some examples of new projects being hyper fueled by > >> AI coding tools. > >> > >> Apache Iggy - Complete rust replacement of kafka. Crazy fast velocity > >> Turso - Rust re-write of SQLite > >> Bun - Rust re-write of itself from Zig. > >> > >> Think this couldn't happen to us? Already has: > >> https://github.com/ferrosadb/ferrosa. Ben is using it to power his own > >> startup, but it was him alone using a ton of local AI coding agents. He > >> even implemented Accord. Yeah... > >> > >> The cracks are already starting to show. There is a black market economy > >> of Cassandra patches happening now. Not going to name names or call people > >> out, but there are fixes and optimizations living in branches outside of > >> the Cassandra project. Why? I'll use myself as an example. I fixed a nasty > >> bug I ran into with TCM a few weeks ago. Wrote the tests. It passes CI and > >> lives in my personal branch. I'm sitting here really wondering if I want > >> to go through the ritual humiliation of being roasted for using AI to fix > >> it. Me. I am worried about contrinuting code the Cassandra. What the hell > >> does that say? > >> > >> I have my CQLite project that I've been doing a release around once a > >> month. I would love to donate that to the Cassandra project but I wouldn't > >> if it essentially killed any progress. > >> > >> My larger counter proposal would be to: > >> - Adopt the “You are expected to understand and to be able to defend > >> everything you submit.” approach the Linux project has adopted. > >> - Loosen up the contributor process and our worry on trunk. Let 1000 > >> flowers bloom and bring it in. > >> - And finally, to give some people more peace of mind and open more > >> doors, adopt what other projects have done and provide more pluggability. > >> Let new ideas have an easy place to connect. > >> > >> We are at a fork in the road. What are we going to do? And then I have to > >> ask myself, what am I going to do as a contributor? > >> > >> Patrick > >> > >> On Wed, Sep 23, 2026 at 6:16 AM Blake Eggleston <[email protected] > >> <mailto:[email protected]>> wrote: > >>> I’m not necessarily opposed to having a policy, but so far we have some > >>> specific proposals addressing a problem statement that’s very nebulous. > >>> What is the community failing to do on its own that we’re trying to > >>> correct with policy? What outcomes are we trying to create or prevent? > >>> Having some examples and specific problems to discuss would help focus > >>> the conversation. > >>> > >>> On Wed, Sep 23, 2026, at 4:34 AM, Shailaja Koppu via dev 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] <mailto:[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] > >>>> >>>> <mailto:[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]> <mailto:[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]> <mailto:[email protected] > >>>> >>>>>> <mailto:[email protected]>>> wrote: > >>>> >>>>>> > >>>> >>>>>> On Tue, Sep 22, 2026 at 3:28 AM Benedict <[email protected] > >>>> >>>>>> <mailto:[email protected]> <mailto:[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 > >>>> >>>>>> > >>>> >>>>> > >>>> >>> > >>>> >>> > >>>> >> > >>>> > >>>> >
