On Fri, Sep 25, 2026 at 7:52 PM David Capwell via dev <[email protected]> wrote: > > Thanks for the reply josh / Aleksey. > > I am one of the lead maintainers for repair / type system / and gossip… so I > can always ask myself how would I feel if either of the 2 conditions came to > my table > > 1) someone established in the community sends me a AI generated patch > 2) someone new (first contribution) sends me a AI generated patch > > I have more trust that I can collaborate with 1 than I do with 2 (thats true > today without LLMs) but I need to be open and welcoming and assume we can > collaborate until proven otherwise. > > For repair, coordinator has good test coverage, so if the patch is at the > coordination layer I am not really concerned (other parts of repair I would > have more concern due to lack of coverage). I feel I can collaborate with > the human and not worry that they use AI to aid in the patch. My review / > existing tests / and me expecting existing tests to be improved and new tests > to cover the new behavior should be more than fine. > > For type system there is a known testing gap for function integration (this > was brought up when adding vector type and wasn’t solved). This is an issue > with triable knowledge and something I would try to collaborate with the > patch author to improve to lower the risk of their patch. > > For both repair and the type system they both suffer a lot from lack of > documentation; type system is the worst as it has so many subtle apis to > flesh out. This type of documentation isn’t for LLMs, its for any and all > contributors; adding a new type to the server shouldn’t be so annoying and > should be clear (leaving out the client side of this). Work on the docs > could happen now or with the help of the contributor (can focus on docs that > directly impact their patches to start and incrementally improve them). > > So my answer for both 1/2; I do not care at all if AI is used. > > Then there is gossip. You might think my take is that this invalidates > everything but it doesn’t! Before TCM merged I was working on refactoring > gossip to be testable and added simulation based testing; this testing was > finding bugs blocking its merge. I was getting close to merge but then TCM > was right about to merge and Marcus and I came to an agreement to not merge > before TCM as it would make the TCM merge harder. After TCM merged I lost my > time to improve gossip (this refactor was funded by a production issue I had > to root cause / fix. It was critical to root cause and prove my fix worked, > but couldn’t merge as there were more gossip bugs…)…. Given this context I > would ask the contributor to help resurrect the gossip simulation tests, and > to root cause and fix the existing issues. With this in place the new > contribution that is desired has drastically lowered the risk to the > contribution! Before LLMs this kind of request was basically a “go F > yourself”, but now it’s a reasonable request if I know the author is using AI > to write the patch; if you want to burn tokens on cassandra how about you > focus it on derisking contributions! > > So now my answer for 3; I trust 2 humans to touch gossip and AI… A new human > trying to contribute is far too risky and I can’t ask them to take on such a > burden… > > So for every area I help maintain I am not worried about AI as long as the > human on the other side is willing to collaborate and work together.
I think this is the crux of it. I have a similar opinion. Recently, when we finished Zstd dictionary compression, the remaining part was to introduce its auto-training functionality. I kind of knew what I wanted, asked Claude to do the core set of classes from which everything followed. Then I stopped using AI assistance completely and made sure that I "touch and tweak by hand" - a human touch. Nobody can wire it better than a human, it still holds. AI will never be able to write it as _I_ want it. Couple more iterations and I was done. I presented this to Yifan, the review still pending. Is this _mergeable_? No way. It is 85% there. Both of us know it. But it is good enough to have another human in a loop to go over it, _knowing some of it was AI-driven_, while he is still able to give a meaningful input to what I have done. I would not believe a non-committer or a person who did not spend a significant amount of time on the dictionary compression because they don't have the context. > > > and it's not budgeted in by anyone, > > I do think it’s fair to ask the contributor to budget it as a tool to derisk > their desired contribution. If they are not willing to do it I do feel its > more than fair as reviewer to not sign off on the patch as it is too risky. > > I do not have the budget to improve the type system + function calling area, > but if the contributor can I can spare time to review / guide. This would be > a great contribution that makes it easier for more people to contribute! > > I do not have the budget to resurrect the gossip simulation test, but if the > contributor can I can spare time to review / guide. Again, this would be an > amazing contribution! > > I do not have the time to lower the bar to contribute, but if a contributor > is willing to I think that contribution should be welcomed and encouraged. > > > and you can't just ask Fable to fix it all, at least not yet. > > > But we can make incremental progress, the same way we did for 4.x testing. > > I think a great example of this is SAI. SAI was seen as running in > production so was low risk, we even released it. I got nerd sniped so added > a SAI command to my existing fuzz tests and this caused Caleb to not sleep > for 5 months as it kept finding data loss and correctness issues (some issues > in SAI handling, others in core Cassandra sub systems not known about for > 10y+)… At this point I am no longer the main person adding to these tests, > SAI contributions are the main patches extending the tests now! > > This was all human code but it helps lower the bar to contribute. It makes > it safer for everyone to contribute regardless of if AI or a human wrote it. > > "SAI was able to become the first filtering thing that didn't suck by the > end.” - Caleb > > > because of how unnecessarily complicated, interconnected, poorly > > documented, poorly tested, poorly factored / architected / abstraction > > leaking our current code-base and architecture is > > > I do agree here as we saw first hand with 4.x line how important it was to > improve these places to get a production quality database. The more we fix > these the better it is for our database’s health and the ease for us all to > contribute. We want to add very complex and challenging features in this > current environment; thats very risky even with humans doing it… to help > lower the risk we should improve in these areas, and doing so makes it easier > for new people to contribute. > > > > On Sep 25, 2026, at 8:36 AM, Aleksey Yeshchenko via dev > > <[email protected]> wrote: > > > >> I do think our project is in a particularly vulnerable place for > >> destabilization by the introduction of any accelerating technology because > >> of how unnecessarily complicated, interconnected, poorly documented, > >> poorly tested, poorly factored / architected / abstraction leaking our > >> current code-base and architecture is. I'd much prefer we invest in > >> improving the robustness of our deterministic exit criteria so we can > >> encourage more contribution and retain confidence in the properties of the > >> system; if we continue to rely on social stratification, domain > >> participation limits, and tooling and workflow gate-keeping to slow things > >> down to a pace our current very weak acceptance gates on the system can > >> validate as "correct enough" we're going to continue to languish as a > >> project right as the rest of the world accelerates. > > > > > > This is true. A lot (not all, but a lot) of this complexity is inherent to > > the domain, however. This is a distributed DBMS after all, so the bar to > > participate can only be lowered by so much, even in a perfectly factored > > implementation. > > > > That said, it can absolutely be lowered from where it is now. It's just > > that doing the necessary work to get there is *hard* and it's not budgeted > > in by anyone, and you can't just ask Fable to fix it all, at least not yet. > > Until this is addressed and not just acknowledged, most of the things > > you've mentioned will remain load-bearing (sorry). Those who haven't worked > > on the internals of the project a lot don't realise how heavily > > load-bearing (sorry) they are. > > > >> On 25 Sep 2026, at 16:13, Josh McKenzie <[email protected]> wrote: > >> > >>> This is by no means a simple matter of needing more testing or less > >>> timeline pressure, > >> > >> Nothing is simple and nobody is claiming it is; these 2 axes are > >> significant. With sufficiently broad testing from a client space (i.e. all > >> CQL types in all combinations with data set sizes up to our supportable > >> limits w/workflows interleaving in a chaos monkey environment, etc. etc. > >> etc) and unbounded time, a storage engine refactor or even wholesale > >> rewrite should be a black-box non-event. I.e. the hyperbolic and > >> hypothetical (and very impossible) extreme of "if our CI suite exercised > >> every workload every user in the world ever runs at every shape with every > >> client concurrency, we could change whatever we wanted with absolute > >> confidence and not disrupt anyone". > >> > >> The opposite extreme: we test (and comment!) nothing and YOLO things in. > >> > >> My contention: in the past, we've been much closer to the YOLO extreme > >> than the "Let's test everything" extreme. All the defects found post 8099 > >> could have been found had we adequate testing of those shapes of workloads > >> prior to that work. We didn't, so it was caught when those shapes were > >> exercised. Unfortunately sometimes in prod. > >> > >> This is why the run up to 4.0 included so much fuzz testing to try and > >> suss those things out in advance; in lieu of deterministically authoring > >> all those tests directly, we're going with the economically sustainable > >> and balanced approach of generative fuzz testing. The number of defects > >> all the testing leading up to 4.0 surfaced supports my hypothesis that > >> vastly more deliberate and robust testing on the project could have > >> prevented much of our pain over the years. > >> > >> I don't think it's computationally reasonable to get to a point where we > >> have sufficient testing to just full pipeline YOLO changes into the > >> database w/out any human oversight or review, and even if it were I very > >> much share everyone's concerns about community building, review being the > >> process through which we connect and learn and grow, feelings of ownership > >> over a domain, maintenance, etc. > >> > >> I do think our project is in a particularly vulnerable place for > >> destabilization by the introduction of any accelerating technology because > >> of how unnecessarily complicated, interconnected, poorly documented, > >> poorly tested, poorly factored / architected / abstraction leaking our > >> current code-base and architecture is. I'd much prefer we invest in > >> improving the robustness of our deterministic exit criteria so we can > >> encourage more contribution and retain confidence in the properties of the > >> system; if we continue to rely on social stratification, domain > >> participation limits, and tooling and workflow gate-keeping to slow things > >> down to a pace our current very weak acceptance gates on the system can > >> validate as "correct enough" we're going to continue to languish as a > >> project right as the rest of the world accelerates. > >> > >> On Fri, Sep 25, 2026, at 9:20 AM, Jason Wee wrote: > >>> > >>> > >>> when ai wrote code, we don't allow it to have bug and worst.. we don't > >>> allow ai to write at all... > >>> > >>> sure, you can argue humans should understand the code... but we stop > >>> at first hand, that actually blocks us from learning... > >>> > >>> When ai wrote the code, people argued that llm comprehension of the > >>> code is difficult to understand but isn't that give a different > >>> perspective on how a code can be rewritten? > >>> > >>> On Fri, Sep 25, 2026 at 6:28 PM Benedict Elliott Smith > >>> <[email protected]> wrote: > >>> > > >>> > 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 > >>> > > >
