AI Has No Wisdom and Neither Will You
AI Has No Wisdom and Neither Will You
AI 没有智慧，你也不会有
In the past month alone I’ve heard these phrases: I haven’t written code since 2025; Code reviews are dead; People no longer read code. Certainly the industry is transforming, however, the people and organizations falling into the trap of no longer reading and writing code only do so at their peril. 仅在过去的一个月里，我就听到了这些说法：我从 2025 年起就没写过代码了；代码审查已经消亡；人们不再阅读代码了。诚然，行业正在转型，然而，那些陷入“不再阅读和编写代码”陷阱的个人和组织，这样做只会自担风险。
Fact is, vibe-coded projects devolve over time into an unmaintainable mess. The reason is simple, yet hard to fix: code maintainability and good architecture don’t have good measurements that we can apply, because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code. 事实是，靠“感觉”编写的项目随着时间的推移，最终会演变成无法维护的烂摊子。原因很简单，却很难修复：代码的可维护性和良好的架构缺乏可应用的有效衡量标准，因为要察觉到糟糕架构或不可维护代码的后果，往往需要数月甚至数年时间。
We can certainly define bad code: code that’s hard to read, hard to understand, hard to evolve for whatever the future throws our way. The kind of code in which changing one thing breaks the program in very non-deterministic ways, or breaks the logic somewhere else, far removed from your change, resembling the “butterfly effect”. 我们当然可以定义什么是糟糕的代码：难以阅读、难以理解、难以应对未来需求变化的代码。这种代码在修改一处时，会以极其不可预测的方式破坏程序，或者破坏远离修改点的其他逻辑，就像“蝴蝶效应”一样。
The kind of code where adding a feature means a serious undertaking due to changing code in multiple places and still forgetting to patch everything, thus getting inconsistencies. Code in which the invariants of the design aren’t clear, with its authors no longer being around to guard against violations and ensure some coherence. 这种代码在增加功能时意味着一项艰巨的任务，因为你必须修改多个地方，却依然可能漏掉某些补丁，从而导致不一致。在这种代码中，设计的恒定性（invariants）不明确，且原作者已不在场来防止违规并确保一致性。
Code that is hard to test, requiring mocks and exposing implementation details, leading to fragile tests that end up preventing meaningful refactoring. And yet, we know it as a fact that noticing bad code takes time. Months, years. 这种代码难以测试，需要大量的 Mock 并暴露实现细节，导致测试变得脆弱，最终阻碍了有意义的重构。然而，我们都知道一个事实：察觉到糟糕的代码需要时间。数月，甚至数年。
Of course, the experienced software engineers have a nose that can detect code smells and can take action long before the bad effects can be observed. The proficient developers, the experts, rely on their intuition built with sweat and tears, working long hours trying to debug and fix production issues, swearing to never again be so foolish as to repeat past mistakes. 当然，经验丰富的软件工程师拥有一种能嗅出“代码异味”的直觉，并能在不良后果显现之前就采取行动。那些精通的开发者和专家，依靠的是用汗水和泪水积累的直觉，他们曾长时间调试并修复生产环境的问题，发誓再也不要愚蠢地重蹈覆辙。
It’s the kind of intuition that can’t really be made into a list of rigid rules, because everything is context-dependent. Experts are incompatible with the same rules and recipes that make beginners more productive. Experts don’t follow the rules, they make the rules. 这种直觉无法转化为一套僵化的规则列表，因为一切都取决于上下文。专家与那些让初学者提高效率的规则和套路是不兼容的。专家不遵循规则，他们制定规则。
And so we have a problem… For one, AI is not trained on what it means for code to be maintainable. For instance, any reinforcement learning done needs a reward signal that can be measured immediately, not in months or years. The AI learns rules from rulebooks meant for beginners. The AI notices patterns from code in the wild and let’s be honest, most code in the wild is pretty bad. 于是我们遇到了一个问题……首先，AI 并没有接受过关于“什么是可维护代码”的训练。例如，任何强化学习都需要一个能立即衡量的奖励信号，而不是数月或数年后的反馈。AI 从面向初学者的规则手册中学习规则。AI 从现有的代码库中识别模式，但说实话，市面上大多数代码都很糟糕。
There is no fitness function you can define for maintainable code, at least not one that we can discern, otherwise it would’ve been baked into our linters. Have you noticed how terrible is the AI at “simplifying” code? Yes, the SOTA models. It can’t even define functions properly, choosing to split functions into smaller functions that are not actually reusable. 你无法为可维护代码定义一个适应度函数（fitness function），至少我们目前还无法识别，否则它早就被集成到我们的代码检查工具（linters）中了。你有没有注意到 AI 在“简化”代码方面有多糟糕？没错，即使是目前最先进（SOTA）的模型。它甚至无法正确定义函数，只会选择将函数拆分成实际上并不可重用的更小函数。
Extracting a smaller function from a bigger function is a very bad choice if, to understand the bigger function, you have to also read the implementation of the extracted smaller function. Defining reusable and clarifying functions is an art form, an art that takes mastery. Most developers, being still “advanced beginners” in the Dreyfus model, are not able to define good, clarifying, reusable functions and neither does the AI currently. 如果为了理解大函数，你还必须去阅读被提取出来的小函数的实现，那么这种提取就是一种非常糟糕的选择。定义可重用且清晰的函数是一门艺术，一门需要精通才能掌握的艺术。大多数开发者在德雷福斯模型（Dreyfus model）中仍处于“高级初学者”阶段，他们无法定义出优秀、清晰且可重用的函数，目前的 AI 也做不到。
This wouldn’t be so bad if people would still be in control and learn from those mistakes. But we are seeing a trend of people relying on AI to write, and even read code. Those people will never reach mastery, because they no longer make choices, they no longer take responsibility for mistakes in coding and no longer learn from those mistakes. 如果人们仍然能掌控局面并从错误中学习，情况还不至于太糟。但我们看到一种趋势：人们开始依赖 AI 来编写甚至阅读代码。这些人永远无法达到精通的境界，因为他们不再做选择，不再为编码错误承担责任，也不再从错误中学习。
It’s the AI that’s making mistakes now, the AI doesn’t learn from those mistakes, and neither are the people relying on AI for coding. Yikes! 现在是 AI 在犯错，AI 不会从这些错误中学习，而依赖 AI 编码的人也不会。天哪！
Don’t get me wrong, I think LLMs are a great tool. I’m no Luddite, I’ve integrated AI in my everyday work, while actually teaching my colleagues what I’ve learned. I gladly use LLMs to take care of all the boring, soul-sucking shit we have to deal with. I’m also enjoying the efficiency benefits that I’m seeing. 别误会，我认为大语言模型（LLM）是一个伟大的工具。我不是卢德分子（反技术者），我已经将 AI 集成到我的日常工作中，并积极向同事传授我的心得。我很乐意使用 LLM 来处理那些枯燥、令人心力交瘁的琐事。我也很享受我所看到的效率提升。
But at the end of the day, it’s just a tool, and like all other revolutions, its light will also fade; IMO, it already is, as right now tech news is frankly quite boring. People are actually terrible at making predictions. I believe the future will surprise all of us. 但归根结底，它只是一个工具，像所有其他革命一样，它的光芒终将褪去；在我看来，现在就已经开始了，因为坦率地说，现在的科技新闻相当无聊。人类在预测未来方面其实很糟糕。我相信未来会让我们所有人感到惊讶。
But, I’m going to make a prediction of my own… In the future we will see more and more companies proudly boasting their “NO-AI” policy as a competitive advantage. And they will be right. 不过，我要做出我自己的预测……未来，我们将看到越来越多的公司自豪地宣称他们的“无 AI”政策是一种竞争优势。而且他们是对的。
“But automated assembly lines are always more efficient” people say, except that the software industry is special, because we’ve always done automation at scale, everything we do is automation, LLMs are not the only means for it, and depending on context, it may actually be a distraction. 人们常说“自动化流水线总是更高效”，但软件行业很特殊，因为我们一直在进行大规模自动化，我们所做的一切都是自动化，LLM 并不是唯一的手段，而且根据具体情况，它甚至可能是一种干扰。
“Coding isn’t solved” in any meaningful sense. Sure, you can instruct the LLM to build you a C/C++ compiler, or you can just clone GCC or LLVM, and you’d get a better C/C++ compiler, for free, too. And maybe there are better ways to spend our time and resources than reinvent the same CRUD apps (human needs and desires are infinite, there’s no shortage of new goals to work on). If people and companies don’t start being responsible about its use, there will be consequences. 从任何有意义的角度来看，“编程问题”都没有被解决。当然，你可以指示 LLM 为你构建一个 C/C++ 编译器，或者你也可以直接克隆 GCC 或 LLVM，而且你会免费得到一个更好的 C/C++ 编译器。也许我们有比重复造 CRUD 应用更好的方式来花费时间和资源（人类的需求和欲望是无限的，永远不缺新的目标去追求）。如果个人和公司不开始负责任地使用它，后果自负。
Updated: September 22, 2026 | Written by Alexandru Nedelcu 更新时间：2026 年 9 月 22 日 | 作者：Alexandru Nedelcu