Could the global economy survive what that would do to the B2B SaaS industry?

Plain http 1.0 is KISS. Does not really work that well.

Systems should be made as simple as possible, and no simpler.

That doesn't mean every simple system solves the problems we intend for it to solve. It means that all else being equal, we should prefer parsimony.

What I have heard from AI it is anything but KISS... More features and more code as fast as machinelly possible.

Depends on your incentives, most people and companies are measuring Lines of codes and features as the metric so ofc it will increase it, but AI can create small KISS applications. It might have a little difficulties in doing so sometimes because it sometimes likes to overengineer things but I have to wonder how much of it is because it is RLHF'd to solve questions at any costs in terms of lines of code rather than training it in solving it in KISS principles. Also I wonder how AI will perform if we explicitly treat KISS as the only principle and have checks running on it and have it discard all the code which wouldn't follow KISS principle if it doesn't follow the principle.

Dunno about your company, mine measures in lines of code removed.

> have checks running on it

We don’t have effective objective measures of what would constitute KISS.

> ... More features and more code as fast as machinelly possible.

i am going to quote that a lot...

I think 'clankerly' has a better ring to it.

People complain about LLMs not respecting KISS, but fail to address why = LLMs being defensive and coding for situations that either do not happen or are unlikely to happen. That doesn't absolve you from deciding using your human brain if given change makes sense or doesn't. You can also tell LLMs to not program defensively.

Same with any other acronyms - if you don't set up guardrails on when given principle should apply you'll get code that you can only complain about.

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

It doesn't have to be that way. You can use llms to greatly improve the quality of the code. You do this by focusing on one part of the design use the LLM to explore alternatives, use it to poke holes in what you have. I think the engineering cultures that embrace this way of using AI will far outperform everyone else in the long term.

I just had a discussion with the AI recently about whether to duplicate the code something used or refactor it so both places used the same code. The decision was to duplicate the code, but make notes (and a ticket) to refactor it later - because the time to test the possible regression cases of the original code wasn't available right now.

I could have worked through all that on my own, but having the AI as a rubber duck to talk to - plus the edge cases it was able to point out - was really helpful.

It's funny, I've had similar conversations, where the agent would recommend the 'lazy' solution because the robust one took too long. More often than not, it was assuming human-hours of work though. Once reminded that a clanker would be doing the work it's conclusion shifted to the robust one.

Now, I wonder if it actually agreed, or if it sensed that I preferred the robust solution and was trained to make me happy.

Yeah, I've seen that, too. In my case it was less about the dev time and more about the regression testing time (much of which would fall on QA and involved reading from external feeds, etc - so, complicated). But your point is fair. The AI is ... notoriously bad at LOE. Not that it's always wrong, but frequently enough (and by a large enough amount) that tradeoffs like that really need humans considering them.

It’s jarring when the bot tells you something will take a “week of work”. A good reminder I guess that it doesn’t have self awareness as we usually think of it.

[delayed]

> I just had a discussion with the AI recently about whether to duplicate the code something used or refactor it so both places used the same code. The decision was to duplicate the code, but make notes (and a ticket) to refactor it later

I wonder if a refactor is even necessary.

Concepts like KISS, DRY, etc. are largely human-centric. They're meant to make code easier to write, understand, and maintain - for people.

Duplicating code was traditionally "bad" because it increased maintenance costs, risked divergence, and added cognitive overhead for human developers.

But with coding agents, some of those tradeoffs start to change. An agent can find and update duplicate implementations in seconds. It doesn't need to maintain the same mental map of a codebase that a human does.

And if we have good specifications and comprehensive tests, behavioral divergence should be detectable and correctable. In fact, duplication can offer an advantage over shared abstractions: isolation. Changes to one implementation don't risk breaking unrelated consumers of shared code, and each implementation can evolve independently.

Maybe we won't need as many high-level abstractions, or eventually even some of the architectural patterns we consider best practices today.

