It seems the problem here is that, as frequently happens, we all have different backgrounds and priorities, and we are currently discussing where to draw the line between speed and stability.
On one side, we have people who are committed to run huge clusters in production, where even low-probability issues can happen simply because of the scale. Their main priority is to keep those systems healthy and avoid spending nights on call, so they naturally want bulletproof stability, even at the cost of slower feature development. On the other side, there are people with more of a startup-like mindset who want to move fast, avoid falling behind, and are more willing to accept some additional risk. And there is a wide range of positions in between. I would put myself somewhere in the middle, with a slight tendency towards the safer side. So the question is: how do we find a position that is acceptable to both groups? Maybe we should look at the extremes and then evaluate different points in between, to see where the most reasonable balance lies. For example, for me: 1. The maximum level of risk I am currently comfortable with for an AI-max direction would be the Linux policy for the CORE part of Cassandra: https://docs.kernel.org/process/generated-content.html Here, by "understand", I mean that I understand what each line of code does and why it is needed — i.e. I have read it before sharing it — and I understand the existing code context that I am touching in my patch. Yes, I realise that it is difficult to introduce formal criteria for such "understanding". 2. I am more relaxed when it comes to tests, build infrastructure, and tooling (e.g. nodetool). By "understand" here, I am pretty satisfied with being able to understand the overall ideas and see that there are no obvious hazards, without necessarily being able to explain exactly what every line of code does without some extra thinking or checking. 3. I am in favour of automatic review as a prerequisite — both as assistance for any review and as part of self-review before publishing changes. This is actually what I already do in practice. 4. I am against fully automatic review with no human involvement at all Of course, it is much easier to have code reviewed fully automatically: we don't have to wait for anyone, and we can deliver features very quickly. But I am not convinced that this model works well in the long term for an active, dynamically evolving project with many interacting and sometimes conflicting requirements. We also frequently talk about how important the community is in open source, and code review is one of the mechanisms through which that community is built and maintained. It is actually how I got to know the majority of people here. If we end up with a common repository where everyone uploads code and everything is reviewed solely by AI, I'm not sure I would call that a community anymore. Another thought: we have a way not just try to accept risks but to reduce them actively as well by introducing more advanced safety nets first, such as static code analysis, architecture fitness functions, better test coverage, green CI(yes, I can talk about it forever but I feel pain each time when I see status of our CI jobs 😢 ), and review guidelines/prompts for specific subsystems (like: https://github.com/sashiko-dev/sashiko/tree/main/third_party/prompts) P.S. While writing this, I realised that I had seen something similar before: the conflict between development and IT operations, where Google found a way to address it, at least to some degree, through SRE and the concept of error budgets. On Thu, 24 Sept 2026 at 11:18, Benedict Elliott Smith <[email protected]> wrote: > Hi David, > > Thanks for raising your concerns. Unfortunately, I think the main topics > you raise regarding ASF principles are highly sensitive to your priors. For > me they were unconvincing, and I would be comfortable making sincere > arguments in direct opposition to yours - that you would perhaps find > equally unconvincing. I suspect this line of argument will be highly > unproductive for all involved, and if you really want to pursue it I would > ask that we do it offline to avoid polluting an already busy conversation. > > You raise another concern that I think falls into the category of “fine > tuning the text” - namely how we handle shallow and localised bug fixes. I > would be happy adding a clear entry to the “Permitted” section for this. No > doubt there are many refinements needed to the Restricted text as well, > that might also capture some of your concerns. > > You may have raised some other issue I missed - please do highlight > anything else you want to litigate. > > > On 2026/09/24 04:54:50 Caleb Rackliffe wrote: > > I’d support something that boils down to roughly this: > > > > > > > > 1.) 2 committers must understand an LLM-assisted change before it > commits. > > (Perhaps separately we can explore the question of why we haven’t added > any > > new committers to the core project for about a year. I’m also still not > > entirely sure if it’s acceptable within our guidelines for a committer > to +1 a > > patch after delegating review.) > > > > > > > > 2.) Patch authors must demonstrate enough understanding to discuss their > own > > patch, whether or not parts of it are generated by an LLM. > > > > > > > > 3.) The “Assisted-by” tag should be used to indicate any non-trivial LLM > usage > > in the generation of a patch, just like we have used Co-authored-by > > historically. > > > > > > > > 4.) Comments and other things that aren't the actual code (but could sow > > confusion) should be held to the same standard we'd expect from a human > > writer. If we don’t yet agree on that standard, we can formalize enough > of it > > to guide both humans and LLMs. > > > > > > > > > > > > > On Sep 23, 2026, at 5:39 PM, David Capwell via dev > > > <[email protected]> wrote: > > > > > > > > > > > Dmitry, thanks so much for sharing; I agree its a great talk to > listen to. > > > > > > > > > > > > > > > > > > > >> On Sep 23, 2026, at 3:03 PM, Dmitry Konstantinov <[email protected]> > > wrote: > > > > >> > > > > >> > > > > > >> > > > > >> > Think this couldn't happen to us? Already has: > > <https://github.com/ferrosadb/ferrosa>. > > > > >> > > > > >> > > > > > >> > > > > >> < > https://github.com/ferrosadb/ferrosa/blob/main/CONTRIBUTING.md#what-we- > > dont-accept> \- it is interesting that even there we have: "What We Don't > > Accept: Code generated by AI tools without human review and > understanding. > > We're happy for contributors to use AI as an assistant, but the > contributor > > must understand and stand behind every line they submit." > > > > >> > > > > >> > > > > > >> > > > > >> On Wed, 23 Sept 2026 at 22:35, Dmitry Konstantinov > > <[[email protected]](mailto:[email protected])> wrote: > > > > > >> > > > > >>> An interesting Linux Kernel Report talk has just come out, and it’s > quite > > relevant to our discussion: < > https://www.youtube.com/live/3KAcS05H31Y?t=1242s> > > > > >>> > > > > >>> > > > > > >>> > > > > >>> On Wed, 23 Sept 2026 at 22:09, Aleksey Yeshchenko via dev > > <[[email protected]](mailto:[email protected])> 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]](mailto:[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 > > > > >>>>>>>> > > > > >>>>>>>> >>>>>> > > > > >>>>>>>> > > > > >>>>>>>> >>>>> > > > > >>>>>>>> > > > > >>>>>>>> >>> > > > > >>>>>>>> > > > > >>>>>>>> >>> > > > > >>>>>>>> > > > > >>>>>>>> >> > > > > >>>>>>>> > > > > >>>>>>>> > > > > > >>>>>>>> > > > > >>>>>>>> > > > > > >>>> > > > > >>>> > > > > > >>> > > > > >>> > > > > > >>> > > > > >>> > > > > > >>> > > > > >>> \-- > > > > > >>> > > > > >>> Dmitry Konstantinov > > > > >> > > > > >> > > > > > >> > > > > >> > > > > > >> > > > > >> \-- > > > > > >> > > > > >> Dmitry Konstantinov > > > > > > > > > > > > > > > > -- Dmitry Konstantinov
