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.
> 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. ;)
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.