Cursor is an excellent product, but it seems to be at a plodding development progress at the moment. While no offense is intended, the product is beginning to exhibit signs of being managed by a young team with limited experience in growth and operational management. While the platform itself shows potential, your communication with your users and the documentation requires significant improvement.
Example “Composer” is a significant components of Cursor, but it is not mentioned or explained in the documentation. For example I just tried using the “search or ask” for Composer on the Cursor - Build Software Faster - the result was:
“You have reached your chat limit. Please try again later.” it’s hard to take “Cursor” seriously if you don’t even update basic documentation and your search reaches the chat limit
A few examples of the documentation:
- Lack of Clarity on Reindexing and Dataset Management:
The documentation does not explain the technical foundation of reindexing. Is it powered by Retrieval-Augmented Generation (RAG) or another methodology? Understanding this would help users optimize their workflows, especially when working with large codebases. Additionally, providing concrete examples of when to use dataset indexing versus .cursorignore files would be invaluable.
- Best Practices for Context Optimization:
One of Cursor’s advertised strengths is providing “contextual awareness” for better coding assistance. However, there is little to no guidance on how users can structure their projects or configure Cursor to maximize this capability. Including real-world examples, data points, or even anecdotal use cases could make this section significantly more actionable.
- Comprehensive Feature Explanations:
While brevity is important, the current documentation leans too heavily on surface-level descriptions. For a platform that recently raised $60M in funding, and having users like my self that are paying 40USD/m it should be a reasonable to request that you put in the hours to provide detailed, and insightful technical resources that not only describe what a feature does but also why and how to use it effectively.
Some sections of the documentation read as though they were generated by a language model with limited knowledge of Cursor’s architecture and goals. This diminishes the credibility of the content when you encourage us to use Google or Stack overflow for the .gitignore typed .cursorignore
files.
I think you could reduce the amount of clutter on the forum if you started to provide use case scenarios for optimal onboarding experience and clear technical insights to help your users.
Providing simple things like a roadmap would ease many users. BTW, framing your collaboration with Supermaven is not a roadmap.
Beyond technical issues, there is a more significant concern: communication. Cursor currently appears to be out of touch with its user base, which could have long-term consequences. For example, acknowledging user frustrations and outlining your roadmap for improvements would go a long way. Statements like:
“We understand Composer is a frustrating experience 50% of the time. We are sorry for the many instances where your carefully crafted code was deleted or altered without clear reason :joy:. We’re actively working to change this behavior to better serve you.”
… would demonstrate that you value your users’ feedback and are committed to improvement. This kind of transparency builds loyalty. Users will tolerate growing pains if they feel heard and understand the steps being taken to address their concerns.
In the rapidly evolving landscape of AI coding assistants, it’s impossible to stay permanently ahead of the curve. There are too many players vying for attention. However, solid communication can cultivate loyal users who will stay with Cursor even when the next shiny tool emerges. Without it, the platform risks becoming another temporary stop for lemmings and “content creators” that jump to the next trend once their favorite YouTuber makes a shocked-face thumbnail about a competing product.