points by layer8 3 days ago | 0 comments
> coding for situations that either do not happen or are unlikely to happen.
Not coding for situations that “do not happen” is exactly what creates vulnerabilities. But I also don’t think that such code is the main source of complexity in LLM-generated code.
[–] lilbigdoot 3 days ago
Idk I routinely see the LLMs repeat validations that already happen in another layer or it imagines things that don't exist
[–] ShadowOfThePit 3 days ago
I vibe-slopped a small and local forms application for my family. I explicitly mentioned that fact to the LLM.
Yet, I removed 2/3s of the code, because it triple-checked that every file really existed and was valid, that the input form was less than a million bytes in size, that there were propper HTTP status codes for everything, that every possible error from reading data was eagerly checked and caught, and so on.
Like come on, three people will ever look at it. So keep it small and tidy so I can understand it better!
[–] eithed 3 days ago
[–] Orphis 3 days ago
Having it in the lower layer is correct, a proper optimizing compiler should be able to detect there's a single code path to the function and that the checks have already been done, skipping the second check.
[–] alright2565 3 days ago
[1]: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
[–] eithed 3 days ago
[–] layer8 3 days ago
That’s why I think code needs to document all its assumptions, and in a way that is checked by the compiler to the extent possible. If you document that the values have restricted range, then the AI should be taking it into account.
[–] eithed 3 days ago
My main point still stands = LLMs code defensively catering for unknowns that are not loaded into context.