> 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.
In an environment where we already require involvement (and therefore independent understanding) from 2 committers, I'm worried these two things would only be feasible together if the additional reviewer did not have to be a committer. On Tue, Sep 22, 2026 at 10:37 PM Caleb Rackliffe <[email protected]> wrote: > To expand on that, it feels like the questions are around how prescriptive > we are going to be and how much support we'll provide? (ex. Do we provide a > project CLAUDE.md that influences things like JavaDoc brevity?) > > On Tue, Sep 22, 2026 at 10:27 PM Caleb Rackliffe <[email protected]> > wrote: > >> > All public prose must be human authored. This includes inline comments, >> docs, posts to Jira etc. >> >> I agree with this if by "authored" we mean "authored or closely audited >> for brevity and correctness". The value of verbose inline documentation in >> our world is certainly declining, and all but the most necessary comments >> risk confusing LLM comprehension of the codebase rather than enhancing it. >> >> On Tue, Sep 22, 2026 at 9:13 PM guo Maxwell <[email protected]> wrote: >> >>> +1 on this suggestion. >>> >>> 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 >>> >>> >>> Besides, in light of this perspective, should we produce a list of >>> module maintainers? These maintainers could be PMC members or committers. >>> >>> Jon Haddad <[email protected]> 于2026年9月23日周三 03:03写道： >>> >>>> Agreed, Josh. >>>> >>>> Threatening to blindly -1 patches based on a hunch that someone used an >>>> LLM to work on it isn't productive. It's certainly not a door that should >>>> be opened, because it swings both ways. If people start -1'ing patches >>>> because of bitter feelings instead of technical reasoning, why would anyone >>>> want to contribute? >>>> >>>> I am -1 on the policy suggestion. This project is *struggling* to get >>>> things merged in. The idea that we wouldn't take advantage of LLMs to >>>> write or review code doesn't make any sense to me at all. >>>> >>>> Jon >>>> >>>> >>>> On Tue, Sep 22, 2026 at 11:55 AM Josh McKenzie <[email protected]> >>>> wrote: >>>> >>>>> to focus minds, I will remind everyone that the project rules permit >>>>> unilateral vetoes on contributions, and in the absence of any policy on >>>>> the >>>>> matter that includes AI generated contributions. >>>>> >>>>> Personal opinion here, but this is a counter-productive way to open a >>>>> collaborative discussion. >>>>> >>>>> Since this is out here on thread, I'll take it upon myself to clarify >>>>> the official policy for anyone that's not aware: >>>>> >>>>> https://cwiki.apache.org/confluence/spaces/CASSANDRA/pages/158863606/Cassandra+Project+Governance >>>>> >>>>> >>>>> - Code must not be committed while subject to an explicit -1 vote >>>>> by a committer for clearly expressed and reasonable technical grounds >>>>> - If code has been committed but not released, a -1 vote from a >>>>> committer (that is not resolved by follow-up commits) can be reverted >>>>> - If the proposer responds to the concerns of a -1 voter, and the >>>>> -1 voter does not engage reasonably with the response, the -1 is >>>>> rescinded >>>>> - Committers should explicitly veto work *exceptionally rarely* >>>>> >>>>> >>>>> I read this as more nuanced than "project rules permit unilateral >>>>> vetoes on contributions". >>>>> >>>>> On Tue, Sep 22, 2026, at 6:27 AM, Benedict wrote: >>>>> >>>>> Hi everyone. Let me preface this by saying that we need a policy on >>>>> this, and we will probably struggle to reach a consensus. So to focus >>>>> minds, I will remind everyone that the project rules permit unilateral >>>>> vetoes on contributions, and in the absence of any policy on the matter >>>>> that includes AI generated contributions. >>>>> >>>>> My proposal in brief is that LLM usage is >>>>> >>>>> ===== >>>>> 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>" >>>>> ===== >>>>> >>>>> I will keep my argumentation brief. >>>>> >>>>> LLM generated changes: >>>>> - Break the community and knowledge-building aspect of patch >>>>> review, since the contributor is not clearly learning from the feedback >>>>> process >>>>> - Flips the asymmetry between author and reviewer/maintainer: it >>>>> is now cheaper to write than review or maintain >>>>> - Does not demonstrate expertise, commitment or that they can or >>>>> will maintain the patch >>>>> >>>>> For these reasons, it should be expected that the person producing the >>>>> patch has already demonstrated their expertise and commitment by producing >>>>> and maintaining similar patches without the use of AI >>>>> >>>>> Authoring a patch results in deeper understanding. To offset the >>>>> reduced collective knowledge of LLM generated changes, and improve our >>>>> ability to confidently maintain it, we should expect changes to be more >>>>> widely socialised through an additional review. >>>>> >>>>> Finally, LLM comments are worse than no comment. An author must ensure >>>>> their reader's time is valued, by investing their own time crafting a >>>>> message with a proper understanding of its intended audience. LLMs may >>>>> assist in preparation, but must not produce the content itself. >>>>> >>>>> I don't believe this fully accounts for all of the risks posed by AI >>>>> usage in the project, especially regarding maintainability of the codebase >>>>> and maintaining the community. But I hope this middle-ground policy will >>>>> prove to be acceptable to enough of the community. >>>>> >>>>> >>>>>
