My +1 was to keeping it simple and just go with Blake's simple straightforward guidelines.
On Sat, Sep 26, 2026 at 9:47 AM <[email protected]> wrote: > We have multiple active proposals on this thread but it’s unclear which > proposals "+1’s” should be attributed to. > > From a threaded reading based on which messages reply to which: > > - Alex’s reply with a +1 is to Benedict’s email and original proposal. > - Jon’s reply is to Blake’s email but says “to simple straightforward > guidelines” (unclear if referring to Blake’s proposal or simple guidelines > in general). > - Dinesh’s reply is to Jon’s, which carries ambiguous attribution to > Blake’s proposal or simple guidelines. > > > To keep our discussion tidy and positions clear, can I propose clearly > attaching a +1 to a specific proposal or position in the thread so there’s > no ambiguity as to what each of us support? > > – Scott > > On Sep 26, 2026, at 9:32 AM, Dinesh Joshi <[email protected]> wrote: > > +1 > > On Sat, Sep 26, 2026 at 9:21 AM Jon Haddad <[email protected]> > wrote: > >> +1 to simple straightforward guidelines >> >> >> >> On Thu, Sep 24, 2026 at 1:01 PM Blake Eggleston <[email protected]> >> wrote: >> >>> I propose the following guidelines: >>> >>> >>> 1. Contributors must have a comprehensive understanding of the >>> patches they contribute >>> 2. Reviewers must have a comprehensive understanding of the patches >>> they approve >>> 3. Reviewers must have experience with the affected systems >>> commensurate with the risk and complexity of the patch. >>> >>> >>> This makes the expectations that have been mostly implicit explicit, >>> doesn’t gate keep on the contributor side, doesn’t tell people how to do >>> their work, and gives the subject matter expert, the reviewer, the latitude >>> to decide what standards make sense for the patch they’re reviewing. >>> >>> >>> On Thu, Sep 24, 2026, at 12:01 PM, Josh McKenzie wrote: >>> >>> Apache Cassandra was fundamentally undeployable for four years between >>> Nov 2015 - 2019. >>> >>> CASSANDRA-8099 was a maximal manifestation of a specific approach to >>> engineering and calendar constraints we've seen time and again on the >>> project; I don't want us to conflate things here. That was a herculean >>> monolithic body of work performed in inhuman conditions (in vim!) that was >>> ultimately so invasive, all the unit tests in the code-base were commented >>> out and Jake and I spent a grueling 1.5-2 months hand-rewriting basically >>> all the unit tests in that code-base to get things to even build and run, >>> much less pass. >>> >>> Massive blast radius changes that are un-sustainably complex, >>> under-tested, where we don't property, fuzz, check coverage, check >>> complexity, or A/B compare against a known good system (i.e. pre/post) >>> correctness testing are going to destabilize the database at any time under >>> any regime of tooling. We certainly could speed-run our way back into >>> destabilization with LLM's as they are a force multiplier for both the good >>> and the bad of one's engineering practices, but that's a solvable problem >>> by better defining what our bars of quality are (Definition of Done >>> anyone?) and holding ourselves accountable to delivering at that bar. >>> >>> On Thu, Sep 24, 2026, at 2:40 PM, David Capwell via dev wrote: >>> >>> >>> if you really want to pursue it I would ask that we do it offline to >>> avoid polluting an already busy conversation >>> >>> People are directly responding saying that they feel discrimination >>> currently and that the policy tries to codify that discrimination, so I >>> feel its 100% on topic. This thread has presented 0 evidence that LLM usage >>> has lowered the quality of contributions merged and has so far been vibes >>> and feeling; I have yet to see any evidence to justify such discrimination >>> so I will keep pushing back until such evidence is presented so we can have >>> a informed debate. >>> >>> 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. >>> >>> I will not sign off on cherry picking areas where "safe" to use a tool; >>> so no it does not capture my concerns. >>> >>> >>> I don't know if everyone remembers, but ten years ago Cassandra was full >>> of serious correctness and stability issues. Despite developing it, I would >>> not have run it myself or recommend that anyone use it. We have dug >>> ourselves out of that hole, but it took years of discipline and effort, and >>> we're still (deservedly) recovering our reputation. >>> >>> Let's use this new technology to improve the quality of our >>> contributions, not squander our hard-earned gains in the name of speed. It >>> will be hard to recover our reputation a second time. >>> >>> I do recall the 3.x line and put in a significant amount of effort to >>> harden it. There were behaviors I noticed after joining Cassandra that I >>> feel directly contributed to 3.0 and the decade of catch up; behaviors that >>> still linger in parts of the community today. >>> >>> As I look on trunk and look at committed code and trace back to PRs and >>> JIRA I see the following: >>> >>> - large patches approved without comments >>> - 0 evidence that tests were run >>> >>> I then look at our CI and see tests failing for months. As you start to >>> triage you start to see some of them show real issues; yet they linger for >>> months not being addressed... when CI is unstable it takes a lot of effort >>> to triage "did my patch break the test", and I have seen time and time >>> again people do not put in that effort, and shrug off as "its just a flakey >>> test"; then our CI failure rate grows. >>> >>> Non of this has anything to do with LLMs but LLMs running in this >>> environment is far more dangerous as there are not checks in place to "hold >>> the bar". I am all for raising the bar universally; expecting both humans >>> and LLMs to match that bar. >>> >>> 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. >>> >>> I can get behind this proposal but i would tweak it as 1/2 i don't think >>> really need to special case LLM usage >>> >>> 1. 2 committers must understand the change before it commits. >>> 2. Patch authors must demonstrate enough understanding to discuss >>> their own patch >>> >>> Nothing about those 2 need to be scoped to LLM usage and honestly >>> matches most PMCs I have talked to understanding of our bar (as Benedict >>> pointed out, the actual wording could be interpreted to allow rubber >>> stamping from committer) >>> >>> As for 3 I am cool with this. ASF recommends the same (it says >>> Generated-by but that discount's the human's effort) as its useful for >>> audits and tooling. Having Assisted-by tag should not imply anything >>> about the committed patch as it should have gone through the same bar we >>> all expect; its just for tools auditing. >>> >>> On Sep 24, 2026, at 10:37 AM, Aleksey Yeshchenko via dev < >>> [email protected]> wrote: >>> >>> Meant "doing away with", sorry. Non-native speaker with a headache here. >>> Thanks Caleb for spotting. >>> >>> On 24 Sep 2026, at 17:35, Aleksey Yeshchenko via dev < >>> [email protected]> wrote: >>> >>> P.S. I assume it's obvious from the text above that I don't believe that >>> getting away with human code review is a viable option. >>> >>> >>> >>> On 24 Sep 2026, at 17:37, Štefan Miklošovič <[email protected]> >>> wrote: >>> >>> Good call on checkerframework, we even have a patch for it. Work of >>> Jacek Lewandowski. We might just drive it to completion. Using AI for >>> finishing it would be quite ironic. >>> >>> (1) https://github.com/apache/cassandra/pull/2370 >>> >>> On Thu, Sep 24, 2026 at 6:19 PM Jon Haddad <[email protected]> >>> wrote: >>> >>> >>> There are some really good points being brought up about stability of >>> the codebase, maintainability, quality of reviews, correctness bugs, and I >>> agree with all of them. I think it would be helpful to take a step back >>> and consider how those bugs got there in the first place, how they were >>> fixed, and what we could do to further advance the codebase so they don't >>> creep back. LLMs can be used either with very tight guardrails, or in >>> what's effectively YOLO mode, and there's a big difference in the quality >>> of the results you get. >>> >>> One thing to keep in mind, a lot of the initial code in C* was added >>> without comprehensive testing. I hope we can all agree that it's a lot >>> easier to break code that doesn't have high quality tests. During the code >>> freeze, a lot of people people spent several years relentlessly finding and >>> fixing bugs. This was probably a pretty frustrating time for anyone who was >>> focused on fixing other people's bugs when they wanted to build features. >>> I think we should recognize the effort here and appreciate the foundation >>> that the project stands on now. I can understand how anyone involved with >>> this effort would be apprehensive about seeing years of their life swept >>> away by an agent that was driven by goal seeking to remove all the tests >>> that it broke instead of fixing them. >>> >>> When I picked up the work to improve cursor compaction, the first thing >>> I asked myself was how can I make sure I don't break this? How do I even >>> know it works properly? There were some tricky parts to the code, and I >>> really didn't want to come in and immediately break stuff. That's why I >>> started with an entire patch dedicated to adding test infra to it. 90% of >>> the patch was tests, and in my other cursor patches, it remains *at least* >>> 80% of my patches. It was a *lot* faster to add almost 10K lines of tests >>> that handled a byte for byte differential testing paired with harry to find >>> over 30 bugs that caused cursor to corrupt results. Range tombstones alone >>> were at least a dozen bugs, but I also found issues with static columns, >>> reverse ordering, etc. Randomizing schemas and data in burn tests to >>> generate different shapes of data, to ensure they all result in the same >>> output at the end. JMH tests to ensure there weren't performance >>> regressions, hours of profiling. These were all a *lot* easier to do with >>> the LLM helping me out. In the process I've found bugs that have been >>> lingering in the codebase for years. >>> >>> That's a long story, but hopefully we all agree that having >>> comprehensive tests is a great way to ensure that both humans and LLMs >>> don't break things that are working. >>> >>> The lesson: we need to keep improving our testing. Everything that we >>> touch, should be left in a better state than how we found it with regard to >>> test coverage. >>> >>> Test coverage isn't everything though, there's always little subtle bugs >>> that don't get found in testing, that can slip in despite our best >>> efforts. It's debatable if humans will be as good as agents for coding in >>> the long term, for spotting small defects. I sincerely doubt it. For the >>> time being though, we still have people involved. It's probably a good time >>> to start using more static analysis tools to identify problematic code and >>> to add this to CI. Dmitry had a suggestion recently for checkerframework >>> to detect leaking contexts, a problem he spotted when reviewing my branch. >>> It would be great to have that integrated into our CI and dev workflow so >>> we can simply avoid an entire class of bugs. >>> >>> There's also PMD, which is excellent for finding code that can be hard >>> to understand. I *highly* suggest you all run PMD to analyze for cognitive >>> complexity and high npath scores. This was made popular by the folks at >>> Sonar and I've found it to be an excellent feedback mechanism for >>> structuring code. The default max they set is 15, which is the point where >>> it starts to become difficult to verify something works without making a >>> massive investment. We've got areas in the codebase that are in the >>> hundreds, and some parts even higher. These have been contributed by >>> humans, and are all high risk points for both humans and agents to start >>> messing around with. They're also in some fairly critical areas that are >>> very likely to break, so I understand why people would not want an agent >>> anywhere near it. >>> >>> Unfortunately, it's not an easy problem to address. There's so many >>> places where the code is structured in a way that has so many branches, so >>> many conditions, that it's effectively impossible for a human to >>> understand, creating a fear of messing around in it. There's plenty of >>> areas that deserve extreme scrutiny, and we should be careful of what we >>> add, whether it's human or agent. >>> >>> The codebase today requires a high degree of internal knowledge to >>> navigate. There's land mines everywhere. We should be looking to make >>> conscious improvements by moving the code forward, so it's easier to make >>> changes to small, well tested components with minimal side effects. Not >>> making it harder for people to use the tools that aid in that process. >>> >>> Here's what we could do to achieve the underlying goal of not breaking >>> the DB: >>> >>> Add cognitive complexlity and npath via PMD as a feedback mechanism. >>> >>> Code that's hard to understand is hard to review. It's also hard to >>> test. Let's break down the complex code so more people can contribute, >>> safely. >>> >>> Add checkerframework to our tooling, >>> >>> Properly annotate the codebase for it and reduce the surface area that >>> things can break. Less brittle codebase = we can move faster. >>> >>> Use jacoco to find areas of the codebase with poor testing. >>> >>> Let's improve the test coverage there, LLMs are great for this. We have >>> a ton of static tests, these can become more dynamic, parameterized, and >>> leverage harry. >>> >>> Refactor parts of the codebase that have high cognitive complexlity and >>> NPath scores. >>> >>> This should be lowered over time to meet some high watermark, say 25 >>> maximum, although I'd prefer 15 which is where the Sonar folks settled. >>> >>> Move forward moving the codebase to a more modular structure >>> >>> We've talked about Gradle on and off - but it can really be a huge help >>> with incremental, modular builds. This is pretty easy to do with an agent >>> and we could have it done in a couple days. >>> >>> Enforce boundaries with ArchUnit >>> >>> If we want to enforce certain code boundaries, this is the way to do it. >>> Should not be part of manual review. >>> >>> Add LLM review for all incoming PRs before a human >>> >>> The goal here is to automate the initial part of the review process that >>> reviewers should spot, and raise the bar for the initial contribution. >>> When the code gets reviewed by a human, it should already have passed a >>> large variety of initial checks. This should shorten the review cycle and >>> result in higher quality patches. I've had Claude reviewing all my PRs in >>> my personal projects for a while now and it consistently gives great >>> feedback that I almost always incorporate. >>> >>> In my ideal world, we'd also auto-format all code >>> >>> Consistent formatting throughout the codebase would be amazing, but >>> that's just one man's dream. >>> >>> Hopefully there's at least a couple things in this list we could move >>> forward with in the short term, as it'll help improve the code quality >>> regardless of how it's created. >>> >>> Jon >>> >>> https://checkerframework.org/manual/#aliasing-leaking-contexts >>> https://www.sonarsource.com/docs/CognitiveComplexity.pdf >>> https://pmd.github.io/pmd/pmd_rules_java_design.html >>> >>> >>> >>> >>> >>> On Thu, Sep 24, 2026 at 7:38 AM C. Scott Andreas <[email protected]> >>> wrote: >>> >>> >>> From Benedict: >>> >>> “I don't know if everyone remembers, but ten years ago Cassandra was >>> full of serious correctness and stability issues. Despite developing it, I >>> would not have run it myself or recommend that anyone use it. We have dug >>> ourselves out of that hole, but it took years of discipline and effort, and >>> we're still (deservedly) recovering our reputation.” >>> >>> Expanding on this point for those who may not have been active in the >>> project at this time — >>> >>> Apache Cassandra was fundamentally undeployable for four years between >>> Nov 2015 - 2019. The database literally lost data if you ran a read-only >>> SELECT query ordered descending (C-14513, C-14515). If you haven’t read >>> these tickets before, please take a moment to do so. >>> >>> It took years of careful work via property-based testing, fuzzing, and >>> deterministic simulation to restore Cassandra’s status as a usable system >>> of record. Once 14513 and 14515 were identified, nearly 30 additional >>> critical data loss and incorrect response bugs were identified. >>> >>> It is essential for the project’s future that we don’t regress to this >>> state chasing AI-generated features motivated by fear. The fact that >>> examples cited in this thread which boast shiny features but have critical >>> shortcomings unknown to their author supports this argument. >>> >>> The most common path for large corpuses of AI-generated software is >>> elation and reveling in a feature matrix, followed by abandonment. >>> >>> I endorse this point: >>> >>> “Let's use this new technology to improve the quality of our >>> contributions, not squander our hard-earned gains in the name of speed. It >>> will be hard to recover our reputation a second time.” >>> >>> Patrick, I don’t want your note regarding a TCM issue to go unaddressed. >>> Please file a Jira ticket and the patch if you like. I can’t comment on the >>> patch as I haven’t seen it, but together we will solve the problem. >>> >>> – Scott >>> >>> On Sep 24, 2026, at 4:01 AM, Benedict Elliott Smith <[email protected]> >>> wrote: >>> >>> Hi Patrick, >>> >>> As I mentioned in my reply to David, I would be happy to create a carve >>> out for shallow and localised bug fixes in the "Permitted" section. Would >>> this alleviate some of your concerns regarding your ability to contribute >>> to the project? >>> >>> I appreciate your pointing out Ferrosa's Accord implementation however, >>> as it is a *great* example of the problems we're leaping into. I took a >>> look, and within about 30s found that the protocol is fundamentally >>> incorrect, having failed to address CASSANDRA-18365. This is despite >>> claiming to be tested with Jepsen that should in principle find this fault. >>> I followed up by using Claude to interrogate the implementation further, >>> and immediately found other serious correctness issues. >>> >>> I use LLMs daily now to help facilitate Accord development, and while >>> they are powerful they are NOT able to author the code themselves, even >>> when building upon a strong human-authored foundation. >>> >>> I don't know if everyone remembers, but ten years ago Cassandra was full >>> of serious correctness and stability issues. Despite developing it, I would >>> not have run it myself or recommend that anyone use it. We have dug >>> ourselves out of that hole, but it took years of discipline and effort, and >>> we're still (deservedly) recovering our reputation. >>> >>> Let's use this new technology to improve the quality of our >>> contributions, not squander our hard-earned gains in the name of speed. It >>> will be hard to recover our reputation a second time. >>> >>> >>> On 2026/09/23 19:16:17 Patrick McFadin 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 >>> >>> >