If the cost of writing and maintaining code approaches zero, perhaps we should optimize less for human readability and more for runtime performance, memory efficiency, isolation, and correctness.

We might even regain some CPU and memory efficiency by eliminating layers of indirection, virtual calls, and abstractions that primarily existed to make code manageable for humans.

Perhaps the optimal architecture for AI-maintained software is fundamentally different from the optimal architecture for human-maintained software.

A lot of our software engineering best practices are based on the economics/ergonomics of human maintenance. What happens when those fundamentally change?

> Duplicating code was traditionally "bad" because it increased maintenance costs, risked divergence, and added cognitive overhead for human developers.

Until proven wrong by coding agents, this is still the case even for agents. Not sure why you are assuming this doesn't apply for the machine

I cannot read a 50-page T&C document. I mean, obviously, I can physically do it, but I don't have the patience, and I'd lose track of what I'd read. Getting an LLM to summarise a 50-page T&C document is simple, it doesn't lose track, and it spits out a summary in seconds.

I cannot read a 50K LOC code base at once. I mean, obviously, I can physically do it, but I don't have the patience, etc. I need mental shortcuts like abstractions layers to hold even parts of the code base in my head. LLMs don't. They can read that in seconds and hold the whole thing in context.

This doesn’t really support the argument that KISS et al don’t apply to LLMs. They may not ‘need’ these principles for the same reasons as humans, but will still benefit from the context having higher information density.

> but will still benefit from the context having higher information density.

That's an assumption.

And is that what we really care about anymore? Maybe we are ok accepting some "inefficiencies" in the code for the LLM but we get better CPU utilization or cache/RAM usage

> That's an assumption.

So is that ;) But yeah, the link between context length and performance reduction is well researched. Automatic context management has been getting better, but it’s not a panacea, especially in very large codebases and long sessions.

> Maybe we are ok accepting some "inefficiencies" in the code for the LLM but we get better CPU utilization or cache/RAM usage

If by ‘inefficiencies’ you mean choosing hardware-friendly architectures over those that correspond to a human-friendly world model, then I would agree with you (this was already required in my domain pre-LLMs). Even still that does not stop one from adhering to DRY, KISS, etc as the abstractions required are often either free or close to free at runtime.

>because the time to test the possible regression cases of the original code wasn't available right now.

The models don't know that they're not human when they estimate. It's worth telling them that all estimates need to be made in the context of an agentic AI doing the work.

I may be ignorant, but what do you mean with this and why is it upvoted so much?

To me KISS is basically about how you’d write the code, the architecture, which is something that - at least currently - humans need to oversee when writing new code with LLMs.

But what does it have to do with AI discovering a ton of bugs in a lot of (open-source) software?

A lot of these bugs are in rarely exercised code paths that probably shouldn't have been written into the software in the first place.

that people will finally start solving issues by simplifying the software rather than generating even more edge cases.

Software that does less is easier to understand and reason about, and typically requires less code. Less opportunity for bugs to appear.

Maybe, when they build a pomodoro timer, people will consider the possibility that the entirety of a browser engine as well as 30 000 javascript dependencies from random unvetted sources introduces unnecessary complexity and a practically infinitely fractal attack surface.

[delayed]

[delayed]

> but that makes it easier than ever to inflate codebases to millions of lines of unnecessary complexity that are impossible to work with and maintain.

Impossible for you, me, and other humans maybe. But not hard to understand for LLMs

> I want to see an LLM reduce a complex multi-million line codebase to 1/10th of its size or less without breaking functionality. That would be impressive!

They can and do, if you ask them to.

If you have tests to validate functionality, it can easily reduce and refactory.

But, why are we caring about LOC again?

Well, with fewer architecture astronauts overdoing things, all those extra abstractions and dimensions of extensibility that never get used never get written, so one might hope the code is simpler in the long run. But right now coding agents just love writing code, and they don't have a lot of taste for boundaries and architecture, so we have the loop-unrolled, big-pile-of-ifs kind of logic that isn't good.