Code style still matters, but the reason has shifted and that shift is worth being precise about.
The old argument was humans read code, so write for humans. The new reality is LLMs also read code, and they read it differently. They don't get lost in deep nesting the way a junior dev does, but they are surprisingly sensitive to naming ambiguity, inconsistent abstraction levels, and context fragmentation across files. A well-structured codebase gives the model a coherent "world model" to reason within. A spaghetti codebase gives it conflicting signals, and it hallucinates confidently in the gaps.
So the argument for style hasn't disappeared it's been redirected. You're now writing for two audiences the human reviewer and the model that will modify it next.
The part I'd push back on in your framing "the object design is terrible" is not a style issue. That's the part that actually breaks down under AI-assisted development. Models are very good at generating locally coherent code and very bad at maintaining global architectural integrity across iterations. Bad object design doesn't become invisible to LLMs, it compounds. Every subsequent generation inherits and amplifies the structural confusion.
No single paper nails that exact claim. SWE-bench Princeton does show that models struggle significantly with real-world issues requiring changes across multiple files and functions which points in that direction. But the local vs global framing is mostly practitioner-observed, not a formally tested hypothesis yet. Fair point, I should have hedged it. https://arxiv.org/abs/2310.06770
Go create a big monolith in an LLM versus a high compartmentalized and decomposed/modular codebase that does the same thing.
The LLM is going to optimize the shit out of the decomposed version and maintain it well, and it's going to struggle to find even trivial bugs in the monolithic version.
Code style still matters, but the reason has shifted and that shift is worth being precise about.
The old argument was humans read code, so write for humans. The new reality is LLMs also read code, and they read it differently. They don't get lost in deep nesting the way a junior dev does, but they are surprisingly sensitive to naming ambiguity, inconsistent abstraction levels, and context fragmentation across files. A well-structured codebase gives the model a coherent "world model" to reason within. A spaghetti codebase gives it conflicting signals, and it hallucinates confidently in the gaps.
So the argument for style hasn't disappeared it's been redirected. You're now writing for two audiences the human reviewer and the model that will modify it next.
The part I'd push back on in your framing "the object design is terrible" is not a style issue. That's the part that actually breaks down under AI-assisted development. Models are very good at generating locally coherent code and very bad at maintaining global architectural integrity across iterations. Bad object design doesn't become invisible to LLMs, it compounds. Every subsequent generation inherits and amplifies the structural confusion.
> Models are very good at generating locally coherent code and very bad at maintaining global architectural integrity across iterations.
Is there any published work on this? Or just more of an observed accusation?
No single paper nails that exact claim. SWE-bench Princeton does show that models struggle significantly with real-world issues requiring changes across multiple files and functions which points in that direction. But the local vs global framing is mostly practitioner-observed, not a formally tested hypothesis yet. Fair point, I should have hedged it. https://arxiv.org/abs/2310.06770
Absolutely.
Go create a big monolith in an LLM versus a high compartmentalized and decomposed/modular codebase that does the same thing.
The LLM is going to optimize the shit out of the decomposed version and maintain it well, and it's going to struggle to find even trivial bugs in the monolithic version.
Why? Context and token cost.