111–120 of 131 posts
https://docs.roocode.com/features/experimental/codebase-inde...
Augment Code's secret sauce is largely its code indexer, and I find it to be the best coding agent around.
Earlier quoted context omitted.
Fair point Jeff -- you're right that we're still doing retrieval. The key distinction is how we retrieve. Traditional RAG for code uses vector embeddings and similarity search. We use filesystem traversal and AST parsing - following imports, tracing dependencies, reading files in logical order. It's retrieval guided by code structure rather than semantic similarity. I highly recommend checking out what the Claude Cod…
Probably good to add a disclaimer at the top that clarifies the definition, since RAG is ultimately just a pattern, and vector indexes are just one way to implement the pattern. Indeed, industry at large sees RAG as equivalent to "vector indexes and cosine similarity w.r.t. input query", and the rest of the article explains thoroughly why that's not the right approach.
Yep, and this is getting really old. Information retrieval is not a new problem domain. Somehow, when retrieved info is fed into an LLM, all nuance is lost and we end up with endless pronouncements about whether retrieval is/is not "dead".
Earlier quoted context omitted.
Than it must be able to search every book and paper ever written because when it comes to deciding if an algorithm is correct I need to read the original paper that defined it and any updates in the literature since then. Since that rag system doesn't, and probably will never, exist we are stuck with vector embeddings as the common definition everyone working in the field uses and understands.
If you were to do this by hand, would you search every book and paper ever written? That is not feasible so you have to make a trade-off. For alternatives to vector search, see GraphRAG and AST parsing; e.g., https://vxrl.medium.com/enhancing-llm-code-generation-with-r... or https://github.com/sankalp1999/code_qa
Which incidentally shows why RAG just means vector store + embedding model, since your definition means different things to different people and an implementation can't exist until we figure out AGI.
What about doing something just-in-time? I'm just speculating, but what if cline leverages the LSP (for instance, rust-analyzer) to track the function chain and build a tree-like context of the codebase—not the entire codebase, but just specific blobs of code? Would that work?
This is still retrieval and RAG, just not vector search and indexing. it’s incredibly important to be clear about terms - and this article does not meet the mark.
Fair point Jeff -- you're right that we're still doing retrieval. The key distinction is how we retrieve. Traditional RAG for code uses vector embeddings and similarity search. We use filesystem traversal and AST parsing - following imports, tracing dependencies, reading files in logical order. It's retrieval guided by code structure rather than semantic similarity. I highly recommend checking out what the Claude Cod…
Cursor does it. Cline doesn't. Aider goes the middle way with repo maps. Let's see what works best.
When I'm in the middle of a conversation with AI, sometimes I like to change the code immediately ("Oh that's wrong, let me fix that first"). Does it mess the context? Or I need to close/Ctrl+C and reopen?
Btw. You can also trigger Aider via comments. This way you can mix it with your changes immediately.
This is still retrieval and RAG, just not vector search and indexing. it’s incredibly important to be clear about terms - and this article does not meet the mark.
Fair point Jeff -- you're right that we're still doing retrieval. The key distinction is how we retrieve. Traditional RAG for code uses vector embeddings and similarity search. We use filesystem traversal and AST parsing - following imports, tracing dependencies, reading files in logical order. It's retrieval guided by code structure rather than semantic similarity. I highly recommend checking out what the Claude Cod…
"We Don't Dynamically Index Your Codebase So We Recan It with Every Query". Wasting time and tokens like this is not something to brag about. If indexing is so hard maybe someone should start a company just to do that, like https://news.ycombinator.com/item?id=44097699
They are saving time and tokens. They are rescanning the files locally using parsing and AST without sending tokens to the model which
I've been wondering when someone would finally use the actual code structure to do RAG. It seems like such an obvious, if somewhat harder (at least if you need to support many languages), approach. The vector/keyword based RAG results I've seen so far for large code bases (my experience is Cody) has been quite bad. For a smaller projects (using Cursor) it seems to work quite well though.
Roo Code experimental code indexing using vector DB dropped 3 days ago. Theire using Tree-sitter (the same as Aider) to parse sources into ASTs and do vector embedding on that product, instead of plaintext.