> I believe that elegant code is a different bulding material to ugly code. Ugly code is harder to change. At some point, it becomes impossible to change.

I believe the same thing and it’s also the main reason I hate AI code.

AI tends to not have much regard to “architecture” or even really considering how code should be organized. Need a function to read a base64 string into a private key? “fn base64_to_key” right there next to the code that needs it. Need to take that key and encrypt a blob? “fn encrypt_blob” right next to it. No thought about maybe pushing that code to a crypto module, or representing the invariants as types, or even just putting the functions where they might logically belong, just spews them out everywhere.

But, I have a problem trying to prove why this is an actual problem in the end product. You can say “it’s harder to refactor later” but the LLM is already pretty good at just changing bulk amounts of code to behave differently. In fact, having utility functions “nearby” the code that needs it might be better for its own context management. Most of the reason humans prefer the “single responsibility principle” and “modular design” are to make the code easier for us to change and reason about, but an LLM with a finite context window may actually do better with code that doesn’t match this premise.

I find myself reviewing code that others on my team generated with an LLM, and I tend to focus on these sorts of architectural “problems” the most because it’s the biggest gap between the way I program and what the LLM executes. But sometimes I worry that I’m fighting a losing battle, and that the focus on good architecture isn’t as important as I think it is. Or at least, I’m having trouble proving that it actually matters tangibly. Will it result in an unmaintainable mess? Maybe. It’s not guaranteed that LLM’s have the same limitations we do when it comes to maintaining code.