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. > 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 >>> >
