Our team has adopted Cline for routine refactoring tasks, and we've hit a recurring efficiency blocker. The tool frequently analyzes the context we provide and suggests patterns or library usage that are deprecated, having been explicitly replaced in our newer codebase.
For example, when working on our AWS Lambda functions, Cline will suggest using the older `requests` library for HTTP calls, even though our team standard moved to `httpx` over a year ago. More critically, it suggests AWS SDK (boto3) patterns we've deprecated, like using `client.describe_instances()` for simple checks, when we now enforce the use of specific, tagged naming conventions and a centralized service class.
We provide clear file context and often reference our architecture decision records. The suggestions are technically correct in a vacuum, but they ignore our documented evolution. This creates more work, as we must then manually correct the suggestion instead of accepting a valid, modernized output.
* Is there a method to "train" Cline on our current patterns beyond the immediate context window?
* Should we be structuring our prompts with explicit negations (e.g., "do not use boto3 client directly")?
* Has anyone implemented a successful workflow where Cline references a living style guide or a vector store of our approved code patterns?
The goal is to shift from policing outdated suggestions to receiving actionable, compliant refactoring proposals. The current overhead is negating the productivity gains.
Optimize or die.
CloudCostHawk
You've hit on a really common challenge when integrating these tools into an established workflow. The issue with patterns like suggesting `requests` over `httpx` is that Cline, and tools like it, are trained on a broad corpus of public code, which naturally lags behind internal team decisions.
Explicit negations in your prompts are a practical stopgap, but they're brittle and don't scale. The core problem is the tool lacks your team's specific architectural history.
Have you explored whether Cline can be configured with a persistent "project guidelines" document or a custom knowledge base? Some tools allow you to feed a markdown file of your ADRs and current standards, which it can reference before generating suggestions. If that feature doesn't exist yet, detailing this use case for the developers could be valuable feedback. It's less about training the model and more about giving it a persistent memory of your rules.
—HR
The "persistent memory of your rules" idea is intriguing, but it's just moving the goalposts. It assumes a vendor will prioritize building, securing, and maintaining a custom knowledge base feature over pumping out new marketing bullet points.
Even if they built it, you'd then be on the hook for keeping that "project guidelines" document perfectly updated. The moment it's stale, the tool's suggestions become confidently wrong in a new, sanctioned way. That's a maintenance trap, not a solution.
cg