←back to thread

Hallucinations in code are the least dangerous form of LLM mistakes

(simonwillison.net)
371 points ulrischa | 5 comments | 02 Mar 25 19:15 UTC | HN request time: 0.238s | source
Show context
al2o3cr ◴[02 Mar 25 20:51 UTC] No.43234929[source]▶

    My cynical side suspects they may have been looking for
    a reason to dismiss the technology and jumped at the first
    one they found.
MY cynical side suggests the author is an LLM fanboi who prefers not to think that hallucinating easy stuff strongly implies hallucinating harder stuff, and therefore jumps at the first reason to dismiss the criticism.
replies(2): >>43235138 #>>43237917 #
williamcotton ◴[02 Mar 25 21:09 UTC] No.43235138[source]▶
What do you mean by "harder stuff"? What about an experimental DSL written in C with a recursive descent parser and a web server runtime that includes Lua, jq, a Postgres connection pool, mustache templates, request-based memory arena, database migrations and much more? 11,000+ lines of code with ~90% written by Claude in Cursor Composer.

https://github.com/williamcotton/webdsl

Frankly us "fanbois" are just a little sick and tired of being told that we must be terrible developers working on simple toys if we find any value from these tools!

replies(6): >>43235291 #>>43235372 #>>43235757 #>>43235877 #>>43239166 #>>43239764 #
1. dzaima ◴[02 Mar 25 21:24 UTC] No.43235291[source]▶
Some free code review of the first file I clicked into - https://github.com/williamcotton/webdsl/blob/92762fb724a9035... among other places should probably be doing the conditional "lexer->line++"; thing. Quite a weird decision to force all code paths to manually do that whenever a newline char is encountered. Could've at least made a "advance_maybe_newline(lexer);" or so. But I guess LLMs give you copy-paste garbage.

Even the article of this thread says:

> Just because code looks good and runs without errors doesn’t mean it’s actually doing the right thing.

replies(2): >>43235410 #>>43235622 #
2. williamcotton ◴[02 Mar 25 21:35 UTC] No.43235410[source]▶
Thanks for taking a look! The lexer and parser is probably close to 100% Claude and I definitely didn't review it completely. I spent most of the time trying out different grammars (normally something you want to do before you start writing code) and runtime features! "Build the web server runtime and framework into the language" was an idea kicking around in my head for a few years but until Cursor I didn't have the energy to play around with the idea.
3. ianbutler ◴[02 Mar 25 21:56 UTC] No.43235622[source]▶
Okay so this is a personal opinion right? Like where is the objectivity in your review?

What are the hardline performance characteristics being violated? Or functional incorrectness. Is this just "it's against my sensibilities" because at the end of the day frankly no one agrees on how to develop anything.

The thing I see a lot of developers struggle with is just because it doesn't fit your mental model doesn't make it objectively bad.

So unless it's objectively wrong or worse in a measurable characteristic I don't know that it matters.

For the record I'm not asserting it is right, I'm just saying I've seen a lot of critiques of LLM code boil down to "it's not how I'd write it" and I wager that holds for every developer you'll ever interact with.

replies(2): >>43236010 #>>43236155 #
4. KoolKat23 ◴[02 Mar 25 22:38 UTC] No.43236010[source]▶
I agree, it seems a lot of the complaints boil down to academic reasons.

Fine it's not the best and perhaps may run into some longer term issues but most importantly it works at this point in time.

A snobby/academic equivalent would be someone using an obscure language such as COBOL.

The world continues to turn.

5. dzaima ◴[02 Mar 25 22:55 UTC] No.43236155[source]▶
OP didn't put much effort into writing the code so I'm certainly not putting in much effort into a proper review of it, for no benefit to me no less. I just wanted to see what quality AI gets you, and made a comment about it.

I'm pretty sure the code not having the "if (…) lexer->line++" in places is just a plain simple repeated bug that'll result in wrong line numbers for certain inputs.

And human-wise I'd say the simple way to not have made that bug would've been to make/change abstractions upon the second or so time writing "if (…) lexer->line++" such that it takes effort to do it incorrectly, whereas the linked code allows getting it wrong by default with no indication that there's a thing to be gotten wrong. Point being that bad abstractions are not just a maintenance nightmare, but also makes doing code review (which is extra important with LLM code) harder.