Why Cline doesn't index your codebase

Using Gemini 2.5’s 1MM token context window to work with large systems of code at once immediately feels far superior to any other approach. It allows using an LLM for things that are not possible otherwise.

Of course it’s damn expensive and so hard to do in a high quality way it’s rare luxury, for now…

Anyway context to me enables a lot more assurance and guarantees. RAG never did.

My favorite workflow right now is:

  - Create context with https://github.com/backnotprop/prompt-tower
  - Feed it to Gemini
  - Gemini Plans
  - I pass the plan into my local PM framework
  - Claude Code picks it up and executes
  - repeat

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.

Would that work?

LLMs are already stochastic. I don't want yet another layer of randomness on top.

Cline doesn't.

Aider goes the middle way with repo maps.

Let's see what works best.

First, like some other comments have mentioned RAG is more than result = library.rag(). I get that a lot of people feel RAG is overhyped, but it's important to have the right mind model around it. It is a technique first. A pattern. Whenever you choose what to include in the context you are performing RAG. Retrieve something from somewhere and put it in context. Cline seems to delegate this task to the model via agentic flows, and that's OK. But it's still RAG. The model chooses (via tool calls) what to Retrieve.

I'm also not convinced that embedding can't be productive. I think nick is right to point out some flaws in the current implementations, but that doesn't mean the concept in itself is flawed. You can always improve the flows. I think there's a lot to gain from having embeddings, especially since they capture things that ASTs don't (comments, doc files, etc).

Another aspect is the overall efficiency. If you have somewhat repetitive tasks, you'll do this dance every time. Hey, fix that thing in auth. Well, let's see where's auth. Read file1. Read file2. Read fileN. OK, the issue is in ... You can RAG this whole process once and re-use (some) of this computation. Or you can do "graphRAG" and do this heavy lifting once per project and have AST + graph + model dump that can be RAGd. There's a lot of cool things you can do.

In general I don't think we know enough about the subject, best practices and useful flows to confidently say "NO, never, nuh-huuh". I think there might be value there, and efficiencies to be gained, and some of them seem like really low hanging fruit. Why not take them?

1. This argument seems flawed. Codebase search gives it a "foot in the door"; from that point it can read the rest of the file to get the remaining context. This is what Cursor does. It's the benefit of the agentic loop; no single tool call needs to provide the whole picture.

2. This argument is "because it's hard we shouldn't do it". Cursor does it. Just update the index when the code changes. Come on.

3. This argument is also "because it's hard we shouldn't do it". Cursor does it. The embeddings go in the cloud and the code is local. Enforced Privacy Mode exists. You can just actually implement these features rather than throwing your hands up and saying it's too hard.

This honestly makes me think less of Cline. They're wrong about this and it seems like they're trying to do damage control because they're missing a major feature.

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.

It doesn’t seems like what they are doing necessarily replaced RAG, even if it can

The times I’ve implemented RAG, I’ve seen an immediate significant improvement in the answers provided by the model

Maybe they need some metrics to properly assess RAG vs no-RAG

This is a hilariously obvious LLM sentence by the way:

> Your codebase isn't just text – it's your competitive advantage

When creating articles aimed at LLM power users (which this one is), just have a human write it. We can see through the slop. Come on, you're VC backed, if you were bootstrapping I wouldn't even be calling this out.

The other arguments I used to agree with - compression and RAG means loss of quality, increasing context windows and decreasing prices means you should just send a lot of context.

Then I tried Augment and their indexing/RAG just works, period, so now I'm not convinced anymore.

First, large context models essentially index their context as it grows bigger, or else they can't access the relevant parts of it. However it can't be as comprehensive as with RAG. There is also nothing that makes navigating the context from point to point easier than with RAG.

It seems they're trying to convince people of their superiority, but it's BS, so they're trying to bank on less knowledgeable customers.

Indexing is essentially a sorted projection of a larger space, based on the traits and context you care about. There's no magical way for a context to be more accessible, if it has no such semantical indexing, implicit or explicit. Also RAG doesn't mean you can't embed AST and file structure as a concern. A vector is a set of dimensions, a dimension can be literally anything at all. AI is about finding suitable meaning for each dimension and embedding instances in that dimension (and others in combo).

Using Gemini 2.5 pro is also pretty cheap, I think they figured out prompt caching because it definitely was not cheap when it came out.

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

But more importantly, why double and triple down on no RAG? As with most techniques, it has its merits in certain scenarios. I understand getting VC money so you have to prove differentiation and conviction in your approach, but why do it like this? What if RAG does end up being useful? You'll just have to admit you were wrong and cursor and others were right? I don't get it.

Just say we don't believe RAG is as useful for now and we take a different approach. But tripling down on a technique so early into such a new field seems immature to me. It screams of wanting to look different for the sake of it.