Context size is the hardest thing to manage right now in agentic coding. I’ve stopped using MCP and switched to skills as a result.
A couple of things worth noting. You can use many multiple CLAUDE.md/AGENT.md files in a large code base. I’m started doing this and it is remarkable. For example, in the pylib directory a CLAUDE.md file would provide the Python specific info if making changes. The standard layout for each should be - What is this - Where do I get more information - How do I run or test - What are the non-nogetialble rules - What does done look like Imagine one in all sorts of places. fqtool, sstableloader, o.a.c.io <http://o.a.c.io/>.*, o.a.c.repair.* etc etc. And they can evolve over time as people use them. The other thing to bring up is Brokk built by Jonathan Ellis. He specifically built it for large code bases and specifically tests on the Cassandra code base. (I’ll let him jump in here) Patrick > On Feb 18, 2026, at 8:51 AM, Josh McKenzie <[email protected]> wrote: > >> I’ve had trouble using Claude effectively on C*’s large codebase without a >> lot of repeated “repo discovery” prompting. > Just to keep beating the drum: I've had trouble working in our codebase > effectively without a lot of repeated "repo discovery" time. In fact, a huge > portion of the time I spend working on the codebase consists of reading into > adjacent coupled classes and modules since things are a) not consistently or > thoroughly documented, and b) generally not that decoupled. > > This is also / primarily a "human <-> information interfacing efficiency > problem" and it just so happens LLM's and agents being blocked from working > on our codebase is giving us an immediate short-term pain-proxy for something > I strongly believe has been a long-term tax on us. > > On Wed, Feb 18, 2026, at 10:04 AM, Isaac Reath wrote: >> I'm a +1 for the same reason that Josh lays out. Markdown files that detail >> the structure of the repo, how to build & run tests, how to get checkstyle >> to pass, etc. are all very valuable to new contributors even if LLMs went >> away today. >> >> On Tue, Feb 17, 2026 at 7:33 PM Jon Haddad <[email protected] >> <mailto:[email protected]>> wrote: >> It's all part of the same topic, Yifan. You're making a distinction without >> a difference. We could just as easily be discussing supporting certain MCP >> servers like serena, or baking claude into a devcontainer. It's all >> relevant. There's no need to police the discussion. >> >> On Tue, Feb 17, 2026 at 4:25 PM Yifan Cai <[email protected] >> <mailto:[email protected]>> wrote: >> The original post was about adding AI tooling, prompt, command, or skill. >> The thread is shifted to AI memory files. >> >> I do not have an objection to any of these, but want to make sure that we >> are still on the original topic. >> >> IMO, AI tooling has a clear scope / definition and is easier to reach >> consensus on. Meanwhile, AI memory files are vague to define clearly. >> Different developers on different domains could have quite different >> preferences. >> >> - Yifan >> >> On Tue, Feb 17, 2026 at 3:37 PM Dmitry Konstantinov <[email protected] >> <mailto:[email protected]>> wrote: >> I do not have my one but here there are few examples from oher Apache >> projects: >> https://github.com/apache/camel/blob/main/AGENTS.md >> https://github.com/apache/ignite-3/blob/main/CLAUDE.md >> https://github.com/apache/superset/blob/master/superset/mcp_service/CLAUDE.md >> >> >> On Tue, 17 Feb 2026 at 23:22, Jon Haddad <[email protected] >> <mailto:[email protected]>> wrote: >> I think a few folks are already using CLAUDE.md files in their repo and >> they're just not committing them. >> Anyone want to share what's already done? I'm happy to help share what I >> know about the agentic side of things, but since I don't do much in the way >> of patching C* it would be a lot of guessing. >> >> If I'm wrong and nobody shares one, I'll take a stab at it. >> >> >> >> On Tue, Feb 17, 2026 at 3:08 PM Štefan Miklošovič <[email protected] >> <mailto:[email protected]>> wrote: >> Great feedback everybody! Really appreciate it! >> >> Reading what Jon posted ... Jon, I think you are the most experienced >> in this based on what you wrote. Would you mind doing some POC here >> for Cassandra repo? For the trunk it is enough ... Something we might >> build further on. I think we need to build the foundations of that and >> put some structure into it and all things considered I think you are >> best for the job here. >> >> If the basics are there we can play with it more before merging, this >> is not something which needs to be done "tomorrow", we can collaborate >> on something together for some time and add things into it as patches >> come. I think it takes some time to "tune" it. >> >> Everybody else feel free to help! My experience in this space is >> limited, I think there are people who are using it more often than me >> for sure. >> >> Regards >> >> On Wed, Feb 18, 2026 at 12:59 AM Joel Shepherd <[email protected] >> <mailto:[email protected]>> wrote: >> > >> > There's been some momentum building for AGENTS.md files, both on the >> > project and on the agent side: >> > >> > https://agents.md/ >> > >> > Same idea and benefits, but it might help to align folks on a "standard" >> > that will work well across agents. >> > >> > I also think that more and better code documentation can be very >> > beneficial when using agents to help with working out implementation >> > details. I spent a bunch of time in January writing an introduction to >> > Apache Ratis (Raft as a library: >> > https://github.com/apache/ratis/blob/master/ratis-docs/src/site/markdown/index.md). >> > The code itself is pretty well-documented but it was hard for me to >> > build a mental model of how to integrate with. AI was very effective in >> > taking the granular in-code documentation and synthesizing an overview >> > from it. Going the other way, the in-code documentation has made it >> > possible for me to deep dive the Ratis code to root cause bugs, etc. >> > Agents can get a lot out of good class- and method-level documentation. >> > >> > -- Joel. >> > >> > On 2/16/2026 8:03 PM, Bernardo Botella wrote: >> > > CAUTION: This email originated from outside of the organization. Do not >> > > click links or open attachments unless you can confirm the sender and >> > > know the content is safe. >> > > >> > > >> > > >> > > 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] >> > >> <mailto:[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 >> >> >> -- >> Dmitry Konstantinov >
