Cursor sucks. Not as a product. As a team. Their customer support is terrible. I was offered in writing a refund by the team who cold reached out to me to ask me why I cancelled my sub one week after start. Then they ignored my 3+ emails in response asking them to refund, and other means of trying to communicate with them. Offering me a refund as a bait to gain me back, then when I accept it they ghost me. Wow. Very…
Cursor IDE support hallucinates lockout policy, causes user cancellations
401–410 of 635 posts
Re: Cursor IDE support hallucinates lockout policy, causes user cancellations
#402Cursor sucks. Not as a product. As a team. Their customer support is terrible. I was offered in writing a refund by the team who cold reached out to me to ask me why I cancelled my sub one week after start. Then they ignored my 3+ emails in response asking them to refund, and other means of trying to communicate with them. Offering me a refund as a bait to gain me back, then when I accept it they ghost me. Wow. Very…
You just don't know how to prompt it correctly.
Re: Cursor IDE support hallucinates lockout policy, causes user cancellations
#403Earlier quoted context omitted.
Did anyone say that? They are an issue everywhere, including for code. But with code at least I can have tooling to automatically check and feed back that it hallucinated libraries, functions etc, but with just normal research / problems there is no such thing and you will spend a lot of time verifying everything.
I use Scala which has arguably the best compiler/type system with Cursor. There is no world in which a compiler or tooling will save you from the absolute mayhem it can do. I’ve had it routinely try to re-implement third party libraries, modify code unrelated to what it was asked, quietly override functions etc. It’s like a developer who is on LSD.
Re: Cursor IDE support hallucinates lockout policy, causes user cancellations
#404Earlier quoted context omitted.
> * Any AI responses used for email support are now clearly labeled as such. We use AI-assisted responses as the first filter for email support. Don't use AI. Actually care. Like, take a step back, and realise you should give a shit about support for a paid product. Don't get me wrong: AI is a very effective tool, *for doing things you don't care about*. I had to do a random docker compose change the the other day. I…
Not trying to defend them, but I think it’s a problem of scaling up. The user base grew very quickly and keeping up with the support inquiries must be a tough job. Therefore the first like of defense is AI support replies. I agree with you, they should care.
Re: Cursor IDE support hallucinates lockout policy, causes user cancellations
#405(Cursor cofounder) Apologies - something very clearly went wrong here. We’ve already begun investigating, and some very early results: * Any AI responses used for email support are now clearly labeled as such. We use AI-assisted responses as the first filter for email support. * We’ve made sure this user is completely refunded - least we can do for the trouble. For context, this user’s complaint was the result of a r…
Re: Cursor IDE support hallucinates lockout policy, causes user cancellations
#406Earlier quoted context omitted.
How do you define code quality in this case and what is your stack?
Code that you can understand and fix later, is acceptable quality per my definition. Either way, LLMs are actually high up the quality spectrum as they generate a very consistent style of code for everyone. Which gives it uniformity, that is good when other developers have to read and troubleshoot code.
This definition limits the number of problems you can solve this way. It basically means buildup of the technical debt - good enough for throwaway code, unacceptable for long term strategy (growth killer for scale-ups).
>Either way, LLMs are actually high up the quality spectrum
This is not what I saw, it’s certainly not great. But that may depend on stack.
Re: Cursor IDE support hallucinates lockout policy, causes user cancellations
#407Earlier quoted context omitted.
I worry that they don't understand the limitations of their own product.
The market will teach them. Problem solved.
Re: Cursor IDE support hallucinates lockout policy, causes user cancellations
#408Cursor sucks. Not as a product. As a team. Their customer support is terrible. I was offered in writing a refund by the team who cold reached out to me to ask me why I cancelled my sub one week after start. Then they ignored my 3+ emails in response asking them to refund, and other means of trying to communicate with them. Offering me a refund as a bait to gain me back, then when I accept it they ghost me. Wow. Very…
[flagged]
Re: Cursor IDE support hallucinates lockout policy, causes user cancellations
#409There is a certain amount of irony that people try really hard to say that hallucinations are not a big problem anymore and then a company that would benefit from that narrative gets directly hurt by it. Which of course they are going to try to brush it all away. Better than admitting that this problem very much still exists and isn’t going away anytime soon.
Did anyone say that? They are an issue everywhere, including for code. But with code at least I can have tooling to automatically check and feed back that it hallucinated libraries, functions etc, but with just normal research / problems there is no such thing and you will spend a lot of time verifying everything.
Re: Cursor IDE support hallucinates lockout policy, causes user cancellations
#410Earlier quoted context omitted.
I think that’s why Apple is very slow at rolling out AI if it ever actually will. Downside is way too big than the upside.
You say slowly, but in my opinion Apple made an out of character misstep by releasing a terrible UX to everyone. Apple intelligence is a running joke now. Yes they didn't push it as hard as, say, copilot. I still think they got in way too deep way too fast.
The models and devices just aren't quite there yet.
Once Google gets its shit together and starts deploying (cloud--based) AI features to Android devices en masse, Apple is going to have a really big problem on their hands.
Most users say that they want privacy, but if privacy comes in the way of features or UX, they choose the latter. Successful privacy-respecting companies (Apple, Signal) usually understand this, it's why they're successful, but I think Apple definitely chose the wrong tradeoff here.