> will definitely help contributors adhere to standards To me this is actually the big win and the current shape of LLM's as agentic coders is just a kind of forcing function for something we ought to have been doing for new human contributors for ages.
LLM's need the same kind of "fresh onboarding" context that a new contributor would have to be effective in a space (ignoring MCP servers with AST's, code property graphs, etc for now). So I'm a +1 on it from the human angle alone. On Mon, Feb 16, 2026, at 11:03 PM, Bernardo Botella wrote: > Thanks for bringing this up Stefan!! > > A really interesting topic indeed. > > > I’ve also heard ideas around even having Claude.md type of files that help > LLMs understand the code base without having to do a full scan every time. > > So, all and all, putting together something that we as a community think that > describe good practices + repository information not only for the main > Cassandra repository, but also for its subprojects, will definitely help > contributors adhere to standards and us reviewers to ensure that some steps > at least will have been considered. > > Things like: > - Repository structure. What every folder is > - Tests suits and how they work and run > - Git commits standards > - Specific project lint rules (like braces in new lines!) > - Preferred wording style for patches/documentation > > Committed to the projects, and accesible to LLMs, sound like really useful > context for those type of contributions (that are going to keep happening > regardless). > > So curious to read what others think. > Bernardo > > PD. Totally agree that this should change nothing of the quality bar for code > reviews and merged code > > > On Feb 16, 2026, at 6:27 PM, Štefan Miklošovič <[email protected]> > > wrote: > > > > Hey, > > > > This happened recently in kernel space. (1), (2). > > > > What that is doing, as I understand it, is that you can point LLM to > > these resources and then it would be more capable when reviewing > > patches or even writing them. It is kind of a guide / context provided > > to AI prompt. > > > > I can imagine we would just compile something similar, merge it to the > > repo, then if somebody is prompting it then they would have an easier > > job etc etc, less error prone ... adhered to code style etc ... > > > > This might look like a controversial topic but I think we need to > > discuss this. The usage of AI is just more and more frequent. From > > Cassandra's perspective there is just this (3) but I do not think we > > reached any conclusions there (please correct me if I am wrong where > > we are at with AI generated patches). > > > > This is becoming an elephant in the room, I am noticing that some > > patches for Cassandra were prompted by AI completely. I think it would > > be way better if we make it easy for everybody contributing like that. > > > > This does not mean that we, as committers, would believe what AI > > generated blindlessly. Not at all. It would still need to go over the > > formal review as anything else. But acting like this is not happening > > and people are just not going to use AI when trying to contribute is > > not right. We should embrace it in some form ... > > > > 1) https://github.com/masoncl/review-prompts > > 2) > > https://lore.kernel.org/lkml/[email protected]/ > > 3) https://lists.apache.org/thread/j90jn83oz9gy88g08yzv3rgyy0vdqrv7 > >
