| We'll queue up database schemas, good call. On RAG, I have a lot of thoughts - it's my pet project to make it work really well. We started out down this road but in practice getting good results out of RAG has been shockingly hard on bigger, more complicated codebases. In many cases when we put this in front of devs that know their code, the RAG part has been a lossy approximation of what they already knew the relevant code to be, so they'd sit there and watch "is this thing going to find the code that I already know I need for this task" I think the key here will be a robust, language-agnostic symbol graph that maps out high-resolution dependencies, so when you are retrieving `foo`, you can also efficiently retrieve the references to and from of `foo` to some depth (often greater than 1). Some languages have better tools for this kind of symbol resolution than others, but in many cases they're highly bespoke. Github's stack-graphs and Sourcegraph's SCIP are the best attempts I've seen at solving this in a generic way, but neither of them have gotten all the way there yet. I've been half-seriously thinking about running neovim in headless mode and using it as an interface to all the LSP's for each language, and resolving all the edges of the symbol graph that way - I might still try it one of these days On design doc convention - I think you're right, it's not completely 1-1 with the term today, and there's not a single definition that everyone agrees on. We're using it as the initial mental model of where we want to plug in, but there might be a better succinct way to describe it Haven't tried the raw ast yet, curious how that goes |