He should've tested 4.5. This model is hallucinating much less than any other model.
[deleted]
Making o1, o3, and Sonnet 3.7 hallucinate for everyone
71–80 of 233 posts
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#72I'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.
> I really don't get how so many people can get LLMs to code most of their tasks without those issues permanently popping up They can't, they usually just don't understand the code enough to notice the issues immediately. The perceived quality of LLM answers is inversely proportional to the user's understanding of the topic they're asking about.
Alternatively, we understand it well, and discard bad completions immediately.
When I'm using llama.vim, like 40% of what it writes in a 4-5 line completion is exactly what I'd write. 20-30% is stuff that I wouldn't judge coming from someone else, so I usually accept it. And 30-40% is garbage... but I just write a comment or a couple of lines, instead, and then reroll the dice.
It's like working through a junior engineer, except the junior engineer types a new solution instantly. I can get down to alternating between mashing tab and writing tricky lines.
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#73Earlier quoted context omitted.
A language like Golang tries really hard to only have _one_ way to do something, one right way, one way. Just one way. See how it was before generics. You just have a for loop. Can't really mess up a for loop. I predict that the variance in success in using LLM for coding (even agentic coding with multi-step rather than a simple line autosuggest or block autosuggest that many are familar with via CoPilot) has much mo…
> A language like Golang tries really hard to only have _one_ way to do something Really? Logging in Go: A Comparison of the Top 9 Libraries https://betterstack.com/community/guides/logging/best-golang...
Since Go added slog many of these have been removed in favor of that. Obviously not universal, but compared to npm there really are massive numbers of devs just using the standard library.
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#74I'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.
> I really don't get how so many people can get LLMs to code most of their tasks without those issues permanently popping up They can't, they usually just don't understand the code enough to notice the issues immediately. The perceived quality of LLM answers is inversely proportional to the user's understanding of the topic they're asking about.
That's more or less my suspicion.
A few months ago I tried to do a small project with Langchain. I'm a professional software developer, but it was my first Python project. So I tried to use a lot of AI generated code.
I was really surprised that AI couldn't do much more than in the examples. Whenever I had some things to solve that were not supported with the Langchain abstractions it just started to hallucinate Langchain methods that didn't exist, instead of suggesting some code to actually solve it. I had to figure it out by myself, the glue code I had to hack together wasn't pretty, but it worked. And I learned not to use Langchain ever again :)
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#75It’s not really hallucinating though, is it? It’s repeating a pattern in its training data, which is wrong but is presented in that training data (and by the author of this piece, but unintentionally) as being the solution to the problem. So this has more in common with an attack than a hallucination on the LLM’s part.
So anyone can make up some random syntax/fact and post it once, and in some cases the model will take it as truth. I don't know if there's a widely agreed-on definition of "hallucination", but if this isn't one, then the distinction is meaningless imo.
Yes. And anyone can easily embed a backdoor just by publishing it on a own website that is in the training data.
Prompt injection (hidden or not) is another insane vulnerability vector that can't easily be fixed.
You should treat any output of an LLM the same way as untrusted user input. It should be thoroughly validated and checked if used in even remotely security critical applications.
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#76Earlier quoted context omitted.
I use LLMs for writing generic, repetitive code, like scaffolding. It's OK with boring, generic stuff. Sure it makes mistakes occasionally but usually it's a no-brainer to fix them.
> I use LLMs for writing generic, repetitive code, like scaffolding. It's OK with boring, generic stuff. In other words, they're OK in use-cases that programmers need to eliminate , because it means there's high demand for a reusable library, some new syntax sugar, or an improved API.
Boilerplate and plumbing code isn't inherently bad, nor do you improve the codebase by factoring it down to zero with libraries and abstractions.
As I've matured as a developer, I've appreciated certain types of boilerplate more and more because it's code that shows up in your git diffs. You don't need to chase down the code in some version of some library to see how something works.
Of course, not all boilerplate is created equally.
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#77I'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.
I've used it for some smaller greenfield code with success. Like, write an Arduino program that performs a number of super-sampled analog readings, and performs a linear regression fit, printing the result to the serial port.
That sort of stuff can be very helpful to newbies in the DIY electronics world for example.
But for anything involving my $dayjob it's been fairly useless beyond writing unit test outlines.
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#78Earlier quoted context omitted.
> I really don't get how so many people can get LLMs to code most of their tasks without those issues permanently popping up They can't, they usually just don't understand the code enough to notice the issues immediately. The perceived quality of LLM answers is inversely proportional to the user's understanding of the topic they're asking about.
Alternatively, we understand it well, and discard bad completions immediately. When I'm using llama.vim, like 40% of what it writes in a 4-5 line completion is exactly what I'd write. 20-30% is stuff that I wouldn't judge coming from someone else, so I usually accept it. And 30-40% is garbage... but I just write a comment or a couple of lines, instead, and then reroll the dice. It's like working through a junior engi…
I don't see the point in AI code completions, they are just distracting noise. I'm only doing bigger changes with AI.
Prompt based stuff, like "extract the filtering part from all API endpoints in folder abc/xyz. Find a suitable abstraction and put this function into filter-utils.codefile"
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#79Earlier quoted context omitted.
Doesn't prevent it from hallucinating, only reduces hallucinations by a single digit percentage
Personally I’ve been finding that the more context I provide the more it hallucinates.
There's probably a sweet spot. Same with people. Too much context (especially unnecessary context) can be confusing/distracting, as well as being too vague (as it leaves room for multiple interpretations). But generally, I find the more refined and explicit you are, the better.
Re: Making o1, o3, and Sonnet 3.7 hallucinate for everyone
#80Earlier quoted context omitted.
> I use LLMs for writing generic, repetitive code, like scaffolding. It's OK with boring, generic stuff. In other words, they're OK in use-cases that programmers need to eliminate , because it means there's high demand for a reusable library, some new syntax sugar, or an improved API.
Boilerplate and plumbing code isn't inherently bad, nor do you improve the codebase by factoring it down to zero with libraries and abstractions. As I've matured as a developer, I've appreciated certain types of boilerplate more and more because it's code that shows up in your git diffs. You don't need to chase down the code in some version of some library to see how something works. Of course, not all boilerplate is…
Boilerplate is better than bad abstractions. But good abstractions are far superior.