Hallucinations like this could be a great way to identify missing features or confusing parts of your framework. If the llm invents it, maybe it ought to be like this?
Making o1, o3, and Sonnet 3.7 hallucinate for everyone
151–160 of 233 posts
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#152A while back a friend of mine told me he's very found of llms because he's confused with kubernetes cli and instead of looking up the answer on the internet he can simply state his desire in a chat to get the right answer.
Well... Sure, but if you'd look the answer on stackoverflow you'd see the whole thread including comments and you'd had the opportunity to understand what the command actually does.
It's quite easy to create a catastrophic event in kubernetes if you don't know what you're doing.
If you blindly trust llms in such scenarios sooner or later you'll find yourself in a lot of trouble.
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#153The interesting thing here to me is that the llm isn’t ‘hallucinating’, it’s simply regurgitating some data it digested during training.
What's the difference?
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#154Earlier quoted context omitted.
In my case the maximum was ~3k LOC.
That's not just small, it's utterly miniscule. It's most certainly not large.
You can fit a hell of a lot of functionality in 3k statements. Really whether it's considered large or small necessarily must rely on the functionality it's intended to provide.
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#155Earlier quoted context omitted.
Boilerplate is better than bad abstractions. But good abstractions are far superior.
I agree with you but as I've matured as a programmer, I feel like it's very hard to get abstractions for boilerplate right. Every library I've seen attempt to do it has struggled.
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#156Earlier quoted context omitted.
This is what got me in most sleepless nights, crunch and ass clenching production issues over my career. Simple repetitive shit is easy to reason about, debug and onboard people on. Naturally it's balancing act, and modern/popular frameworks are where most people landed, there's been a lot of iteration in this space for decades now.
I've made the opposite observation. Without proper abstractions code bases grow like crazy. At some point they are just a huge amount of copy, paste, and slight modification. The amount of code often grows exponentially. With more lines of code comes more effort to maintain it. After a few years those copy and pasted code pieces completely drift apart and create a lot of similar but different issues, that need to be…
I mean is that bad? Unless you keep having to have huge MRs that modify every copy/paste could you just let the code sit there and run forever?
I only say this because I've been a maintenance programmer and I could only dream of a codebase like this. The idea that I get a Rollbar with a stack trace and the entirety of what the code actually does is laid bare right at the site of the error in a single file is amazing. And I can change it without affecting anything else?! I end up having to "unwind" all of the abstractions anyway because the nature of the job means I'm not intimately familiar with the codebase and don't just know where the real work happens.
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#157I've got a lot of hallucinations like that from LLMs. I really don't get how so many people can get LLMs to code most of their tasks without those issues permanently popping up.
What TFA was talking about didn't really seem like an hallucination - just a case of garbage in-garbage out. Normally there are more examples of good/correct data in the training set than bad, so statistically the good wins, but if it's prompted for something obscure maybe bad is all that it has got. Common coding tasks are going to be better represented in the training set and give better results.
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#158Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#159Hallucinations like this could be a great way to identify missing features or confusing parts of your framework. If the llm invents it, maybe it ought to be like this?
I agree completely… Usually when I catch it doing this kind of hallucination, it's inventing an API or syntax that is far more clear and intuitive than the actual syntax.
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#160Hallucinations like this could be a great way to identify missing features or confusing parts of your framework. If the llm invents it, maybe it ought to be like this?
Only if you wanna optimize exclusively for LLM users in this generation.
It'll be like a slack support channel, for robots.