Ultimately we came to a similar conclusion and put the project on ice: chunking and vector similarity search are fundamentally not great approaches for code RAG.
I don't really agree with most of Cline's other assertions because those are pretty easy to work around (I suspect they may just be content slop?). It's pretty easy to vectorize and re-chunk code as you change it as long as you have a fixed way of encoding vectors, and you can also generate indices or do more expensive changes to encoding as part of your CI/CD. Indices can be stored in your git repo itself so theres not really a security risk either. Our tool made this pretty easy to do. An index can literally just be a file.
No, the problem is really that vector search (especially with a-kNN) is fundamentally a fuzzy/lossy kind of search, and even when the vector search part works perfectly, your choice of k will usually either include more information than you intend or miss information that didn't meet the top-K threshold. And naive implementations that don't add additional context or are unconditionally searching based on your prompt will probably bias or confuse your model with code that might seem relevant but isn't (eg if you are trying to debug deployments, you include a bunch of your code related to deployments, but the bug is in the application code, and also you have a bunch of deployment scripts in your codebase that are for different platforms and are extra irrelevant).
It's significantly more work to make a vector based approach to code-RAG actually good than it is to get a naive implementation working. We have a different approach to Cline but it's similar in that it uses things like references and how the developer actually understands their codebase.