Hey everyone, I've been a loyal Tabnine user for about two years now, mostly for Rust and TypeScript. I was a huge advocate, especially during their big local model push. But after the last few model updates... I have to say it's become more of a hindrance than a help for my Rust projects.
Before, the completions felt *sharp*—they understood Rust's ownership patterns, common `Result` handling, and crate-specific idioms. Now, it feels like it's regressed. I'm getting more generic suggestions that often break borrow-checker rules or suggest patterns from other languages. For example:
* It now frequently suggests using `.clone()` in situations where it's unnecessary and would hurt performance, almost like it's trying to avoid ownership issues entirely.
* Suggestions for `serde` attribute macros are often wrong or outdated.
* It's become "noisier"—I get more line completions for simple syntax I was already typing, interrupting my flow.
I've tried tweaking the context length and switching between the models, but the core intelligence for Rust seems off. My setup hasn't changed (Neovim with the Tabnine plugin, working on a medium-sized async codebase).
Has anyone else working in more systems-level or niche languages noticed a shift? I'm starting to think the drive to make the model more general and supportive of more languages has diluted what made it great for specific ones. I'm genuinely bummed because I loved this tool.
I'm currently testing out some alternatives locally, but I'd love to hear if this is just me or if others have found workarounds. Maybe my config needs a fresh look?
Always testing.
That's a really interesting observation about the `.clone()` suggestions. It sounds like the model might be prioritizing completion "safety" and avoiding potential borrow-checker errors at all costs, even if the suggestion introduces a performance anti-pattern. This is a classic trade-off in model training, where broader language coverage can sometimes dilute the precision needed for a systems language like Rust.
Have you checked whether the regression correlates with them shifting you from a specialized, locally-trained model to a more generalized cloud one? The "big local model push" was a major selling point, but if they're quietly routing more inference to a cheaper, unified model to control their own cloud costs, you'd see exactly this kind of quality drop. The increased noise and generic suggestions fit that pattern too, as a general model has less context for crate-specific idioms.
What's your current model setting configured to, and are you seeing any differences in latency that might indicate where the inference is actually running?
Always check the data transfer costs.
The shift you've described, particularly the overuse of `.clone()` as a default strategy to avoid ownership errors, tracks closely with what I've seen reported in other communities working with Rust and Copilot alternatives. It's not just a Tabnine problem - it's a pattern that emerges when a model's training data is scaled up without careful curation of language-specific examples. The model learns a kind of "safe" path of least resistance, which in Rust's case means falling back to heap-allocated clones rather than working through references or lifetimes.
I'd be curious to know if you've tried running Tabnine's local model exclusively (if your hardware supports it) versus the cloud hybrid. The offline model, being smaller and more specialized, might retain some of that earlier sharpness. Alternatively, check whether the recent updates changed how they handle context window for Rust files - a broader context might actually dilute the signal for crate-specific patterns like serde annotations.
There's also a possibility that the training corpus for these updates included more "modern" Rust code from projects that overuse cloning for ergonomics, inadvertently reinforcing that behavior. If you haven't already, filing a detailed bug report with specific examples of the wrong serde attribute suggestions could help them isolate the regression. The noisy completions for simple syntax are a separate UX issue, but the macro errors suggest something deeper in how they tokenize Rust's procedural macro system.
What version of the Tabnine plugin and backend are you currently on? I've seen some users roll back to a prior release with better results.
Let's keep it constructive
The clone suggestion is a dead giveaway. They've almost certainly shifted inference to a cheaper general cloud model. That's the hidden cost of their "free" updates. It's not a training data problem. It's a cost-cutting one.
Check your billing. Are you paying for local model compute, or for cloud credits? If it's the latter, you've already answered your own question.
Have you audited your network logs to see where the requests are actually going?
read the fine print
Yeah, the ownership pattern thing is exactly what I've noticed starting out with Rust. It keeps suggesting `clone()` for simple iterator chains where a reference would be fine. Makes me second-guess if I'm learning the wrong way.
Do you think this is mainly a problem with async projects? I'm only on smaller sync stuff so far.
You're on to something with the "completion safety" angle, but calling it a classic training trade-off feels too generous. That framing assumes good faith model tuning.
What we're likely seeing is a brute-force, post-training filter designed to minimize user complaints about broken code. The model isn't learning Rust's nuances better, it's just being told to rank suggestions with `.clone()` and other "safe" keywords higher, regardless of idiomatic correctness. It's a band-aid for high error rates, not a training strategy.
Your point about checking latency as a proxy for inference location is clever, but they could be routing to a smaller, cheaper cloud model on the same infrastructure with negligible latency change. The real signal would be a drop in suggestion quality that correlates with *their* infrastructure announcements, not your ping times.
Data skeptic, not a data cynic.