I am encountering a persistent and costly issue in my team's workflow: our AI coding assistants (primarily GitHub Copilot and Cursor) frequently suggest functions, methods, and libraries that have been deprecated or removed from our internal framework and target cloud stack. This is not a minor nuisance; it's introducing security vulnerabilities, runtime errors, and significant refactoring overhead during code review.
Our stack is a PostgreSQL-backed service layer (Node.js/Typescript) running on Kubernetes, with a hard requirement to use the latest stable versions of `pg` and `node-postgres` libraries. The AI consistently suggests patterns from `pg` version 7.x, such as the old callback-style `pool.query()` or the deprecated `Client` constructor, when we have standardized on version 8.x+ and its async/await patterns with parameterized queries. Similarly, for our cloud SDKs (AWS SDK v3), it will generate code using the long-deprecated v2 `aws-sdk` package.
I have attempted to mitigate this with:
* Explicit comments in the prompt (`// using pg v8.11, use async/await`)
* Providing a top-of-file context block with our versioned imports
* Using Cursor's project-level `.cursor/rules` to define technology constraints
The results are inconsistent at best. The assistant will often "acknowledge" the rule in a comment, then immediately generate the deprecated code pattern.
My hypothesis is that the underlying models are trained on a broad corpus of public code, which includes a significant volume of outdated tutorials and legacy repositories, and they lack a reliable mechanism to prioritize context from my immediate project (like `package.json`) over that training data.
I am seeking a concrete, repeatable setup—a "recipe"—that has proven effective for others. Specifically:
1. What is the most reliable method to "anchor" the assistant to your exact library versions and approved patterns? Is it a custom instruction, a project rule file, or a systematic context injection strategy?
2. For teams, how are you validating that these mitigations work? Are you using unit tests that fail on deprecated API usage, or a linting rule (like `eslint-plugin-node` with `no-deprecated-api`), and feeding those results back into the assistant's context?
3. Has anyone built a cost-benefit model for the time spent crafting these rules versus the time saved by the assistant? I'm concerned about rule sprawl.
I am less interested in "try being more specific in your prompt" and more interested in engineered solutions: pre-commit hooks, custom linters that run against AI suggestions, or structured context management pipelines.
-ek
Show me the numbers, not the roadmap.
Yeah, this is a huge problem with the context limits. Even with the project-level rules, it seems like the training data for these assistants is a few years behind on specific libs. Have you tried just turning it off for certain file types? That's what my team did for our Terraform modules because it kept suggesting old AWS provider syntax.
Still learning