[HN Gopher] Why Cline doesn't index your codebase
___________________________________________________________________
Why Cline doesn't index your codebase
Author : intrepidsoldier
Score : 138 points
Date : 2025-05-27 13:44 UTC (9 hours ago)
(HTM) web link (cline.bot)
(TXT) w3m dump (cline.bot)
| coreyh14444 wrote:
| Yep. Have definitely been replacing RAG solutions with
| search+feed the context window instead lately as well.
| spenczar5 wrote:
| What does that mean? In what way does "search and feed" differ
| from "retrieve and augment?" Those are practically synonyms to
| me - is it about tool use vs prompt crafting?
| theturtle32 wrote:
| Correct. RAG is a general term as you describe, but it has
| become inextricably linked with vector databases in the minds
| of a lot of people, to the extent that GP and even the blog
| post we're discussing use RAG specifically to mean the use of
| a vector database after chunking input to create embeddings.
|
| I agree with you that RAG should be a generic term that is
| agnostic to the method of retrieval and augmentation. But at
| the moment, in a lot of people's minds, it specifically means
| using a vector database.
| wat10000 wrote:
| I'm not an expert here, but isn't "search and feed the context
| window" exactly what RAG is?
| PhilippGille wrote:
| Like the other comment already said, the search is still _R_
| etrieval, and putting it into the context window is _A_
| ugmenting, and the LLM request leads to the _G_ eneration.
| A.k.a. RAG.
| jeffchuber wrote:
| 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.
| nick-baumann wrote:
| 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 Code team
| discovered (48:00
| https://youtu.be/zDmW5hJPsvQ?si=wdGyiBGqmo4YHjrn&t=2880). They
| initially experimented with RAG using embeddings but found that
| giving the agent filesystem tools to explore code naturally
| delivered significantly better results.
|
| From our experience, vector similarity often retrieves
| fragments that mention the right keywords but miss the actual
| implementation logic. Following code structure retrieves the
| files a developer would actually need to understand the
| problem.
|
| So yes -- I should have been clearer about the terminology.
| It's not "no retrieval" -- it's structured retrieval vs
| similarity-based retrieval. And with today's frontier models
| having massive context windows and sophisticated reasoning
| capabilities, they're perfectly designed to build understanding
| by exploring code the way developers do, rather than needing
| pre-digested embeddings.
| phillipcarter wrote:
| 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.
| Tycho wrote:
| Don't take this the wrong way, but did you use an LLM to
| generate this reply? The reply is good, but the writing style
| just piqued my curiosity.
| dkubb wrote:
| I wonder if the more we use LLMs the more our written
| patterns will begin to match them. Those of us who work
| with them the most are likely to be affected earliest.
| kunzhi wrote:
| This may not be what is meant here, but I wonder if in the
| future anybody who actually bothered to learn to write well
| will automatically be flagged as likely having used AI to
| write their prose.
|
| For instance, everyone seems to believe that em dashes are
| something only an AI would use -- but I've been using them
| in my writing for a long time.
| jasonjmcghee wrote:
| This doesn't read like an LLM at all...
| aryamaan wrote:
| Hi, nick, given that this product is opensourced, I have a
| request/ wish:
|
| It would be wondeful if some of the tools the projects uses
| are exposed to build on. Like the tools related to AST,
| finding definitions, and many more
| dcreater wrote:
| If you're putting everything in the context window, is it
| still considered "retrieval"? Did we have a preexisting
| robust definition of what constitutes retrieval?
| WhitneyLand wrote:
| The article reads fine to me.
|
| Yes by technicality RAG could mean any retrieval, but in
| practice when people use the term it's almost always referring
| to some sort of vector embedding and similarity searching.
| jamesblonde wrote:
| Wittginstein would concur
| colordrops wrote:
| I guess that's technically true, but RAG has colloquially taken
| on the meaning of vector database retrieval. Perhaps there's a
| paper out there that defines RAG specifically as any data
| retrieval, but at this point in time that's so general a term
| that it's bordering on useless. It's like saying "network
| connected application". No one has said that for decades now
| that it's status quo. Also, there are many types of networks,
| but "network connected app" generally meant TCP, despite it not
| being in the name.
| paxys wrote:
| > it's incredibly important to be clear about terms
|
| Is it? None of these terms even existed a couple of years ago,
| and their meaning is changing day by day.
| throwaway314155 wrote:
| Fairly pedantic take.
| deepdarkforest wrote:
| Terrible stuff and a reddish flag. First of all, gpt signs all
| over the blog post, reads like a bottom of the barrel linkedin
| post.
|
| 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.
| ramesh31 wrote:
| Cline is, hands down, the most effective agentic coding tool
| out there. I've extensively daily driven any one of them you
| can name, and there's nothing even close. The reality is that
| no one knows how any of this stuff should work, and RAG is just
| a term that was made up a few years ago; it has no strict
| formal definition. There's a long way to go before _anyone_
| knows what the correct way to do things should be, but they are
| clearly on the right path from direct experience.
| cdelsolar wrote:
| What's incredible to me is that it's open source. I've
| learned a ton about prompting and agent workflows, tool use,
| etc. from its code.
| MisterSandman wrote:
| That's not universally true. I've had a better experience
| with Amazon Q than I've had with Cline.
| beauzero wrote:
| I agree. This is the golden tool that doesn't get the hype.
| Well as golden as tools get. Hope they can keep delivering.
| It seems to hit my personal sweet spot.
| johnisgood wrote:
| What are the options?
|
| Cursor, Zed, Cline (VSCode), and anything else?
|
| I have not tried either. I wanted to try Cursor but it has a
| bug that is a blocker.
|
| My workflow involves manual copying and pasting from the
| browser into my own text editor.
| ramesh31 wrote:
| >My workflow involves manual copying and pasting from the
| browser into my own text editor.
|
| Cline with mcp-playwright:
| https://github.com/executeautomation/mcp-playwright
|
| There is no free tier like other tools, but it's far more
| transparent in that regard; it uses an
| Anthropic/OpenAI/etc. API key directly, and your only costs
| are direct token usage.
|
| The real "aha" moment with this kind of thing is in
| realizing that the agent can not just use the tool as
| provided, but it can write scripts to dynamically execute
| on the page as well. So it's not just going to a page and
| dumping a bunch of HTML back into the client; it actually
| analyzes the DOM structure and writes JS snippets to
| extract relevant information which are then executed in the
| browser's runtime.
| didibus wrote:
| Amazon Q CLI, Claude Code CLI, Goose with any model,
| OpenAPI released Codex CLI recently, and Google released
| Jules.
|
| You can also just use Claude Desktop and hook it up to MCP
| servers.
| johnisgood wrote:
| I still need to catch up on MCPs, it is still new to me
| and truth be told, I am clueless about it.
| mwigdahl wrote:
| How is it better than Claude Code? I have decent experience
| with CC, but haven't used Cline. Are there good tutorials for
| best practices with it?
| marcellus23 wrote:
| The post may not be written very well (although it seems mostly
| fine to me) but it doesn't seem GPT-written at all. Especially
| as it has obvious typos that LLMs don't make:
|
| > ...and this choice isn't an oversight's a fundamental design
| decision that delivers better code quality, stronger security,
| and more reliable results
| noosphr wrote:
| I build these systems for a living, and I just made a post
| about why code is different from natural text:
| https://news.ycombinator.com/item?id=44107379
|
| RAG is useful for natural text because there is no innate logic
| in how it's structured. RAG chunking based on punctuation for
| natural language doesn't work well because people use
| punctuation pretty poorly and the RAG models are too small to
| learn how they can do it themselves.
|
| Source code, unlike natural text, comes with grammar that must
| be followed for it to even run. From being able to find a
| definition deterministically, to having explicit code blocks,
| you've gotten rid of 90% of the reason why you need chunking
| and ranking in RAG systems.
|
| Just using etags with a rule that captures all the scope of a
| function I've gotten much higher than sota results when it
| comes to working with large existing code bases. Of course the
| fact I was working in lisp made dealing with code blocks and
| context essentially trivial. If you want to look at blub
| languages like python and javascript you need a whole team of
| engineers to deal with all the syntactic cancer.
| esafak wrote:
| RAG does not just mean similarity search. It means retrieving
| all relevant content, including the AST dependencies.
| Whatever you would want to know if you were to answer the
| query yourself.
| noosphr wrote:
| 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.
| esafak wrote:
| 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
| neonwatty wrote:
| The limitations of RAG / strengths of a more structured (AST)
| approach for the case of code are spelled out well. Its punchy
| and too the point. Don't see these issues.
| mindcrash wrote:
| Warning: I don't know what this post does in the background but
| it definitely slows down Firefox 138 to the point that it is
| barely usable
| sbarre wrote:
| Yeah same here, the whole site is just unresponsive... So it's
| not just you.
| lsaferite wrote:
| I almost had to force-quit FF as well.
| electroly wrote:
| I'm not convinced--codebase indexing is still a killer feature in
| Cursor. I have _tens of thousands_ of reference files stashed in
| the project directory to be indexed so that any time the model
| reaches out to the codebase search tool with a question, it finds
| a file with the answer. Lots of it is _not_ code and has no AST
| representation; it 's documentation. Without codebase indexing,
| it may entirely miss the context.
|
| 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.
| chime wrote:
| Same with Augment. Indexing makes a huge difference in a large
| monorepo and I can't imagine working in an editor that doesn't
| support an LLM with full indexing.
| rtfeldman wrote:
| A better argument against vector embeddings for AI code agents
| is that model performance degrades with number of tokens used
| (even when well below the context window limit), and vector
| chunks are more prone to bloating the context window with
| unhelpful noise than more targeted search techniques.
|
| Claude Code doesn't do vector indexing, and neither does Zed.
| There aren't any rigorous studies comparing these tools, but
| you can find plenty of anecdotes of people preferring the
| output of Claude Code and/or Zed to Cursor's, and search
| technique is certainly a factor there!
| bryanlarsen wrote:
| Sounds like you're the exception rather than the rule. I've
| never seen a project with tens of thousands of files worth of
| accurate documentation. Any project that has that much
| documentation the majority of it is outdated and/or wrong. Some
| of it is still useful, but only in a historical context.
|
| The code is the authoritative reference.
| electroly wrote:
| Sure, I'm a power user with a monster codebase, never said
| that I wasn't. RAG is a power user feature.
|
| The files are generated from external sources, pulling
| together as much information as I could collect. It's a
| script so I can keep it up to date. I think there is roughly
| no programmer out there who needs to be told that
| documentation needs to be up-to-date; this is obvious enough
| that I'm trying not to be offended by your strawman. You
| could have politely assumed, since I said I have it working,
| that it does actually work. I am doing productive work with
| this; it's not theoretical.
| bryanlarsen wrote:
| By documentation I assumed you meant internal
| documentation, like on a company Wiki.
|
| External documentation is presumably already in the LLM's
| training data, so it should be extraneous to pull it into
| context. Obviously there's a huge difference between
| "should be" and "is" otherwise you wouldn't be putting in
| the work to pull it into context.
| electroly wrote:
| I'd guess the breakdown is about:
|
| - 80%: Information about databases. Schemas, sample rows,
| sample SQL usages (including buried inside string
| literals and obscured by ORMs), comments, hand-written
| docs. I collect everything I can find about each
| table/view/procedure and stick it in a file named after
| it.
|
| - 10%: Swagger JSONs for internal APIs I have access to,
| plus sample responses.
|
| - 10%: Public API documentation that it should know but
| doesn't.
|
| The last 10% isn't nothing; I shouldn't have to do that
| and it's as you say. I've particularly had problems with
| Apple's documentation; higher than expected hallucunation
| rate in Swift when I don't provide the docs explicitly.
| Their docs require JavaScript (and _don 't_ work with
| Cursor's documentation indexing feature) which gives me a
| hunch about what might have happened. It was a pain in
| the neck for me to scrape it. I expect this part to go
| away as tooling gets better.
|
| The first 90% I expect to be replaced by better MCP tools
| over time, which integrate vector indexing along with
| traditional indexing/exploration techniques. I've got one
| written to allow AI to interactively poke around the
| database, but I've found it's not as effective as the
| vector index.
| behnamoh wrote:
| I never had good experience with RAG anyway, and it felt "hacky".
| Not to mention most of it basically died when most models started
| supporting +1M context.
|
| LLMs are already stochastic. I don't want yet another layer of
| randomness on top.
| WaltPurvis wrote:
| >Not to mention most of it basically died when most models
| started supporting +1M context.
|
| Do most models support that much context? I don't think
| anything close to "most" models support 1M+ context. I'm only
| aware of Gemini, but I'd love to learn about others.
| fkyoureadthedoc wrote:
| GPT 4.1 / mini / nano
| consumer451 wrote:
| As the context grows, all LLMs appear to turn into idiots,
| even just at 32k!
|
| > We evaluate 12 popular LLMs that claim to support
| contexts of at least 128K tokens. While they perform well
| in short contexts (<1K), performance degrades significantly
| as context length increases. At 32K, for instance, 10
| models drop below 50% of their strong short-length
| baselines. Even GPT-4o, one of the top-performing
| exceptions, experiences a reduction from an almost-perfect
| baseline of 99.3% to 69.7%.
|
| https://news.ycombinator.com/item?id=44107536
| rs186 wrote:
| This paper is slightly outdated by LLM model standards --
| GPT 4.1 or Gemini 2.5 haven't been released at that time.
| consumer451 wrote:
| Yes, I mentioned that in the comment in the linked post.
| I wish someone was running this methodology as an ongoing
| project, for new models.
|
| Ideally, isn't this a metric that should be included on
| all model cards? It seems like a crucial metric.
| heyhuy wrote:
| > and it felt "hacky"
|
| I think the pattern that coined "RAG" is outdated, that pattern
| being relying on cosine similarities against an index. It was a
| stop gap for the 4K token window era. For AI copilots, I love
| Claude Code, Cline's approach of just following imports and
| dependencies naturally. Land on a file and let it traverse.
|
| No more crossing your fingers with match consign and hoping
| your reranker did drop a critical piece.
| cdelsolar wrote:
| Cline is the most impressive agentic coder tool I've used and it
| seems to be getting better. I've learned to work with it to the
| extent where I can plan with it for 10-15 minutes, set it loose
| on my codebase, go get lunch, and then its diff is almost always
| completely on the money. You should commit often for those rare
| cases where it goes off the rails (which seems to happen less
| frequently now).
|
| 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.
| atonse wrote:
| I've always wondered... Making agents edits (like vibe coding),
| all the tools I've tried (Cursor, Zed, VSCode) are pretty equal
| since most of the brains are in the underlying models
| themselves.
|
| But the killer app that keeps me using Cursor is Cursor Tab,
| which helps you WHILE you code.
|
| Whatever model they have for that works beautifully for me,
| whereas Zed's autocomplete model is the last thing that keeps
| me away from it.
|
| What do Cline users use for the inline autocomplete model?
| nlh wrote:
| I use Cline within Cursor -- best of both worlds!
| atonse wrote:
| What's the benefit? If you're paying $20/month for cursor
| you already get all the agentic coding as part of it.
| esafak wrote:
| "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
| bicepjai wrote:
| They are saving time and tokens. They are rescanning the files
| locally using parsing and AST without sending tokens to the
| model which
| nico wrote:
| They could still RAG the AST and just use different chunking
| strategies
|
| 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
| rtuin wrote:
| Totally irrelevant on the subject, but the screen recording in
| the article caught my attention: what tool does one use to create
| the screen recording with zoom and mouse tracking?
| randomchars wrote:
| The most popular one is Screen Studio[0], but there are a few
| alternatives there, like Tella[1].
|
| [0]: https://screen.studio/
|
| [1]: https://landingpage.tella.com/
| flashblaze wrote:
| Since I use Windows and Screen Studio is Mac only, I tried
| Tella and can definitely vouch for it. (I am on their free
| trial though)
| vunderba wrote:
| Screen Studio is fantastic and unlike a lot of other
| commercial screen recorders has a one-time purchase cost
| (though you can also pay monthly).
| NitpickLawyer wrote:
| Eh... I'm not convinced. I like cline, I've been using it here
| and there and I think it found a good mix between "vibesus take
| the wheel" and "hey, I'm still here and I enjoy doing this". I
| was particularly surprised that it worked pretty well with local
| models. A lot of that is on the model (tested w/ devstral) but a
| lot of it is on the cradle (e.g. aider is great at what it does,
| but local model support is hit and miss).
|
| 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?
| avereveard wrote:
| at some point they will move from scanning files to scannign
| the AST and then token consumption will be greatly reduced by
| default, the challenge is that then you need something generic
| enough like tree-sitter to reduce the monumental effort of
| integrating a number of parsers.
| layer8 wrote:
| Why would an AST greatly reduce LLM token consumption?
| bicepjai wrote:
| More focus on what to use rather when the whole file where
| the code snippet sits
| layer8 wrote:
| I see, it could in principle more easily prune subtree
| that aren't relevant. Initially I was assuming that the
| LLM would still ingest the whole AST in some form, since
| OP wrote "scanning the AST". Does that mean the LLM would
| be invoking some sort of tool to perform a query on the
| AST?
| avereveard wrote:
| a lot of token are used reading files whole just to
| understand where to fit the feature requested and the edit
| point, access to an AST would allow the llm to see the
| project "wireframe" so to say, by asking classes or method
| level granularity, and only then retrieving the source for
| the symbol that most likely contains the edit point the llm
| needs. some token consumption there is anovaidable as the
| llm need the source to build a diff, but still, it's
| focused on the feature than the search.
| wejick wrote:
| I noticed that Sonnet 4 likes to use code search tool in cursor.
| Probably giving model option of tool to use is not bad thing to
| do.
| k__ wrote:
| Cursor does it.
|
| Cline doesn't.
|
| Aider goes the middle way with repo maps.
|
| Let's see what works best.
| bryanlarsen wrote:
| What's the difference between Aider's repo map and the Cline
| AST? Sounds like a small difference in implementation than a
| difference in concept.
| k__ wrote:
| I think, the repomap is an AST that doesn't go down all the
| way.
| wiradikusuma wrote:
| 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?
| therealmarv wrote:
| I would even classify aider a different way because it avoids
| what the blog posts is talking about (or moves the
| responsibility more to the human). In aider you can manually
| define or basically override which files are important for your
| context and for the LLM to know. With 1M context windows that's
| like a no brainer (except for extremely massive projects). I
| mean the repo map truly helps but I compare it with like
| driving a manual car... you shift the gears yourself by
| selecting the relevant files yourself and not your "automatic
| car"/AI code assistant for you like on cursor, cline, roo,
| claude code etc.
| didibus wrote:
| I thought Cursor had support for MCP now? So in theory it can
| now navigate the code base, query for code structure, and so on
| as well no?
| ramoz wrote:
| I kept wondering why Cursor was indexing my codebase, it was
| never clear.
|
| 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
| anukin wrote:
| How does this work?
|
| It's not clear how context is used to plan by Gemini then the
| plan is fed to local framework. Do I have to replan every time
| context changes?
| woah wrote:
| They use a tool like the one they linked to put all their
| files into one file that they give to gemini.
|
| Then they put the plan into their "PM framework" (some
| markdown files?) to have Claude Code pick tasks out of.
| greymalik wrote:
| Can you give an example of a local PM framework? What happens
| in this step - ticket creation?
| olejorgenb wrote:
| 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.
| arthur-st wrote:
| Aider has been doing that for a long time now, it was the first
| project to do this afaik.
| izabera wrote:
| the third point is applicable to a number of tools and systems,
| but who would claim that using git doubles your security surface?
| jjani wrote:
| The security argument is a valid one, as long as the prompts
| aren't passing through Cline's servers but instead directly sent
| to the LLM providers. If they go through an intermediary step,
| it's a pretty pointless difference. Yet it's very hard to make
| money off of a coding assistant where the prompts _don 't_ pass
| through their servers in one way or form. Cline is for-profit and
| currently their only monetization is to get users to use their
| credits system, meaning prompts go through them. In other words,
| if Cline is to succeed and monetize you, the security advantage
| sounds questionable.
|
| 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.
| layer8 wrote:
| > This is a hilariously obvious LLM sentence by the way:
|
| > > Your codebase isn't just text - it's your competitive
| advantage
|
| An LLM would have correctly used an em dash, not an en dash. ;)
| jjani wrote:
| This is so well-known by now that replacing those is
| tablestakes :) The ".. isn't just A - it's B" isn't yet to
| the greater public.
|
| This pattern is so prevalent that in any decent LLM business
| content generation product you're forced to hardcode
| avoidance/removal of that phrase, otherwise it's bound to
| show up in every article.
| never_inline wrote:
| Even cline documentation seems to be slop generated.
| WhitneyLand wrote:
| I generally agree with the article and the approach given
| practical constraints, however it's all stop gap anyway.
|
| 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...
| loandbehold wrote:
| 1 million tokens is still not enough for real life codebases
| (100Ks to millions loc)
| simonklee wrote:
| And it's obviously expensive use this approach.
| orbital-decay wrote:
| It's always a tradeoff, and most of the time chunking and
| keeping the context short performs better.
|
| I feed long context tasks to each new model and snapshot just
| to test the performance improvements, and every time it's
| immediately obvious that no current model can handle its own
| max context. I do not believe any benchmarks, because contrary
| to the results of many of them, no matter what the (coding)
| task is, the results start getting worse after just a couple
| dozen thousand tokens, and after a hundred the accuracy becomes
| unacceptable. Lost-in-the-middle is still a big issue as well,
| at least for reasoning if not for direct recall - despite
| benchmarks showing it's not. LLMs are still pretty unreliable
| at one-shotting big things, and everything around it is still
| alchemy.
| crop_rotation wrote:
| After trying cline,aider,codex, and what not, I feel claude code
| is just so so better than all of them. e.g It takes much much
| fewer prompts to be able to do the same thing compared to cline.
| tbh I am not sure how cline will compete against something like
| Claude code due to the resource/capability imbalance. Does anyone
| else have a different experience?
| loandbehold wrote:
| Same experience. Claude Code is much better than all other
| tools. I suspect Claude Code uses some private features of
| Claude model that's not available to other tools. It only makes
| sense that Anthropic will develop their model in conjunction
| with the tool to produce best result.
| XenophileJKO wrote:
| I really felt like Claude Code would benefit greatly from a
| similar structural map. The little map it made in the Claude.md
| is insufficient. When the code base grows or you add a more
| componentized approach, Claude Code started favoring a locality
| bias which increases the architectural entropy a LOT.
| weitendorf wrote:
| My company is working on a similar tool to Cline, and we had an
| intern project last summer to create a tool for AI-for-coding
| RAG: https://github.com/accretional/semantifly
|
| 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.
| 3cats-in-a-coat wrote:
| This seems like a marketing piece, very poorly justified.
|
| 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).
| cat-whisperer wrote:
| 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?
| silverlake wrote:
| Have you guys at Cline considered using LLMs to create summaries
| of files and complex functions? Rather than read a 500 line
| function, feed it a short comment on what the function is doing.
| I'd like to use a local LLM to create summaries at every level:
| function, file, directory. Then let the LLM use that to find the
| right code to read. This is basically how I navigate a large code
| base.
| dpe82 wrote:
| I've just used Cline to produce files like that, and then later
| when starting a task in plan mode I tell it to read those files
| to get a sense of the project's structure. I also tell it to
| update them as necessary after whatever task we're doing is
| finished.
| jdoliner wrote:
| Does anybody else see high CPU and GPU utilization on this site
| with a process called ClineBot?
___________________________________________________________________
(page generated 2025-05-27 23:01 UTC)