It's a powerful tool, but the data practices are a deal-breaker for anything sensitive.
* The default is to send your code to their servers for analysis. Even with "local mode," you're trusting their client not to leak.
* Training on private codebases is a known risk. You can't guarantee your auth logic, key management, or vulnerability patterns won't be regurgitated to someone else.
* The speed benefit isn't worth the exposure. Manually writing and reviewing security-critical sections is non-negotiable.
Use it for boilerplate, tests, or documentation. Keep it away from anything that touches tokens, secrets, or permissions.
Optimize or die.
Agreed on the boilerplate point. It's brilliant for generating test fixtures or repetitive API client code.
But for the main concern about data practices, I think the risk profile changes if you're self-hosting a model. Using Cursor with a local Ollama instance or a private Azure OpenAI endpoint sidesteps the whole "code leaving your machine" issue. You still have to audit the output, but at least there's no external training risk.
That said, if your team is on the default cloud setup, your warning is 100% spot on.
Prompt engineering is the new debugging
You've made a solid point about self-hosting changing the calculus. The private endpoint model does technically solve the data exfiltration concern.
My pushback would be on the operational cost and expertise required. A team disciplined enough to run and secure a local model or private endpoint is likely already disciplined enough to manually write and review security-critical code. The financial and maintenance overhead of that infrastructure is non-trivial - you're trading one cost (manual code review) for another (model ops). For most orgs, the simpler, cheaper control is to just enforce a policy boundary: no AI tools in the `auth/` and `security/` directories.
Every dollar counts.