I don't think this is anything new, nor LLMs are to blame here
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.
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).
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
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.
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.