The software industry is running a massive uncontrolled experiment: replacing the slow, painful process by which developers learn code architecture with tools that have never been trained on what "maintainable" means. The argument, advanced in a widely circulated essay, is structurally simple but hard to dismiss. Reinforcement learning requires immediate reward signals. Code maintainability reveals itself over months or years. Therefore, AI coding models are structurally incapable of optimizing for the quality that matters most at scale. This is not a Luddite argument. The author uses LLMs daily and teaches colleagues to do the same. The claim is narrower and more damaging: AI learns from rulebooks designed for beginners and from open-source codebases that are, on average, mediocre. It generates code that works but that degrades under the pressures of real evolution — feature additions, refactoring, team handoffs, debugging at 2 a.m. The butterfly-effect fragility the essay describes is familiar to every senior engineer who has inherited a codebase nobody understands. The Dreyfus model of skill acquisition sits at the center of the argument. Beginners follow rules. Experts transcend them, relying on intuition built through years of painful mistakes. AI is permanently stuck at the beginner level when it comes to architectural judgment — it can split functions but cannot tell you whether splitting that function helps or hurts readability in context. Most human developers are also stuck at the "advanced beginner" level. The difference is that humans can, in principle, keep climbing. Developers who stop reading and writing code never will. The skill atrophy dynamic is the most concerning extraction here. When a developer delegates code authorship to an AI, they also delegate the mistake-making process that builds expertise. The AI does not learn from its architectural errors. The developer, no longer making choices, does not learn either. This creates a compounding deficit: each month of delegation widens the gap between what the developer can evaluate and what the codebase requires. The essay's boldest prediction — that companies will market "NO-AI" policies as competitive advantages — reads as contrarian today but has structural logic behind it. If vibe-coded projects reliably degrade over 18-36 months, organizations that maintained deep human expertise will hold an asset that cannot be quickly rebuilt. The software industry's unique position strengthens this: unlike manufacturing, software development has always been automation. LLMs are one more automation tool, not a paradigm-ending revolution. The honest limitation of the argument is that it lacks data. The claim that AI-generated code degrades faster than human-authored code is plausible and structurally sound, but no longitudinal study has measured it. The essay operates on pattern recognition from experienced practitioners, not controlled evidence. That said, the absence of evidence is itself part of the problem — maintainability metrics are precisely the kind of slow-feedback signal that resists easy measurement. What the industry faces is a classic tragedy of the commons. Individual developers and companies capture immediate productivity gains from AI coding tools. The costs — skill atrophy, architectural degradation, unmaintainable codebases — are distributed across time and across the teams who inherit the code. The question is not whether AI coding tools are useful. It is whether the industry will use them responsibly enough to avoid a generation-wide erosion of the expertise required to maintain what gets built.
