LLMs, Abstractions and Local minimas
A look at how modern software and AI development have drifted into a shared local minimum, shaped more by convenience and accumulated abstractions than by real understanding. This episode explores whether AI can help us rethink complexity itself—or whether we're letting its limitations define our future.
Hi
I keep hearing this new anxiety forming around the supposed "decline" in code quality caused by LLMs. And I’m not sure this exclusivity is entirely warranted.
The claim usually comes from watching AI produce patterns that feel overly generic or overly borrowed, and people assume this signals of overall degradation. But that view ignores how uneven the baseline has always been. If you look at the actual distribution of code published publicly, most of it is inconsistent, hastily assembled, or shaped by the immediate pressures of product work. Against that landscape, the average model already produces more coherent structures, and it will only get stronger. The narrative that AI is driving quality downward focuses on the symptom and forgets the environment that produced it.
Software didn’t arrive at its current mess through one bad turn but it drifted here slowly, through years of piling abstractions on top of older abstractions, habits that rewarded quick delivery over clarity, and tools whose purpose was to cushion the impact of rising complexity rather than address it. By the time LLMs entered the picture, the terrain was already tilted. So they hardly reshaped the terrain but rather followed the slope, so to speak.
What stands out now is how naturally these models gravitate toward the architectural shortcuts and stylistic patterns that defined the last decade. The industry spent years hiding complexity behind increasingly opinionated tools, and what I think is that the models absorbed that entire lineage.
When they generate code, they lean back into the same grooves: the same helper layers, the same fashionable wrappers, the same constrained ways of using mature technologies. Those choices feel authoritative because the model is most fluent in that corner of the landscape. Over time, that fluency creates pressure. Teams quietly adjust their stack to fit what the assistant seems most comfortable producing, and the design space narrows into a local minimum shaped far more by the model’s habits than by our own architectural judgement. It’s the easiest path for the current generation of models, not the best path for software engineering.
The issue with that pattern is fairly direct: these systems are trained on an era of software where abstractions rarely reduced complexity in any deep sense. The hard parts were pushed sideways into tooling, libraries, frameworks, and glue code. Problems that used to be handled through architectural discipline were increasingly handled by adding more layers. That is the environment the models internalised - one where wrapping things is rewarded more consistently than understanding them.
LLMs ingest that entire period wholesale. They inherit its biases. They amplify its patterns. And suddenly people start optimizing their architecture to match the habits of a neural net trained on two decades of duct‑taped complexity.
This is the part nobody wants to admit: we’re aligning ourselves to the AI instead of demanding that the AI learn to work with the full abstraction space we already have.
Think about the absurdity of that. We invented Tailwind to reduce the mental load of humans. Now we’re arguing its dominance because it reduces the mental load of a machine. That’s how quickly the logic collapses when we don’t pay attention.
The truth is simple: LLMs are perfectly capable of learning raw CSS, BEM, Sass, architectural composition, design systems - if we train them for it. If we give them better data. If we stop feeding them only the artifacts of a period obsessed with convenience over clarity.
Before returning to the conclusion, it’s worth grounding this in the broader environment. We’ve seen multiple high‑profile infrastructure failures in the past few years - Cloudflare outages, AWS regional meltdowns, cascading dependency failures that ripple through half the internet. None of these happened because engineers suddenly became less competent. They happened because the systems have grown so entangled that even small misalignments propagate in ways no one team can fully foresee.
The same pattern shows up in consumer systems too. Recent macOS releases arrived with an unusual number of regressions, followed by rapid patches that introduced new edge‑case failures. That doesn’t signal a talent shortage at Apple; it signals that the operating system has reached a scale where maintaining global coherence is structurally harder than it used to be.
Modern software has reached a density where individual contributors hold a smaller and smaller share of the total system in their heads. As teams scale, the distribution of architectural intuition dilutes. Not everyone touching the stack has the same depth of design discipline, and the gap accumulates. The result is an ecosystem where complexity broadens faster than our ability to reason about it collectively.
We might also be over‑optimising for a local minimum inside AI itself. Frontier LLMs keep growing - hundreds of billions, soon trillions of parameters - immense reservoirs of compressed knowledge. Andrej Karpathy often points out that this knowledge‑density is both a strength and a constraint. A system that begins its “life” already filled with encyclopedic facts may lose the ability to form structure from experience. It becomes a memoriser first, a reasoner second.
Human children show us the opposite route. They start with almost no explicit knowledge - just a few priors and an architecture wired through evolution. And yet from this near‑empty starting point, they immediately begin dividing the world into meaningful pieces. A shape moving independently from its background becomes an entity. Repeated co‑occurrence becomes pattern. Similarity becomes category. Symbolic structure emerges after perception, not before it.
That progression matters. It shows that general intelligence does not require a trillion‑parameter preload. It requires mechanisms for turning raw sensory input into abstraction. If we keep scaling LLMs by packing more knowledge into bigger matrices, we may be moving away from the very thing we want: systems that generalise because they model structure, not because they memorise structure.
This is why people like Rich Sutton keep emphasizing reinforcement learning from environment interaction, why Yann LeCun keeps arguing for architectures capable of grounded world‑modelling, and why Karpathy warns against assuming that “just scale the LLM” is the right long‑term strategy. Their disagreements are real, but the shared concern is clear: the field risks getting stuck in an LLM‑shaped local minimum, simply because it’s the part of AI that is currently the easiest to scale and the most commercially visible.
And that brings us back to the conclusion. If we want to make sane decisions in the LLM era, we need to be painfully aware of what a local minimum looks like. We can’t confuse immediate AI comfort with long‑term engineering value. We can’t let the shape of our abstractions be determined by the friction profiles of today’s models.
These systems are good at handling cognitive load. That was the entire promise. So use them for that. Offload the mental overhead. Let them help with the boilerplate, the scaffolding, the repetitive glue.
But don’t let them define the architecture. Don’t let them dictate the layers we build. And definitely don’t let their current weakness become the justification for shrinking our expressive tools.
If an abstraction exists solely because humans struggled with complexity, and LLMs dissolve that complexity effortlessly, then clinging to that abstraction becomes irrational. The whole point of this technology is to widen the space of what we can work with - not narrow it.
So the only real question is: do we align our decisions to what helps the AI right now, or do we push the AI to handle the systems that already serve us best?
If we care about long‑term clarity, real composability, and real complexity reduction, the answer is obvious.
We stop optimizing for local minima. We stop letting the model’s convenience define our craft. We push the AI upward instead of dragging ourselves downward.
Because the abstractions will keep coming and going. The fashions will rotate. But the underlying complexity - the real substrate of software - that’s not going anywhere. And either we face it directly, or we let the tools lead us into a future built around their limitations instead of our intentions.
