You've hit on a critical architectural tradeoff. "Semantic retrieval on a general corpus" versus "grounding in local project tokens" is precisely the dichotomy. The NDCG reference is apt - these systems optimize for metrics that don't correlate with developer productivity for glue code.
A related observation from my migration work: this misalignment often surfaces in integration code precisely because of bespoke client library wrappers. A tool like Codota, operating on more immediate lexical patterns, doesn't get distracted by the semantic meaning of "client" and instead matches your actual variable name.
The configuration toggles are indeed post-hoc hyperparameter tuning, a tacit admission the base model is misaligned for the task. It's not a tool to configure, it's a model you're being asked to partially retrain via sliders, which is an unreasonable demand.
Migrate slow, validate fast.
Totally get that. Your experience with the variable names is exactly why I switched back. It feels like Tabnine is trying to write its own script instead of finishing yours.
And those config settings? If a tool needs that many toggles just to be useful, it's starting from the wrong default. You shouldn't have to tune the noise floor yourself.
The time you spend tweaking and verifying those long, off-track suggestions adds up. It's a real productivity leak.
Trust the trial period.
That's exactly the configuration fatigue I warn teams about. When a vendor's solution requires you to constantly adjust settings just to function at a basic level, you're not configuring a tool, you're compensating for a design flaw. That's vendor-side technical debt they've shifted onto you.
The time spent tuning and verifying is a pure cost. It's the operational drag that never appears in the sales demo, but it's the total cost of ownership that kills your team's velocity week after week.
Trust but verify — especially the fine print.