> 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.

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.

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.

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.

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.

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!

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...

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!

Idk I routinely see the LLMs repeat validations that already happen in another layer or it imagines things that don't exist

My complaint is that LLMs’ approach to making code robust is something we used to pejoratively describe as “enterprisey”.

Oftentimes there are two broad ways to fix a gap in the logic. You can eliminate the source of it, which often involves refactoring but tends to result in less code and cleaner, more comprehensible logic. Or you can leave the gap there, but attempt to render it safe by adding extra logic to detect and handle the error condition. This reduces changes to existing code, but makes the overall system more complicated.

You can’t just indiscriminately favor one approach. Which one of those is best depends on the situation. The deciding factor is often something like a time constraint that you can’t know just by reading the code. You might need to talk to your team before deciding.

But LLMs don’t do that. They always choose option B: slap a bandage on it. Keep on adding more epicycles. In the 2000s we learned that, over time, always choosing this approach inexorably leads to codebases that are brittle, bloated and expensive to maintain.

So the problem, from my perspective, isn’t that we shouldn’t be coding defensively. It’s that LLMs encourage us to do it in a way that we’ve already learned is unsustainable.

Agree. It should fall on to developers to decide what to do = whether tackling tech debt is viable solution (whether making decision on their own or talking to people that can make such decision) or not. If, however, you're told "here is a codebase that you're seeing for first time, fix this error" and you simply cannot make the decision, even prior to LLMs you'd put a bandaid on it. Or at least - that's the standard approach = fix now, refactor later, where later in my experience never happens (sorry for this train of thought).

I don't think this is anything new, nor LLMs are to blame here

Agreed, it is not at all a new problem. The enterprisey codebases I’ve encountered are ones that have chronically had no clear owner, or constant ownership churn. I have been in that position before, and I also decided to make the code even more bloated for the same reason: I did not and was not going to have the time to learn the system well enough to safely do a better job.

I think where a lot of people run into problems with the KISS principle is they conflate simple and easy. More often than not, simple is hard. Which is maybe a soft reason why agentic coding, which is all about trying to make every task easy, leads so consistently to complexity and bloat.

Nobody else is likely to see this comment but I want to make it anyway. Yes, simple is hard. Thank you for articulating it so well.

And yes, that's also why LLM code is usually (unless driven by someone who really knows what he's doing) full of unnecessary complexity. Because although LLMs can get a much broader "understanding" of a code base than I would have given them credit for a couple years ago, their "understanding" is still shallow. And what you need to truly be able to achieve that hard simplicity (I heard someone refer to it once as "the simplicity on the other side of complexity", e.g. when Kepler figured out that orbits were ellipses, not circles, and that allowed getting rid of epicycles) is deep understanding. Which LLMs are not capable of, hence why their code is full of the kind of needless complexity that one produces when one has only a shallow understanding of the code. (E.g., you in that enterprisey codebase when you weren't going to be given time to reach deep understanding).

I don't think I agree that simple is hard. Simple takes effort. Simple requires that you have agency. Simple has all the information available. Simple means that you're accountable for something. I'll be cynical here - it's sooooo much easier to say: this is how it was when I arrived here, it's not my problem, what will I get out of this, somebody told me to do it like this. And nothing in the above is LLMs fault! Well, unless at least now you can say - something did it like that! It's not my fault, it's what LLM told me to do.

Anyhow, apologies for being glum and straying away from the topic, but I also wanted to make a comment that is unlikely to be seen :) the bile comes from personal experience and is not directed towards anyone

When you say "simple takes effort", that's kind of what I meant by "simple is hard". It takes work, it takes looking at the problem for a long time (Kepler studied orbits for years) until you understand it well enough to have the epiphany that lets you reduce the complexity down to "oh wait, orbits are ellipses and that solves everything!". Since you preceded your statement that "simple takes effort" with a disagreement about simple being hard, I wonder what you thought I meant by "simple is hard".

Very well stated

So true! And it goes hand-in-hand with a different problem: You being able to try and brute-force solutions.

If you write your prompt as a request, and not carefully as an idea or suggestion, the bot can blindly agree to 'help'. And if you are stubborn about it, you can lose hours on something that cannot work, or make the code infinitely worse.

However, it's also the path of getting better at programming. To learn to take a step back, to ask yourself if it's really sensible. Just that now it also involves questioning the bot's help, as well as writing your prompts to prevent it.