Comment by zoogeny
9 months ago
I think they might have made a change to Cursor recently as well. A few times I've caught it using an old API of popular libraries that have updates. Shout out to all the library developers that are logging deprecations and known incorrect usages, that has been a huge win with LLMs. In most cases I can paste the deprecation warning back into the agent and it will say "Oh, looks like that API changed in vX.Y.Z, we should be doing <other thing>, let me fix that ..."
So it is capable of integrating new API usage, it just isn't a part of the default "memory" of the LLM. Given how quickly JS libraries tend to change (even on the API side) that isn't ideal. And given that the typical JS server project has dozens of libs, including the most recent documentation for each is not really feasible. So for now, I am just looking out for runtime deprecation errors.
But I give the LLM some slack here, because even if I was programming myself using an library I've used in the past, I'm likely to make the same mistake.
You can just use @Docs [0] to import the correct documentation for your libraries.
[0] https://docs.cursor.com/context/@-symbols/@-docs
Sure, however I made the point "how quickly JS libraries tend to change" and "the typical JS server project has dozens of libs". That can add up to a lot of context.
I suppose a point could be made that I could keep the docs up-to-date using Cursor's custom docs feature and hope that whatever magic they are doing to manage context doesn't blow out the daily token budget. And I haven't tried that since the flow I mentioned about tends to work (as long as the libraries in question provide good diagnostic logs).
A good augmentation to my workflow might be periodically prompting "In file X I am using lib Y at version vN.M.P, check the docs for that version and report any errors or misuses ...".