Hacker News
points by bunderbunder 3 days ago | 0 comments
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.

[–] eithed 3 days ago
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. Although - LLMs want to make you happy, or maybe they don't think about what user actually needs, just how to accomplish the goal that was stated; they do stuff without asking questions (unless you constrain them or plan first). I've actively put in a hook for my agent to not make decisions on their own and ask me when it detects it's about to make a decision.

[–] bunderbunder 3 days ago
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.

[–] rmunn 2 days ago
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).

[–] eithed 2 days ago
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, let's leave as it is, there's no point in touching 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.

I'm hopeful that LLMs make iteration and refactoring easier. That they'll allow developers to say to product (or even to themselves) "this module that is a dumpster fire? Sure, I can let agent investigate/refactor and that work that would have taken 2w will be done in half a day, do you want to go ahead?". That they'll allow developers to investigate how to make things simpler, more understandable, more coherent, to agree on a one fucking way to do things.

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 past personal experience and is not directed towards anyone (it's more of an acid reflux).

[–] rmunn 2 days ago
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".
[–] ShadowOfThePit 3 days ago
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.

[–] zeroonetwothree 3 days ago
Very well stated