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 take it into account.
My main point still stands = LLMs code defensively catering for unknowns that are not loaded into context.
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.
[1]: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
Yet, I removed 2/3s of the code, because it checked every file if it REALLY exists, that the input form was less than a million bytes in size, that there were propper HTTP status codes for everything, and that every possible error from reading data was eagerly checked and caught.
Like come on! Less than five people will ever look at it! They aren't going to try to exploit it!
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.