I think it's fair for the project to document what models helped prepare what patches, even if the use of *something* is going to eventually become the rule rather than the exception.
On Thu, Sep 24, 2026 at 8:27 PM Blake Eggleston <[email protected]> wrote: > Why's that? I'm not really interested in adding something like that to my > patches. > > On Thu, Sep 24, 2026, at 6:21 PM, Caleb Rackliffe wrote: > > Regardless of what we end up moving forward with, I think we need to use > "Assisted-by" just like we use "Co-authored-by". > > On Thu, Sep 24, 2026 at 7:59 PM Jane H <[email protected]> wrote: > > I've been reviewing AI-assisted PRs from new contributors lately. > > The main concern I see is that: committers' review is already the > bottleneck of our delivery speed, but LLM-assisted PRs can make PR review > significantly harder, therefore put even more load on reviewers. Without > clear policy, guidance, and aligned expectations from the community, I > worry that increased use of AI can make our delivery speed slower rather > than faster. > > Sharing several challenges I met when reviewing AI-assisted PRs recently: > > 1. How do we put the principle that "contributors are responsible for > the code they submit" into practice? > 1. How does a contributor know they indeed understand every line of > code in their PR? This can be harder than it sounds. Imagine a new > contributor who vibe-codes a PR, reads through every line, feels that > the > code makes sense, and it passes several AI review tools. Is that enough? > I'd say no. For example, if this PR involves sending a new message to a > client, then I think a client and server setup for end-to-end manual > testing is needed. If a PR adds a metric, then I think spinning up a > cluster and watching the metric changes is needed. Such knowledge isn't > necessarily straightforward to new-comers. > 1. I think formal guidance on how to verify (e.g. testing env > setup) and what needs to be verified will be helpful. > 2. If a reviewer suspects that a contributor does not actually > understand their code, what should this reviewer do? In my own > experience, > I point out what's wrong in the code, but I don't think it is helpful to > simply blame the contributor for not understanding their submission. In > most cases, I don't have strong evidence that a mistake came from > AI-generated code and from the contributor failing to review it > carefully. > Human-written code can make similar mistakes too. And even if I know for > sure it's from AI assistance, what should I do? > 3. As PR review is async, sometimes a PR review will go straight to > contributors' claude. For example, if I ask, “Did you try testing > against > X?”, and the contributor asks claude to test against X then responds, > “Yes, > I tried it and it works,” I may trust them and approve the PR. But what > if > that answer turns out to be claude's hallucination? How should > responsibility work in that situation? > 2. More load on reviewers, more load on verification. Because I don't > currently know how the contributor's responsibility can be enforced in > practice, when I see a PR with LLM content, I have less confidence that the > PR is validated by human. In my own experience, I've had to ask > contributors how they've tested and why they think it's working, and tell > them what manual testing is needed. Often times I need to perform those > tests by myself instead, some are tests that I might not have needed to > perform in the same way in pre-AI era. Therefore I propose: > 1. Formal guidance on verification, as mentioned above. > 2. A PR template section that asks contributors to explain what > testing they've done beyond the unit tests and integration tests > included > in the PR. > 3. Disclosure of AI assistance, including which parts of the PR > were AI-assisted. > 3. Potentially misaligned expectation of delivery speed. Consider a > situation where someone comes to me with a new feature consisting of > hundreds of new files generated by LLM in a day saying they verified it and > asks for a review. What am I supposed to do? In my humble opinion, > reviewers should still review line-by-line, and as long as this holds true, > the high productivity of AI can never translate to the high delivery speed > as people wish. Various AI PR review tools can only help a bit but never > resolve the fundamental problem. I'm very open to different opinions here, > but I hope the community can align expectations. > > Overall, I think LLM is NOT just "another tool". None of previous tools > like IntelliJ has caused the above challenges. We have real problems to > solve here, and I think we would benefit from aligned expectation and > guidance, in addition to policies. > > > Jane He > > On Thu, Sep 24, 2026 at 5:40 PM Caleb Rackliffe <[email protected]> > wrote: > > Blake, I’d support those 3 guidelines. > > One hostile reaction to them would, I’m guessing, be that guideline number > 1 is too weak, and that the burden of quality would continue to rest > entirely on committer reviewers. I suppose my reply there would be that > anyone who continually spams the project with patches they do not fully > understand wound incur a pretty heavy reputational penalty and the problem > would more or less sort itself out. > > > > On Sep 24, 2026, at 6:07 PM, Benedict Elliott Smith <[email protected]> > wrote: > > > > For the record Josh, I am including pre-3.0. I was involved in customer > support escalations for 1.2, 2.0 and 2.1: the software was shoddy, to put > it mildly. 8099 was a symptom, not the disease. > > > > The project had a culture of doing stuff without sufficient care or > consideration. This is by no means a simple matter of needing more testing > or less timeline pressure, nor is it easy to define a "bar" to ensure it > does not regress. If we had simple metrics, we would have settled it a long > time ago. > > > > You can still see customer scars crop up on forum discussions > periodically. > > > > > > On 2026/09/24 19:01:02 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 > >
