There have been some emotional appeals regarding the effect of policies on those who don't yet contribute code, or who contribute only a little. We may be forgetting that we have had some notable successes driving away long-term core contributors.
Whatever you think of the concerns, if they aren't addressed trust is undermined, leading to disengagement with the contribution process - then private forks that diverge, and before long upstreaming becomes too burdensome. If we leave everyone to decide their own AI usage policies, we cannot be surprised if they also choose their own review and collaboration policies[1]. This may make it hard to onboard newcomers who cannot navigate the informal landscape, but also leads to parallel communities forming around different norms. My prediction is that no policy means the slow but steady fracturing of the community as it stands today. [1] I, certainly, will limit my collaborations to people who can demonstrate to me that they use LLMs in an appropriate way, though most will not be so frank about this On 2026/09/27 21:14:46 Ekaterina Dimitrova wrote: > Hi Benedict, all, > > I am very excited to see this healthy discussion and the high participation > of people with variety of opinions and points of view. In my opinion, this is > much needed as the software engineering profession is evolving by the day. > Most of all, I think others will agree we all heard the concerns of Patrick > and others about contributions (yikes, that hurts but thank you for being > honest!) and concerns of many of you/us about ensuring we keep the quality > gate we set for ourselves. Yes, fighting all the bugs and CI and this and > that to get 4.0 out was no fun but it was so rewarding at the end! Reviewers’ > load is also definitely something to take seriously. > > Thanks also to everyone who shared different policies, links, other projects > know-how. I actually went through those I didn’t know about. > > First of all, I would like to remind everyone that ASF already has a Gen AI > tools guidance for the projects. [1] A few quotes that I think they apply > directly to the current discussion: > > "The Apache-2.0 license, and the Apache Individual Contribution License > Agreement, both remind contributors that they are responsible for disclosing > any copyrighted materials in submitted contributions that are not their > original creation. This is as true when using generative AI tooling, as it is > when using materials from public websites or code from other open-source > projects." > > "When providing contributions authored using generative AI tooling, a > recommended practice is for contributors to indicate the tooling used to > create the contribution. This should be included as a token in the source > control commit message, for example including the phrase “Generated-by: ”. > This allows for future release tooling to be considered that pulls this > content into a machine parsable Tooling-Provenance file." > > I do not think we need a policy for that, it is already in the ASF guidance? > But maybe we can add a link to it under our own policy/guidance, if we end up > having one? Since transparency is already a community best practice, linking > the ASF guidance directly in our project guidelines makes total sense without > needing to reinvent a brand-new policy. > > Two points on the initial email: > 1. Vetos should be given rarely and they have to be accompanied with > (technical) rationale. [2] > > 2. Creating additional hierarchy of who can and who cannot use AI and from > there - who gets to commit. Any potential policy should be community-oriented > and not single-out people. Not to mention the suggested criteria is very > subjective. I am sure Benedict’s intention was/is not to discriminate anyone, > he actually calls his idea “apprenticeship”, but we should also acknowledge > the feedback that many people provided - they see it as discriminating, or at > least not community-oriented. > > My personal opinion is that we do not see a novel problem (people porting > code from a fork or getting code from Stack Overflow or anywhere else and > not necessarily understanding in full what they are doing), but AI can > definitely accelerate it and make it a bigger issue. I love the suggestion of > recommended practices, also Definition of Done that can apply to all and any > contributions - no matter if it is AI-generated, or human-generated. Also, I > would welcome all the tools suggested to help with automating some of the > review parts (which is a great idea on its own even without AI in the > picture, honestly. Thanks, Jon! Now someone has to work on adding them.) > > Honest question for Benedict and others who support the initial policy > suggested - If a person submitted a great solution and summarized it well on > the ticket with clean CI results etc - is a reviewer going to start > questioning and interrogating them or just approve it, say thank you, and > commit? Also, as others already raised a concern - allowing certain people to > contribute using AI and others not to is subjective and not > community-oriented. > > Just one example where I find such a policy cannot fit, even if let’s say we > adopt it - someone does way more work nowadays around particular features but > in a fork, they haven't done a lot around them in the Cassandra repo. The > person is a long-time committer also. If they decide to port some of the work > done in the fork, what will happen? If they disclose some of it was done with > AI, they are not going to be allowed to port it? They will be told they > haven’t contributed to that feature in the past in the main repo? Or they can > ensure they follow a definition of done and what David suggested with regard > to testing? The latter seems way more feasible to me, and fair. What do > others think? Aren’t we going to lose some potential good contributions in > this case, if we disallow the code as it was ai-assisted/generated by a > long-time committer in a good standing who is coming to contribute in a good > faith? > > “Does not demonstrate expertise, commitment or that they can or will maintain > the patch” > While we obviously want contributors to stick around and support their work, > trying to pre-screen someone's long-term commitment before accepting a patch > is tricky. The most practical leverage we have is during the review itself: > requiring authors to actively engage, explain their changes, and pass all > Definition of Done gates before anything is merged. > > Having a consistent style guide around comments and expectations there seems > like the right place to constrain and normalize our bar of quality, not > policing how people get to that destination. This resonates with me. Also, > make it clear what is expected from the review process and reviewers, if it > is not clear already. > > Stefan mentioned below: > “As somebody who is looking into the open > PRs on a daily basis, the sure way to identify a contributor who is > using AI heavily without constraints is when they create a handful of > PRs in a fast cadence and we never hear from them anymore.” > > Indeed, while AI enables high-volume low-effort submissions, the solution > isn't to ban tools, but to raise the entry gate maybe? (e.g., stricter PR > templates, required test coverage, automated linters, and closing > unassigned/unresponsive PRs quickly, to begin with) > > I agree with this sentiment: > “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.” > > But limiting people and saying - only these or those people can use AI > subjectively doesn’t seem to be a solution. The software engineering > landscape is changing. While a company can probably add such rules internally > with regards to new/junior engineers, I do not think we can apply such rules > to OSS community and single out people. (Some of whom can be very good > experienced software engineers with extensive expertise in distributed > systems or from the ecosystem who just happen to have not been able to > contribute to the main Cassandra codebase so far) > > Also, I agree with Blake: > “ Complicating matters further is the fact that this PMC covers an ecosystem > of Cassandra subprojects, not just the database, and they each have their own > development groups and challenges. > > I think the approach of trying to craft an all encompassing AI policy that > addresses ‘the whole thing’ is unlikely to be successful at this point, > regardless of what the policy is. > > It would be a better use of everyone’s time if we addressed more narrowly > scoped problems and concerns as they come up and build up an AI policy > purposefully and as needed, iterating as we go. I don’t think I need to make > the argument for iterative development being preferable to big bang changes.” > > One more point - we all know that a person, to become a committer they need > to show not only they can submit patches that can be accepted, but also to > show they are capable reviewers and be involved in a lot more than just > committing code. I feel if people want to stick around and become committers, > they won’t have a choice but to show their knowledge and spend time on the > code themselves. > > “While the term “committer” implies committing code, it can also be > interpreted as someone who is committed to the project.” [3] > > “Having said that, I still think we have room for more detailed > guidelines/best > practices for using the tools to bring better quality patches to the review > pipeline to begin with. I don’t want to lose this aspect of Benedict’s > original proposal, and it feels like they can coexist.” > Me too, Caleb. > > I do not have a proposal for policy (though if I see one that resonates well > with me, I would be happy to support it), but I would be happy to help with > some Definition of Done and PR templates, if people think that may be > beneficial. Also, I would be happy to take a stab at opening tickets and > helping add more tooling to provide automated feedback (I would do it with > the help of AI, if I may :-)). We could also consider adding guidance around > PR sizes and incremental changes. > > Best regards, > Ekaterina > > [1] https://www.apache.org/legal/generative-tooling.html > [2] > https://cwiki.apache.org/confluence/spaces/CASSANDRA/pages/158863606/Cassandra+Project+Governance > [3] https://community.apache.org/contributors/becomingacommitter.html > > > > On 2026/09/27 16:43:55 Blake Eggleston wrote: > > Thanks for your input Jarek. > > > > Aleksey, the problem is that most of the reasons given so far in support of > > this policy aren’t facts, laws of nature, or statistics. Generally they’re > > fears, opinions, and minor annoyances. On the other hand, the initial > > proposal is a blanket proposal affecting all contributions and affects who > > can contribute to what. > > > > This thread seems to be trying to fix a ton of problems, none of them well > > defined. If we’re going to craft effective policy I think we need to first > > agree on what is a problem and second how to fix it. > > > > Zooming out, the issue of AI and its role in software development is > > multi-faceted and evolving very quickly. People have very different views > > on the subject, regardless of their place within the project, and feelings > > about how it affects them. Complicating matters further is the fact that > > this PMC covers an ecosystem of Cassandra subprojects, not just the > > database, and they each have their own development groups and challenges. > > > > I think the approach of trying to craft an all encompassing AI policy that > > addresses ‘the whole thing’ is unlikely to be successful at this point, > > regardless of what the policy is. > > > > It would be a better use of everyone’s time if we addressed more narrowly > > scoped problems and concerns as they come up and build up an AI policy > > purposefully and as needed, iterating as we go. I don’t think I need to > > make the argument for iterative development being preferable to big bang > > changes. > > > > Really the topic of new contributors using LLMs deserves it’s own focused > > discussion, the question of whether we should add an Assisted-By tag > > deserves it’s own focused discussion and so on. > > > > We also need to have a candid discussion about the new dynamic of longtime > > and respected PMC members who aren’t core database engineers who have > > started showing up with substantial low level core database contributions > > with the help of LLMs. I strongly suspect that this single issue is > > motivating much of this proposal. It does read that way and it was > > certainly the catalyst for starting this thread. It would be more > > productive to just have a discussion with the parties involved. > > > > Finally, I’d also like to get something off my chest regarding how this all > > applies to me: > > > > I’ve been contributing to Cassandra for over 10 years now. I’ve built up a > > large resume of significant and impactful contributions during that time. > > I’m solid. At this point in my journey as a Cassandra developer, I don’t > > feel that it’s appropriate for the project to be telling me how I can do my > > work or requiring me to report on the tools i use. The project trusts me > > and I should be free to experiment with and evolve my workflow as I see fit. > > > > If anyone has any issues with the quality of my work though, please let me > > know, I’d welcome that. > > > > On Sun, Sep 27, 2026, at 7:40 AM, Patrick McFadin wrote: > > > Jarek, > > > > > > I’ve been watching magpie and will be in Glasgow. I really love the > > > direction of this project and will try to attend your workshop. > > > > > > We currently have over 500 PRs sitting in github. I’m going to set up > > > Magpie and eval that real world problem to see how it can help. I’ll > > > message you with any questions. > > > > > > Patrick > > > > > > > On Sep 27, 2026, at 4:31 AM, Jarek Potiuk <[email protected]> wrote: > > > > > > > > Hi everyone, > > > > > > > > It’s a super-interesting thread. You are definitely not alone—nearly > > > > every open-source project is facing similar discussions right now. > > > > This is actually encouraging; it shows we have so many smart, > > > > community-driven people in Open Source that we will figure it out > > > > together. I already see some encouraging signs. > > > > > > > > As the PMC chair for Magpie, I wanted to share that this project grew > > > > out of what I attempted to do in Apache Airflow to deal with these > > > > exact issues. Over the last 5–6 months, I’ve been experimenting, > > > > seeing what works, and putting lessons into practice—particularly > > > > around Security Issues and Security/Threat model preparation for > > > > Glasswing scanning (the next wave of updates will start when I return > > > > from vacation next week) and PR triaging. > > > > > > > > I’ve gone through many phases, from frustration to excitement about > > > > what AI agents offer, including rabbit holes and a few major wins. > > > > Ultimately, I believe AI will help us build community around code, not > > > > destroy it. However, we must adapt our definition of "community > > > > growth" and focus on the discussions that uphold the values of the > > > > Apache Way. > > > > > > > > For those attending in Glasgow, we will be running Magpie workshops, > > > > participating in a roundtable, and hosting almost daily security open > > > > hours. I look forward to discussing this evolution further in person, > > > > but here are a few key takeaways from my experience: > > > > > > > > - Be a Centaur, not a Reverse-Centaur: AI is a tool to amplify your > > > > capabilities. You should drive the tool, rather than letting it (or > > > > management) drive you. (I highly recommend Cory Doctorow's article, > > > > "The Reverse Centaur's Guide to Life After AI"). > > > > - As a Centaur, consider what you can control to achieve your goals. > > > > In Airflow we are implementing some of these strategies that will add > > > > "harness" to contributors and incentivise them to work in the way that > > > > you want: > > > > * Add easy-to-deploy harnesses that limits some obvious abuses - > > > > we have **just** implemented PR limit (5 open PRS) per external > > > > contributor (some people had 30+ PRs opened, most AI generated) - > > > > asking the contributors to be mindful, prioritise their PRs - and open > > > > only those that are very important to them. (-210 PRs were closed > > > > after we asked contributors to cooperate and reopen only those they > > > > considered most important). The discussion about it generated a lot of > > > > engagement from contributors who were "humans" and suffer because we > > > > had huge backlog of PRs to review - and they actually absolutely > > > > welcomed it - after we explained and documented reasoning and asked > > > > them to cooperate. I was **absolutely surprised** how little backlash > > > > we had on this. We will see in the coming weeks what effect this has > > > > on new PRs. > > > > * Implement things that will incentivise good behaviour. > > > > Something I learned from Apache Seatunnel as Idea - we are discussing > > > > (and I am sure we will try it soon) to expect for external > > > > contributors to have **them** run CI in their PRs - and do not use ASF > > > > infrastructure/runnerrs for it. This will have not only effect on > > > > reducing pressure on the shared runner pool (tragedy of the commons) - > > > > but also has this interesting side effect that contributor - free > > > > accounts have 20 runners as limit - will have **way** longer iteration > > > > on CI with their "huge PRs to important areas" where their "small PRs > > > > to easy-to-contribute-areas" will be almost unaffected. We hope this > > > > will incentivise our external contributors to contribute smaller prs > > > > in areas which require less "care" and are easier to contribute to. > > > > - Practice daily: As you learn to use AI to free up your time, you > > > > create space to experiment and improve further). > > > > - Adapt to changing workflows (especially PR reviews): Instead of > > > > trying to return to past workflows, leverage AI to amplify maintainer > > > > capabilities. Maintainers must delegate routine tasks to AI ("the > > > > horse") so they can focus on product vision and community building. > > > > - Provide context via repositories: Agents require clear guidance. > > > > Creating AGENTS.md files, retroactive ADRs, and clear design documents > > > > allows agents to read and follow project constraints before writing > > > > code. In Airflow, establishing agentic instructions drastically > > > > reduced out-of-bounds PRs within a week. > > > > - Build automated, deterministic harnesses: Turn project invariants > > > > into deterministic scripts and CI checks whenever possible. Use > > > > non-deterministic instructions (AGENTS.md) for the rest. Let the > > > > contributor’s compute verify these rules before a maintainer ever > > > > reviews the PR. > > > > - Shift the review paradigm: Use agents to re-verify invariants and > > > > assist with spot-checks. Every time a new edge case or undocumented > > > > constraint arises during review, turn it into a new automated check or > > > > update your AGENTS.md. > > > > - Automate verification and evidence: Set up your dev environment so > > > > agents can launch services, run integration tests, and supply > > > > screenshots or logs of before-and-after behavior. > > > > - Focus human interaction on high-level design: Require design > > > > specifications for major changes and review those thoroughly. Shift > > > > human maintainer effort toward product vision, architecture, and > > > > meaningful engagement with contributors (e.g., dev calls, > > > > Slack/Discord discussions). > > > > > > > > This approach is central to Magpie. It provides a set of skills to > > > > assist maintainers through interactive PR reviews and can even > > > > automatically propose documentation updates based on new constraints > > > > identified during review. > > > > > > > > Rather than reviewing every line of code manually, maintainers can > > > > focus on refining the harness, elevating their impact, and maintaining > > > > human connections where they matter most. We have even successfully > > > > calibrated Magpie skills to help identify and highlight potential > > > > PMC/committer candidates based on contribution quality. > > > > > > > > I look forward to continuing this discussion and demonstrating these > > > > tools in Glasgow! I think it will take many months for us to > > > > transition to these new ways of work. But I am actually quite excited > > > > now when I see a clearer direction I personally can personally take, > > > > where I can - as one of the leaders in Airflow - drive the direction > > > > of community work, and where I can—as PMC chair of Magpie - help > > > > others follow. > > > > > > > > [1] > > > > https://doctorow.medium.com/https-pluralistic-net-2025-12-05-pop-that-bubble-u-washington-8b6b75abc28e > > > > [2] > > > > https://github.com/apache/security-vulnogram/pull/264#issuecomment-5845781841 > > > > > > > > Best regards, > > > > > > > > Jarek Potiuk > > > > > > > >> On Sun, Sep 27, 2026 at 11:48 AM Aleksey Yeshchenko via dev > > > >> <[email protected]> wrote: > > > >> > > > >> What Blake is proposing here is not an LLM usage policy, it's just > > > >> spelling out loud the existing common sense expectations, and > > > >> addresses none of the concerns raised about LLMs. > > > >> > > > >> > > > >> Transformed into a shape of an LLM usage policy, it would read as "LLM > > > >> use is unrestricted". > > > >> > > > >> And, with Caleb's addition: "LLM use is unrestricted, but must be > > > >> disclosed". > > > >> > > > >> I would not vote for either of these policies, as, again, they don't > > > >> address the concerns raised. > > > >> > > > >> I also recommend folks to read > > > >> https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/ > > > >> and https://forge.rust-lang.org/policies/llm-usage.html as they are > > > >> both quite well written and say what I'd like to say better than I > > > >> could myself. > > > >> > > > >> -- > > > >> AY > > > >> > > > >> On 27 Sep 2026, at 10:18, Aleksey Yeshchenko via dev > > > >> <[email protected]> wrote: > > > >> > > > >> What Blake is proposing here is not an LLM usage policy, it's just > > > >> spelling out loud the existing common sense expectations, and > > > >> addresses none of the concerns raised about LLMs. > > > >> > > > >> We don't need to codify "the author must understand the patch" or "the > > > >> reviewers need to understand the area of the code", these are > > > >> common-sense banalities. > > > >> > > > >> We don't need to vote for it. All of it is already in effect. > > > >> > > > >> -- > > > >> AY > > > >> > > > >> On 26 Sep 2026, at 18:57, Caleb Rackliffe <[email protected]> > > > >> wrote: > > > >> > > > >> Having said that, I still think we have room for more detailed > > > >> guidelines/best practices for using the tools to bring better quality > > > >> patches to the review pipeline to begin with. I don’t want to lose > > > >> this aspect of Benedict’s original proposal, and it feels like they > > > >> can coexist. > > > >> > > > >> On Sep 26, 2026, at 12:51 PM, Caleb Rackliffe > > > >> <[email protected]> wrote: > > > >> > > > >> > > > >> I’m fine with rolling my proposal into Blake’s, with the understanding > > > >> that we still tag model assists in our commit messages. > > > >> > > > >> On Sep 26, 2026, at 11:58 AM, Dinesh Joshi <[email protected]> wrote: > > > >> > > > >> > > > >> My +1 was to keeping it simple and just go with Blake's simple > > > >> straightforward guidelines. > > > >> > > > >>> On Sat, Sep 26, 2026 at 9:47 AM <[email protected]> wrote: > > > >>> > > > >>> We have multiple active proposals on this thread but it’s unclear > > > >>> which proposals "+1’s” should be attributed to. > > > >>> > > > >>> From a threaded reading based on which messages reply to which: > > > >>> > > > >>> Alex’s reply with a +1 is to Benedict’s email and original proposal. > > > >>> Jon’s reply is to Blake’s email but says “to simple straightforward > > > >>> guidelines” (unclear if referring to Blake’s proposal or simple > > > >>> guidelines in general). > > > >>> Dinesh’s reply is to Jon’s, which carries ambiguous attribution to > > > >>> Blake’s proposal or simple guidelines. > > > >>> > > > >>> > > > >>> To keep our discussion tidy and positions clear, can I propose > > > >>> clearly attaching a +1 to a specific proposal or position in the > > > >>> thread so there’s no ambiguity as to what each of us support? > > > >>> > > > >>> – Scott > > > >>> > > > >>>> On Sep 26, 2026, at 9:32 AM, Dinesh Joshi <[email protected]> wrote: > > > >>> > > > >>> +1 > > > >>> > > > >>> On Sat, Sep 26, 2026 at 9:21 AM Jon Haddad <[email protected]> > > > >>> wrote: > > > >>>> > > > >>>> +1 to simple straightforward guidelines > > > >>>> > > > >>>> > > > >>>> > > > >>>> On Thu, Sep 24, 2026 at 1:01 PM Blake Eggleston > > > >>>> <[email protected]> wrote: > > > >>>>> > > > >>>>> I propose the following guidelines: > > > >>>>> > > > >>>>> Contributors must have a comprehensive understanding of the patches > > > >>>>> they contribute > > > >>>>> Reviewers must have a comprehensive understanding of the patches > > > >>>>> they approve > > > >>>>> Reviewers must have experience with the affected systems > > > >>>>> commensurate with the risk and complexity of the patch. > > > >>>>> > > > >>>>> > > > >>>>> This makes the expectations that have been mostly implicit > > > >>>>> explicit, doesn’t gate keep on the contributor side, doesn’t tell > > > >>>>> people how to do their work, and gives the subject matter expert, > > > >>>>> the reviewer, the latitude to decide what standards make sense for > > > >>>>> the patch they’re reviewing. > > > >>>>> > > > >>>>> > > > >>>>> On Thu, Sep 24, 2026, at 12:01 PM, Josh McKenzie wrote: > > > >>>>> > > > >>>>> Apache Cassandra was fundamentally undeployable for four years > > > >>>>> between Nov 2015 - 2019. > > > >>>>> > > > >>>>> CASSANDRA-8099 was a maximal manifestation of a specific approach > > > >>>>> to engineering and calendar constraints we've seen time and again > > > >>>>> on the project; I don't want us to conflate things here. That was a > > > >>>>> herculean monolithic body of work performed in inhuman conditions > > > >>>>> (in vim!) that was ultimately so invasive, all the unit tests in > > > >>>>> the code-base were commented out and Jake and I spent a grueling > > > >>>>> 1.5-2 months hand-rewriting basically all the unit tests in that > > > >>>>> code-base to get things to even build and run, much less pass. > > > >>>>> > > > >>>>> Massive blast radius changes that are un-sustainably complex, > > > >>>>> under-tested, where we don't property, fuzz, check coverage, check > > > >>>>> complexity, or A/B compare against a known good system (i.e. > > > >>>>> pre/post) correctness testing are going to destabilize the database > > > >>>>> at any time under any regime of tooling. We certainly could > > > >>>>> speed-run our way back into destabilization with LLM's as they are > > > >>>>> a force multiplier for both the good and the bad of one's > > > >>>>> engineering practices, but that's a solvable problem by better > > > >>>>> defining what our bars of quality are (Definition of Done anyone?) > > > >>>>> and holding ourselves accountable to delivering at that bar. > > > >>>>> > > > >>>>> On Thu, Sep 24, 2026, at 2:40 PM, David Capwell via dev wrote: > > > >>>>> > > > >>>>> > > > >>>>> if you really want to pursue it I would ask that we do it offline > > > >>>>> to avoid polluting an already busy conversation > > > >>>>> > > > >>>>> People are directly responding saying that they feel discrimination > > > >>>>> currently and that the policy tries to codify that discrimination, > > > >>>>> so I feel its 100% on topic. This thread has presented 0 evidence > > > >>>>> that LLM usage has lowered the quality of contributions merged and > > > >>>>> has so far been vibes and feeling; I have yet to see any evidence > > > >>>>> to justify such discrimination so I will keep pushing back until > > > >>>>> such evidence is presented so we can have a informed debate. > > > >>>>> > > > >>>>> namely how we handle shallow and localised bug fixes. I would be > > > >>>>> happy adding a clear entry to the “Permitted” section for this. No > > > >>>>> doubt there are many refinements needed to the Restricted text as > > > >>>>> well, that might also capture some of your concerns. > > > >>>>> > > > >>>>> I will not sign off on cherry picking areas where "safe" to use a > > > >>>>> tool; so no it does not capture my concerns. > > > >>>>> > > > >>>>> > > > >>>>> I don't know if everyone remembers, but ten years ago Cassandra was > > > >>>>> full of serious correctness and stability issues. Despite > > > >>>>> developing it, I would not have run it myself or recommend that > > > >>>>> anyone use it. We have dug ourselves out of that hole, but it took > > > >>>>> years of discipline and effort, and we're still (deservedly) > > > >>>>> recovering our reputation. > > > >>>>> > > > >>>>> Let's use this new technology to improve the quality of our > > > >>>>> contributions, not squander our hard-earned gains in the name of > > > >>>>> speed. It will be hard to recover our reputation a second time. > > > >>>>> > > > >>>>> I do recall the 3.x line and put in a significant amount of effort > > > >>>>> to harden it. There were behaviors I noticed after joining > > > >>>>> Cassandra that I feel directly contributed to 3.0 and the decade of > > > >>>>> catch up; behaviors that still linger in parts of the community > > > >>>>> today. > > > >>>>> > > > >>>>> As I look on trunk and look at committed code and trace back to PRs > > > >>>>> and JIRA I see the following: > > > >>>>> > > > >>>>> large patches approved without comments > > > >>>>> 0 evidence that tests were run > > > >>>>> > > > >>>>> I then look at our CI and see tests failing for months. As you > > > >>>>> start to triage you start to see some of them show real issues; yet > > > >>>>> they linger for months not being addressed... when CI is unstable > > > >>>>> it takes a lot of effort to triage "did my patch break the test", > > > >>>>> and I have seen time and time again people do not put in that > > > >>>>> effort, and shrug off as "its just a flakey test"; then our CI > > > >>>>> failure rate grows. > > > >>>>> > > > >>>>> Non of this has anything to do with LLMs but LLMs running in this > > > >>>>> environment is far more dangerous as there are not checks in place > > > >>>>> to "hold the bar". I am all for raising the bar universally; > > > >>>>> expecting both humans and LLMs to match that bar. > > > >>>>> > > > >>>>> I’d support something that boils down to roughly this: > > > >>>>> > > > >>>>> 1.) 2 committers must understand an LLM-assisted change before it > > > >>>>> commits. (Perhaps separately we can explore the question of why we > > > >>>>> haven’t added any new committers to the core project for about a > > > >>>>> year. I’m also still not entirely sure if it’s acceptable within > > > >>>>> our guidelines for a committer to +1 a patch after delegating > > > >>>>> review.) > > > >>>>> > > > >>>>> 2.) Patch authors must demonstrate enough understanding to discuss > > > >>>>> their own patch, whether or not parts of it are generated by an LLM. > > > >>>>> > > > >>>>> 3.) The “Assisted-by” tag should be used to indicate any > > > >>>>> non-trivial LLM usage in the generation of a patch, just like we > > > >>>>> have used Co-authored-by historically. > > > >>>>> > > > >>>>> 4.) Comments and other things that aren't the actual code (but > > > >>>>> could sow confusion) should be held to the same standard we'd > > > >>>>> expect from a human writer. If we don’t yet agree on that standard, > > > >>>>> we can formalize enough of it to guide both humans and LLMs. > > > >>>>> > > > >>>>> I can get behind this proposal but i would tweak it as 1/2 i don't > > > >>>>> think really need to special case LLM usage > > > >>>>> > > > >>>>> 2 committers must understand the change before it commits. > > > >>>>> 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 > > > >>> > > > >>> > > > >> > > > >> > > > >
