Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cursor IDE support hallucinates lockout policy, causes user cancellations

old.reddit.com

Post reply on HN
Print view View original

351–360 of 635 posts

Re: Cursor IDE support hallucinates lockout policy, causes user cancellations

#351

Post by geuis »

mntruell wrote: post #272

(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…

Or you could hire real people to actually answer real customer issues. Just an idea.

Re: Cursor IDE support hallucinates lockout policy, causes user cancellations

#352

Post by bigstrat2003 »

arvinsim wrote: post #347
ryandrake wrote: post #212

Earlier quoted context omitted.

Imagine if your compiler just randomly and non-deterministically compiled valid code to incorrect binaries, and the tool's developer couldn't really tell you why it happens, how often it was expected to happen, how severe the problem was expected to be, and told you to just not trust your compiler to create correct machine code. Imagine if your calculator app randomly and non-deterministically performed arithmetic in…

If you think of AI like a compiler, yes we should throw away such tools because we expect correctness and deterministic outcomes If you think of AI like a programmer, no we shouldn't throw away such tools because we accept them as imperfect and we still need to review.

> If you think of AI like a programmer, no we shouldn't throw away such tools because we accept them as imperfect and we still need to review.

This is a common argument but I don't think it holds up. A human learns. If one of my teammates or I make a mistake, when we realize it we learn not to make that mistake in the future. These AI tools don't do that. You could use a model for a year, and it'll be just as unreliable as it is today. The fact that they can't learn makes them a nonstarter compared to humans.

Re: Cursor IDE support hallucinates lockout policy, causes user cancellations

#353

Post by theonething »

seabird wrote: post #341
theonething wrote: post #306

Earlier quoted context omitted.

so your saying that yes you do "trust other developers to write good code without mistakes without getting it reviewed by others." And then you say "by the time the rest of the team reviews it. Most code review is uneventful." So you trust your team to develop without the need for code review but yet, your team does code review. So what is the purpose of these code reviews? Is it the case that you actually don't thin…

I never said that code review was useless, I said "yes, I do" to your question as to whether or not I "trust other developers to write good code without mistakes without getting it reviewed by others". Of course I can trust them to do the right thing even when nobody's looking, and review it anyway in the off-chance they overlooked something. I can't trust AI to do that. The purpose of the review is to find and fix o…

You spend your comment dancing around the fact that everyone makes mistakes and yet you claim you trust your team not to make mistakes.

> I "trust other developers to write good code without mistakes without getting it reviewed by others". Of course I can trust them to do the right thing even when nobody's looking, and review it anyway in the off-chance they overlooked something.

You're saying yes, I trust other developers to not make mistakes, but I'll check anyways in case they do. If you really trusted them not to make mistakes, you wouldn't need to check. They (eventually) will. How can I assert that? Because everyone makes mistakes.

It's absurd to expect anyone to not make mistakes. Engineers build whole processes to account for the fact that people, even very smart people make mistakes.

And it's not even just about mistakes. Often times, other developers have more context, insight or are just plain better and can offer suggestions to improve the code during review. So that's about teamwork and working together to make the code better.

I fully admit AI makes mistakes, sometimes a lot of them. So it needs code review . And on the other hand, sometimes AI can really be good at enhancing productivity especially in areas of repetitive drudgery so the developer can focus on higher level tasks that require more creativity and wisdom like architectural decisions.

> I will pick the domain expert who refuses to touch AI over a generic programmer with access to it ten times out of ten.

I would too, but I won't trust them not to make mistakes or occasional bad decisions because again, everybody does.

> You don't need to constantly train younger developers when you can retain people.

But you do need to train them initially. Or do you just trust them to write good code without mistakes too?

Re: Cursor IDE support hallucinates lockout policy, causes user cancellations

#354

Post by geuis »

eranation wrote: post #346
mntruell wrote: post #272

(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…

Side note... I'm a paying enterprise customer who moved all my team to cursor and have to say I'm considering canceling due to the non existent support. For example Cursor will create new files instead of edit an existing one when you have a workspace with multiple folders in a monorepo...

Why in all of hades would you force your entire eng org to only use one LLM provider. It's incredibly easy to run this stuff locally on 4+ year old hardware. Why is this even something you're spending company money on? Investor funds?

Re: Cursor IDE support hallucinates lockout policy, causes user cancellations

#356

Post by theturtletalks »

permo-w wrote: post #207
theturtletalks wrote: post #49

Cursor is trapped in a cat and mouse game against "hacks" where users create new accounts and get unlimited use. The repo was even trending on Github ( https://github.com/yeongpin/cursor-free-vip ). Sadly, Cursor will always be hampered by maintaining it's own VSCode fork. Others in this niche are expanding rapidly and I, myself, have started transitioning to using Roo and Cline.

literally any service with a free trial--i.e. literally any service--has this "problem". it's an integral part of the equation in setting up free trials in the first place, and by no means a "trap". you're always going to have a % of users who do this, the business model relies on the users who forget and let the subscription cross over to the next month or simply feel its worth paying

This is true but Cursor’s problems are a bit worse than a normal paywalled service.

Cursor allows users to get free credits without a credit card and this forced them to change their VSCode fork on how it handles identification so they can stop users from spawning new accounts.

Another is that normally, companies have a cost for each free user. For Cursor, this cost is so sporadic since it doesn’t charge per million context, they use credits. Free users get 50 credits but 1 credit could be 200k+ context each so it could be $40-50 per free user per month. And these users get 50 credits every month.

Lastly, the cursor vip free repo has trended on GitHub many times and users who do pay might stop and use this repo instead.

The Cursor vip free creator is well within his rights to do what they want and get “free” access. This unfortunately hurts paying customers since Cursor has to stop these “hacks.”

This is why Cursor should just move to a VSCode extension. I’ve used Augment and other VSCode extensions and the feature set is close to Cursor so it’s possible for them just to be an extension. The other would be to remove free accounts but allow users to bring their own keys. To use Composer/Agent, you can’t bring your own keys.

This will allow Cursor to stop maintaining a VSCode fork, helps them stop caring if users create new accounts (since all users are paying) and lets users bring their own keys if they don’t want to pay. Hell, if they charge a lifetime fee to bring our own keys for Agent, that would bring in revenue too. But as I see now, Roo and Cline’s agent features are catching up and Cursor won’t have a moat soon.

Re: Cursor IDE support hallucinates lockout policy, causes user cancellations

#357

Post by throwaway2037 »

saintfire wrote: post #247
cryptoegorophy wrote: post #180

Earlier 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.

    > Apple made an out of character misstep by releasing a terrible UX to everyone
What about Apple Maps? That roll-out was awful.

Re: Cursor IDE support hallucinates lockout policy, causes user cancellations

#358

Post by ericye16 »

daemonologist wrote: post #271
itissid wrote: post #254

Earlier quoted context omitted.

Why is Ultralytics yolo famous for it?

They had a bot, for a long time, that responded to every github issue in the persona of the founder and tried to solve your problem. It was bad at this, and thus a huge proportion of people who had a question about one of their yolo models received worse-than-useless advice "directly from the CEO," with no disclosure that it was actually a bot. The bot is now called "UltralyticsAssistant" and discloses that it's auto…

I was hit by this while working on a project for class and it was the most frustrating thing ever. The bot would completely hallucinate functions and docs and it confused everyone. I found one post where someone did the simple prompt injection of "ignore previous instructions and x" and it worked but I think it's delted now. Swore off ultralytics after that.

Re: Cursor IDE support hallucinates lockout policy, causes user cancellations

#359

Post by diputsmonro »

ToValueFunfetti wrote: post #340
gitremote wrote: post #269

Earlier quoted context omitted.

Absolutely not. We'd just do the calculations by hand, which is better than running the 95%-correct calculator and then doing the calculations by hand anyway to verify its output.

Suppose you work in a field where getting calculations right is critical. Your engineers make mistakes less than .01% of the time, but they do a lot of calculations and each mistake could cost $millions or lives. Double- and triple-checking help a lot, but they're costly. Here's a machine that verifies 95% of calculations, but you'd still have to do 5% of the work. Shall I throw it away? Unreliable tools have a good…

> Here's a machine that verifies 95% of calculations, but you'd still have to do 5% of the work.

The problem is that you don't know which 5% are wrong. The AI is confidently wrong all the time. So the only way to be sure is to double check everything, and at some point its easier to just do it the right way.

Sure, some things don't need to be perfect. But how much do you really want to risk? This company thought a little bit of potential misinformation was acceptable, and so it caused a completely self inflicted PR scandal, pissed off their customer base, and lost them a lot of confidence and revenue. Was that 5% error worth it?

Stories like this are going to keep coming the more we rely on AI to do things humans should be doing.

Someday you'll be affected by the fallout of some system failing because you happen to wind up in the 5% failure gap that some manager thought was acceptable (if that manager even ran a calculation and didn't just blindly trust whatever some other AI system told them) I just hope it's something as trivial as an IDE and not something in your car, your bank, or your hospital. But certainly LLMs will be irresponsibly shoved into all three within the next few years, if it's not there already.

Re: Cursor IDE support hallucinates lockout policy, causes user cancellations

#360

Post by dudinax »

cs702 wrote: post #143

Yup, hallucinations are still a big problem for LLMs. Nope, there's no reliable solution for them, as of yet. There's hope that hallucinations will be solved by someone, somehow, soon... but hope is not a strategy. There's also hype about non-stop progress in AI. Hype is more a strategy... but it can only work for so long. If no solution materializes soon, many early-adopter LLM projects/trials will be cancelled. Sig…

Every llm output is a hallucination. Sometimes it happens to match reality.
Post reply on HN