News for hackers. Stuff that matters.
Re:AI is forcing us to pay off 40 years of technical debt by layer8 on Wednesday November 04, 2026 @09:23AM (#50365940)
> 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.

Re:AI is forcing us to pay off 40 years of technical debt by eithed on Wednesday November 04, 2026 @09:37AM (#50366114)
An example to what I'm talking about: I have application that takes two inputs from request. I've put in validation on request values to deny values that are greater than 100. In my code I'm adding these values. LLM can say "cater for addition of these two numbers, because they might go over MAX_INT". This is a situation that won't happen. LLM can recommend - add assertions. That's unnecessary.
Re:AI is forcing us to pay off 40 years of technical debt by layer8 on Wednesday November 04, 2026 @09:45AM (#50366243)
Arguably it’s only unnecessary when the value range is enforced by the programming language (types). The structure of who calls what in the code can change, and suddenly larger values can appear. You don’t want to have to perform whole-program analysis on every change to check whether all assumptions made in the past still hold. That’s also a source of vulnerabilities: assumptions that held when the code was written, but stopped holding sometime later.

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.

Re:AI is forcing us to pay off 40 years of technical debt by eithed on Wednesday November 04, 2026 @09:59AM (#50366474)
Types is an option. Another option would be tests (and in this case mutation testing).

My main point still stands = LLMs code defensively catering for unknowns that are not loaded into context.

Re:AI is forcing us to pay off 40 years of technical debt by Orphis on Wednesday November 04, 2026 @12:00PM (#50368422)
And the day you add a way to batch import request through another code path, you may forget the validation.

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.

Re:AI is forcing us to pay off 40 years of technical debt by eithed on Wednesday November 04, 2026 @01:40PM (#50369750)
Well - this would be an example of defensive programming and by that logic catering for this "what if" is the way to go. LLMs were correct all along!
Re:AI is forcing us to pay off 40 years of technical debt by alright2565 on Wednesday November 04, 2026 @06:24PM (#50372850)
Alternatively, the code could be written in the style of parse, don't validate[1]. However I've never had a coding LLM preemptively suggest that.

[1]: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

Re:AI is forcing us to pay off 40 years of technical debt by ShadowOfThePit on Wednesday November 04, 2026 @09:59AM (#50366485)
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 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!

Re:AI is forcing us to pay off 40 years of technical debt by lilbigdoot on Wednesday November 04, 2026 @11:40AM (#50368135)
Idk I routinely see the LLMs repeat validations that already happen in another layer or it imagines things that don't exist