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

I'll add to your list this one https://hackage.haskell.org/package/waterfall-cad . I highly recommend it

So that is the way you want to live ? Just being mechanical ? I don't see the point of solving those problems if it mean that our day to day life is shit. The point of tech is to make our life easier, AI doesn't. It just want to replace us as it is today

Craftsmen of all kind probably said the same thing when machines suddenly did their work cheaper and faster (and better?).

I still do diagrams. Not UML specifically, but using mermaid.js. It is a great way to think about the requirements before coding

> When was the last time you ..or anyone.. reviewed the assembly language or binary output of your compiler?

not even a week ago. But generally people prefer to burn millions on compute instead of seeing the output of the compiler and see how they can optimise their code

> Not many people are such cowboys today.

Now-day, it is the llm that write tests. Nobody look at it and verify if it is meaningful. If the test pass, ship it.

It still cowboys days

Glad it gave you a good laugh!

Not only that. Citing "What doesn't kill you make me stronger" in this context is very ironic as Nietzsche was talking for himself. He took that from Ralph Waldo Emerson while stripping the moral aspect of it

As another more poignant philosopher said, "what doesn't kill you makes you very, very weak"

What doesn't kill you postpones the inevitable.

it is not because it work that it is good. It still need to be maintained and this is a huge deal

That is magic thinking and even religious