Yes, this works very well, and I recommend it. Here's my CLAUDE.md from easy-db-lab as an example [1]
Here's what I've found useful: - You can tell it to be aware of certain conventions, relationships between types, tools, shortcuts. - You can tell it to run static analysis to find issues with the code it's writing. Very useful in preventing cyclomatic complexity from spiraling out of control. I use detekt with Kotlin, but you can just as easily use PMD / Spotless. - You can tell it the types of testing you want. Integration, in-jvm tests, unit tests, mocking. - Libraries it should use to solve specific problems. For example, when writing tests for easy-db-lab, I lean on LocalStack since they created test constructs for a lot of AWS. Saves me a ton of time. - Use the hierarchy to your advantage. You can have a file at every level getting more specific as you drill down. - Claude can do the analysis and write the files to give you a good starting point too. - Telling it to use SOLID principles helps a TON, but you need to define that a bit more clearly or you end up with things like DestoyVPCService instead of a class that does all your crud on VPCs. - They are *great* at refactoring. Would be a great opportunity to pay off some technical debt. I've used Claude to do the refactoring projects I was absolutely dreading. > 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. Yes, agreed. Test coverage, documentation and well defined architectural boundaries are good for people and the machines :) Imo, the bar for code quality can be higher when leaning on these tools, because you can spend more brain power on solving real problems. You can put skills in repo itself for common tasks that are a bit complicated. I just published a marketplace [2] that has skills for C* tuning, diagnosing issues and data modeling. To apply this to the C* repo, we could have skills to help create in-jvm dtests, and we could be fairly detailed about the right way to build them. Skills are loaded on demand, so they don't eat up all your context. Useful for when you have a lot of complicated things you want to do, but don't need them all the time. I've been committing around 10-20K LOC a week with Claude. Takes a minute to put the right guardrails in place. Once they're there, it's incredibly impressive. Jon [1] https://github.com/rustyrazorblade/easy-db-lab/blob/main/CLAUDE.md [2] https://github.com/rustyrazorblade/skills On Tue, Feb 17, 2026 at 9:09 AM Josh McKenzie <[email protected]> wrote: > 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 > > > >
