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

251–260 of 635 posts

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

#251

Post by ToValueFunfetti »

ryandrake wrote: post #212
schmichael wrote: post #168

Earlier quoted context omitted.

> You're not supposed to trust the tool This is just an incredible statement. I can't think of another development tool we'd say this about. I'm not saying you're wrong, or that it's wrong to have tools we can't just, just... wow... what a sea change.

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 the only calculators that existed failed at 5% of the calculations, or if the only communication tools miscommunicated 5% of the time, we would still use both all the time. They would be far less than 95% as useful as perfect versions, but drastically better then not having the tools at all.

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

#252

Post by forgetfreeman »

ryandrake wrote: post #218
forgetfreeman wrote: post #199

Earlier quoted context omitted.

"Do you trust other developers to write good code without mistakes without getting it reviewed by others." Literally yes. Test coverage and QA to catch bugs sure but needing everything manually reviewed by someone else sounds like working in a sweatshop full of intern-level code bootcamp graduates, or if you prefer an absolute dumpster fire of incompetence.

I would accept mistakes and inconsistency from a human, especially one not very experienced or skilled. But I expect perfection and consistency from a machine. When I command my computer to do something, I expect it to do it correctly, the same way every time, to convert a particular input to an exact particular output, every time. I don't expect it to guess, or randomly insert garbage, or behave non-deterministicall…

Exactly this.

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

#253

Post by MiddleEndian »

int_19h wrote: post #237
MiddleEndian wrote: post #135

Earlier quoted context omitted.

I don't use VSCode (or Cursor in this case (which I do think was malicious in the way it blindly hallucinated a policy for a paying customer)); I use vim or notepad++ depending on my mood. I just don't have a problem with people "violating" Terms of Service or End User License Agreements and am not really convinced there's a legal argument there either.

I personally don't have a problem with that either, but as far as legalities go, EULAs are legally binding in US.

Have EULAs been tested in court?

For distribution licenses, I would assume they have. Can't put GPL software in your closed source code, can't just download Photoshop and copy it and give it out, etc. And that makes sense and you have some reasonable path to damage/penalties (GPL → your software is now open source, Photoshop → fines or whatever)

But if you download some free piece of software and use it with some other piece of free piece software even though they say "please don't" in the EULA, what could the criminal or civil penalties possibly be?

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

#254

Post by itissid »

daemonologist wrote: post #86
rustc wrote: post #12

Earlier quoted context omitted.

> Tinfoil hat me says that it was a policy change that they are blaming on an "AI Support Agent" and hoping nobody pokes too much behind the curtain. Yeah, who puts an AI in charge of support emails with no human checks and no mention that it's an AI generated reply in the response email?

AI companies high on their own supply, that's who. Ultralytics is (in)famous for it.

Why is Ultralytics yolo famous for it?

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

#255

Post by [deleted] »

furyofantares wrote: post #174
rustc wrote: post #12

Earlier quoted context omitted.

> Tinfoil hat me says that it was a policy change that they are blaming on an "AI Support Agent" and hoping nobody pokes too much behind the curtain. Yeah, who puts an AI in charge of support emails with no human checks and no mention that it's an AI generated reply in the response email?

It does say it's AI generated. This is the signature line: Sam Cursor AI Support Assistant cursor.com • hi@cursor.com • forum.cursor.com

[deleted]

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

#258

Post by DidYaWipe »

sodapopcan wrote: post #234
sitkack wrote: post #89

Earlier quoted context omitted.

These bros are getting high on their own supply. I vibe, I code, but I don't do VibeOps. We aren't ready. VibeSupport bots, how well did that work out for Canada Air? https://thehill.com/business/4476307-air-canada-must-pay-ref...

"Vibe coding" is the cringiest term I've heard in tech in... maybe ever? I'm can't believe it's something that's caught on. I'm old, I guess, but jeez.

It's douchey as hell, and representative of the ever-diminishing literacy of our population.

More evidence: all of the ignorant uses of "hallucinate" here, when what's happening is FABRICATION.

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

#259

Post by dgs_sgd »

ericwood wrote: post #209
cachvico wrote: post #166

Earlier quoted context omitted.

I use it all the time, and it has accelerated my output massively. Now, I don't trust the output - I review everything, and it often goes wrong. You have to know how to use it. But I would never go back. Often it comes up with more elegant solutions than I would have. And when you're working with a new platform, or some unfamiliar library that it already knows, it's an absolute godsend. I'm also damn proud of my own…

I have a hard time being sold on “yea it’s wrong a lot, also you have to spend more time than you already do on code review.” Getting to sit down and write the code is the most enjoyable part of the job, why would I deprive myself of that? By the time the problem has been defined well enough to explain it to an LLM sitting down and writing the code is typically very simple.

For me it's typically wrong not in a fundamental way but a trivial way like bad import paths or function calls, like if I forgot to give it relevant context.

And yet the time it takes me to use the LLM and correct its output is usually faster than not using it at all.

Over time I've developed a good sense for what tasks it succeeds at (or is only trivially wrong) and what tasks it's just not up for.

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

#260

Post by forgetfreeman »

theonething wrote: post #224
forgetfreeman wrote: post #199

Earlier quoted context omitted.

"Do you trust other developers to write good code without mistakes without getting it reviewed by others." Literally yes. Test coverage and QA to catch bugs sure but needing everything manually reviewed by someone else sounds like working in a sweatshop full of intern-level code bootcamp graduates, or if you prefer an absolute dumpster fire of incompetence.

Ok, here I thought requiring PR review and approval before merging was standard industry best practice. I guess all the places I've worked have been doing it wrong?

There's a lot of shit that has become "best practice" over the last 15 years, and a lot more that was "best practice" but fell out of favor because reasons. All of it exists on a continuum of what is actually reasonable given the circumstances. Reviewing pull requests is one of those things that is reasonable af in theory, produces mediocre results in practice, and is frequently nothing more than bureaucratic overhead. Consider a case where an individual adds a new feature to an existing codebase. Given they are almost certainly the only one who has spent significant time researching the particulars of the feature set in question, and are the only individual with any experience at all with the new code, having another developer review it means you've got inexperienced, low-info eyes examining something they do not fully understand, and will have to take some amount of time to come up to speed on. Sure they'll catch obvious errors, but so would a decent test suite.

Am I arguing in favor of egalitarian commit food fights with no adults in the room? Absolutely not. But demanding literally every change go through a formal review process before getting committed, like any other coding dogma, has a tendency to generate at least as much bullshit as it catches, just a different flavor.

Post reply on HN