I think it’s extremely important that large blocks of generated code are directly annotated as such. It is important to me as a maintainer that I know if human intention was properly brought to bear on a body of code, as it changes how I will engage with the code. If the code was broadly LLM-generated, I am more likely to ask an LLM to maintain it, and I am much less likely to try to maintain its design or semantic decisions.
On 2026/09/25 01:26:31 Blake Eggleston 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
