I’m working on a complex system, that includes back-end api, admin dashboard, several microservices and React Native app for mobile platforms. Cursor did amazing job in the beginning, but as the system gets more complex and intertwined, prompting Cursor becomes tedious by day. I almost reached a state, when it’s easier for me to go on and write whole thing myself, rather then build a definitive prompt with all the context and then go through the whole followup, when model does something strange and I need to iterate, until it does something viable. And as the time goes by, results provided by models get worse and worse. Almost never now I accept the changes as they are. Often rewriting the whole thing to fit the task.
I count on models getting better eventually. But what Cursor can already do to mitigate many aspects of the problem is provide a memory for the project. Cursor should remember all the things we did together on the project, how and why. Notepads are good first step, but they are very limited and manual, they also do not support referencing files (for whatever reason, which is a problem by itself). I strongly believe Cursor should maintain internal understanding of the system itself. And to be honest, Cursors understanding of the system should be better (!) than my own. It should help me find my way, not the other way around.
This is also a topic of interest for me. At the moment i mitigate this by trying to keep my prompts more specific for something i want to do and provide only the necessary files. A couple times i prompted on the entire codebase and was actually impressed by the experience, but i haven’t been using Cursor that long and im not sure how large your project is.
The problem lies in the fact that, seemingly, all Cursor does is looks through files. It’s not any “smarter” than using Canvas for ChatGPT and actually I find I use Canvas 100% of the time anyway. I ONLY USE Cursor for one click bug fixing and the improved intellisense.
There really isn’t anything special about Cursor atm and it’s def. not worth the $20 monthly cost. This is especially true when you factor in the memory leak issues or whatever the heck is going on where running cursor for very long brings your machine to a complete screeching halt (unless you’re on a macbook… it’s less noticable there).
It’s definitely hard to build big projects this way. It’s great for quick hacks, but the more complex the system, the more it (or any current LLM-based system) will struggle. I have other rants about the pricing model elsewhere on here but I won’t repost those just now.
I have just written a very lengthy post specifically about how to make the most of Cursor for larger projects though. It’s about a 6 minute read. There’s also a section about TDD in a reply for good measure if you’re interested: An Idiot’s Guide To Bigger Projects
As always, your mileage may vary, but there might be some things in there that could help.
I did turn it on, but then suddenly my quota depleted in a day. I’m not sure if these two events are connected though, so I turned it off. In any case I don’t really see how using long context might ease the situation here. Yes, probably I could keep the tread with Composer quite longer. But not sure if it can fit whole Codebase. Can it? I’m going to try again.
Cursor should remember all the things we did together on the project, how and why
LLMs use a system of weights to “remember” the information they have been trained on, but they are not continuously trained and therefore do not have a way of “remembering” what you’ve talked to them about. This is very different from a human brain, for example. As a result, you are trying to use something for a job it cannot do. The longer the context you provide, the more diluted the message. If I got up on stage and provided you with 200k tokens worth of context in a presentation over the course of 30 minutes, then asked you to repeat it verbatim you’d have a tiny fraction of the information. That’s what an LLM is doing, effectively.
This is all to say that LLMs (and Cursor, by extension) are intrinsically ill equipped to maintaining a long-running history like you suggest. If you want better results out of the tool you need to understand the tool and what it does do better and adapt to leverage that. Opining about how to improve a tool to Cursor when Cursor doesn’t have any control over that tool is a waste of energy.
I wouldnt necessarily say remember everything. I would say a “smart index”, where an index is created, and has some context, maybe call it pattern recognition. My codebase has some exceptions, but there are CLEAR patterns of coding, cursor seems to only get small parts of it. I think this is groundbreaking.
The current generation of models provide the best answers when you feed them only the most relevant context. As the context window grows, and more files are added, the quality of the answers drops because there is much more noise. The ‘next best word’ approach may determine that irrelevant or unexpected parts of the context outweigh what you want it to pay attention to. For the time being, you can only really expect AI to help you with discrete tasks, not the big picture. Break you task down into small parts, and attack them separately. Create a Composer Notepad that describes your feature you are trying to make in detail, so it can be used as a common reference, and start new composers often. Its not Cursor that is unable to handle all the context of a large codebase, but GPT-4o or Sonnet or whatever your using.
I work in a very large codebase, and I find a lot of utility from Cursor, but I typically add files manually as context only when needed, and keep a single thread open for a short time. If it grows too long then the quality decreases.
Check out the post that @three wrote, its really good!
I do not suggest to remember everything (although it should and I believe that’s what we are eventually moving towards with long contexts), but as @guilhermicas said it can generate a compact summary after each session and add that to its “memory”. Also I believe it should constantly rewrite and refactor its “memory” as its understanding of the system grows.
Currently I came up with a bearable workaround, which does exactly that, but I have to do it manually. After each important session with Composer I ask it to generate comprehensible summary of what we did and why, to then feed into a new Composer session. And ask it to patch .cursorrules file with those. .cursorrules file serves the role of the “memory” that I was suggesting. It doesn’t solve all of my problems but situation improved dramatically. Now every time I initiate a Composer session it has understanding about purpose of the project, its overall structure, technologies used (and why), db schema, api controllers, ui components, how everything interconnects with each other, about my coding practices and where to find what.
A feature that would help a lot in .cursorrules file would be ability to reference files and folders!
I still think though that there should be an option in Cursor itself to do this automatically and in more effective way @shaneteks
for larger projects you should prompt using only the context of the files relevant to the change you’re looking to make using the “@” syntax instead of using the entire project as context.
Cursor is a programmers tool, LLm’s have inherent limitations people need to be aware of. Don’t blame the tools for a lack of project analysis & design that can only be done outside of the programming tools.