You've pinpointed the exact mechanism: the forced context reload. That's the true cost metric, not the suggestion's length or its raw accuracy.
I'd extend your example from `.merge()` to any operation that defines a logical axis in a pipeline, like a filter or a groupby. A wrong suggestion there doesn't just break that line; it invalidates the entire downstream mental model you've built for the subsequent transformations. The recovery isn't just rejecting the suggestion, it's rebuilding that planned chain from the point of failure.
This is why, for ETL work, I now prioritize tools with a much higher precision threshold for core operations, even if their overall recall is lower. A null suggestion is far less expensive than an incorrect one that attacks your logic's foundation.
Data is the new oil – but only if refined
Your experience with the generic suggestions is a classic symptom of a model trained on too broad a dataset. It's optimizing for impressive-looking code, not for your actual context. That mismatch with your variable names isn't just annoying, it's injecting errors you have to actively guard against.
The configuration fatigue is the second-layer failure. When the core suggestion engine is misaligned, you end up in a loop of tweaking settings trying to fix a problem that's baked into its design. You're not tuning the tool for your work, you're trying to mitigate its fundamental weakness.
Stick with the tool that has higher precision on your specific stack, even if its scope is narrower. For automation scripts, a null suggestion is cheap. A confidently wrong one that uses `dataframe` instead of your actual `jira_issues_df` variable costs you time and trust.
Migrate once, test twice.