What might be bad for prose (predictable, boring) might be desirable for code. Maybe that's why LLMs work well for writing things read by computers, but not so much for things read by people.

> Maybe that's why LLMs work well for writing things read by computers, but not so much for things read by people.

They don't really work well for that, though.

The reason you hardly ever hear about it is because the people delivering code via LLMs aren't critically evaluating the code it generates. This is why Claude Code, a text app that is little more than glue between various text-suppliers, is what, 500k SLoC in a high level language?

Unless you're writing enterprise Java, conciseness and simplicity of design is still the ideal to aim for; those are not the adjectives I would use to describe LLM generated code.

Laziness is a feature. When you have a tool that is the exact opposite and solves code problems with more code, all you have is a machine that generates tech debt at exponential pace.

If code is predictable then it should be extracted into reusable functions/classes/modules and reused in accordance to DRY principle. I'm not a fan of this AI future where coding standards drop to the floor because humans won't be reading that code anymore.