We've spent years espousing that code isn't just for compilers to consume, it's meant to be read by humans, in the moment and later. I've been at this for 35 years.
With the advent of agent generated code, everyone's seeing a lot of code generated, in part at least, with t...
With the advent of agent generated code, everyone's seeing a lot of code generated, in part at least, with the help of the agent. I'm currently reviewing some code done by a junior developer. It's in a somewhat legacy (6 years old?) Swift code base. The submission is out of step with the conventions of the rest of the code base, and has lots of "best practice" things, but that aren't really relevant to the current problem. And the object design is terrible.
But, the code works fine and fits the desired bill.
I find myself wondering, in an age where LLMs reason about and generate the code, how much value should I place in code/structure readability? It's a very intrinsic value for me. But maybe this is a case where one's aged experience becomes a liability, where spaghetti code isn't a problem anymore of the LLMs reason about code differently. What are others doing?
Comments
By ahmed-fathi 2026-03-1221:211 reply 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.
By travisgriggs 2026-03-1221:331 reply > 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?
By ahmed-fathi 2026-03-1221:43 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
By serf 2026-03-1221:53 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.
