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]> 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]> > 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]> >> 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]> 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 >>> >>>>>> >>> >>>>> >>> >>> >>> >>> >>> >> >>> >>> >>> > -- Dmitry Konstantinov
