过去一个月里听到了这些说法：从2025年起就没写过代码了；代码审查已死；人们不再读代码了。行业正在转型，但不再读写代码的个人和组织是在自冒风险。事实是，vibe-coded 项目会随时间恶化成无法维护的混乱，原因简单却难修复：代码可维护性与好架构没有可应用的衡量标准，因为需数月甚至数年才能注意到坏架构的影响。我们可定义坏代码：难读、难懂、难演进的代码。

过去一个月里，我听到了这些说法： - 我从2025年起就没写过代码了； - 代码审查已死； - 人们不再读代码了。

行业确实在转型，但那些掉进不再读写代码陷阱的个人和组织，这么做只会自食其果。

事实是，靠“氛围”写出的项目会随时间变成无法维护的烂摊子。原因简单却难解：代码可维护性和好架构缺乏可落地的衡量标准，因为坏架构或难维护的恶果往往要数月甚至数年才显现。

我们当然能定义坏代码：难读、难懂、难以应对未来变化。改一处就以极不确定方式让程序崩溃，或破坏了离改动很远的其他逻辑，像“蝴蝶效应”。加功能要在多处改动还漏补，导致不一致。设计不变量不清晰，原作者不在了，没人守护一致性。难以测试，需要 mock 并暴露实现细节，测试脆弱得反而阻碍重构。

不过，识别坏代码需要时间，得几个月甚至几年，这是事实。当然，资深工程师凭直觉就能嗅出代码异味，在恶果前就动手。

熟练开发者和专家，依赖的是用汗水泪水、靠长时间排查生产问题熬出的直觉，发誓不再犯蠢错。这种直觉没法列成死板规则，因为一切看上下文。专家与让新手高效的规则套路格格不入。专家不守规则，他们制定规则。

于是我们有了麻烦……

首先，AI 没被训练去理解代码可维护性。比如强化学习需要能立刻测量的奖励信号，而非几个月或几年后。AI 从给新手的规则书学规则，从野外代码找模式——说实话大部分野外代码很糟。我们给不出可维护代码的适应度函数，否则早写进 linter 了。

你注意到没，AI 在“简化”代码上有多烂？哪怕是 SOTA 模型。它连函数都定义不好，硬把大函数拆成其实不可复用的小函数。如果为看懂大函数还得读拆出的小函数实现，这种提取就很差。定义可复用清晰的函数是门艺术，需精通。多数开发者在 Dreyfus model 里还只是“高级初学者”，定义不好函数，目前 AI 也一样。

如果人还掌控并从中学习，这还不算糟。但我们正看到趋势：人们靠 AI 写代码，甚至读代码。

那些人永远达不到精通，因为他们不再做选择，不再为代码错负责，也不再学。现在是 AI 犯错，AI 不学，依赖 AI 的人也不学。

别误会，我觉得 LLM 是好工具。我不是卢德分子，已把 AI 融入日常工作，还教同事。我乐意用 LLM 处理枯燥折磨人的活，也享受效率。但说到底只是工具，像其他革命光芒会褪去；我觉得已经在了，现在科技新闻实在无聊。

人不擅长预测，未来会惊到所有人。但我还是要预测……

未来会有越来越多公司把“无 AI”政策当作竞争优势骄傲宣扬。他们是对的。

有人说“但自动化流水线总是更高效”，只是软件业特殊，我们一直规模化自动化，做的事本身就是自动化，LLM 不是唯一手段，看上下文甚至可能分心。“编码问题”在实质意义上未被解决。你可以让 LLM 造 C/C++ 编译器，或直接克隆 GCC 或 LLVM，白拿更好的。也许有比重造 CRUD 应用更好的资源用法（人类需求无穷，新目标不缺）。

如果个人和公司不对使用负责，就会有后果。

这场讨论整体情绪是厌倦和怀疑：多数人不接受“vibe coding 必然烂尾”的末日论，认为人类代码本来就烂、可维护性可被工程手段约束，且对长期后果的断言还太早；少数人则坚持机构知识和责任风险才是真问题。分歧主轴在于，问题到底出在 AI 本身，还是出在使用者水平、组织纪律和是否有人负责。

认为 AI 代码不一定比人类写的更差

• 人类历史上大量代码库本就不可维护，中位项目在 agent 出现前也常常是泥潭；有 15 年经验的开发者见过人类能写出更糟的东西。（较多人）
• 在二十多年、成千上万开发者使用的老代码库里，AI 每天都能找出前 AI 时代的 bug，因此它至少已与普通开发者持平，NO-AI 只会缩到极小 niche。（较多人） > 我在一个二十多年、成千上万开发者使用的代码库里，AI 每天都在找出前 AI 时代的 bug。（@micromacrofoot）

认为可维护性取决于工程约束、评审和反馈，而不是 AI 的固有缺陷

• 从纯 vibe coding 到手工 DDD 是一个连续谱；只要明确目标、接入质量指标、让人作为真实用户反复使用并修正，coding agent 也能产出可维护系统。（较多人）
• 资深工程师需要先写核心模式、参考文档和 agent 指引；AI 一旦学到模式，守规矩程度可能超过人类团队，问题在于团队是否愿意为这些产物慢下来。（较多人） > 没有任何东西阻止你把 SonarQube 这类指标接进 agent 工作流。（@davedx）

认为对 vibe coding 长期演化的断言还太早，而且讨论已经老调重弹

• 强编码 agent 出现不到一年，任何“随时间必然腐化”的定论都更像猜测；这是一项仍在改进的新技术，只能算时点批评。（较多人）
• 很多帖子没有新思想，只是重复“这很糟、你也很糟”，无法说服已经在用 AI 快速出货的人，社区也明显疲惫。（较多人） > 强编码 agent 出现还不到一年，对 vibe-coded 项目长期演化的定论只能算猜。（@sobiotite）

认为“好代码”没有跨组织通用定义，AI 的最优结构也未必照搬人类

• 好坏取决于领域、团队能力、软件寿命和变更预期；维护性差只有在必须由人类独自接手时才致命。（较多人）
• AI 常生成 God Object 等人类反模式，但对机器维护者可能更快更简单；边界可以写进规格，设计重心可转向数据语义、不变外部契约和迁移策略。（较多人） > 好代码会随组织形态变化，坚持一套普适标准更像自我催眠。（@jdw64）

认为 AI 大幅加快重构，架构不再是不可逆判决

• 过去数月甚至数年的重构，现在可能数小时完成，代码库像叶子随风弯曲；AI 可能留下架构问题，但修复代价和可逆性完全变了。（较多人）
• 如果代码主要由 AI 维护，那么“人类觉得烂”的意面代码未必真的会崩，除非人类必须无助手维护。（较多人） > AI 可能留下基础架构问题，但架构不再刻在石头上，整个代码库会像风中的叶子一样弯曲。（@donatj）

认为真正危险的是机构知识和判断力的退化

• 依赖 AI 包办编码、写作和设计，会让人不知道组织里谁懂什么、该学什么，也失去“好是什么样”的内部参照；人在环审查仍不可少。（较多人）
• 大学和职业前三年应限制 LLM，基础训练不能跳过；否则用 AI 只会放大不会判断的问题，知识不能靠外包获得。（较多人） > 问题不在 AI 擅长什么，而在机构知识：当 AI 包办编码和设计，没人再知道该学什么、好是什么样。（@FinnLobsien）

认为“NO-AI”公司既不会成为主流，也招不到人

• 消费者不关心代码是否手写；把 NO-AI 当卖点，像过去的 NO-CLOUD 一样可疑，只会成为小众。（较多人）
• 几乎没有工程师愿意去禁用 AI 的公司，这类公司可能无法生存或只服务极少数怀旧客户。（较多人） > 没有哪个工程师会想去一家高调宣称 NO-AI 的公司。（@vale900i）

认为高风险场景必须有明确的人类责任和审查

• 简单提示只能做草图；银行结算、起搏器、敏感数据删除等系统需要有人理解并承担责任。（较多人）
• “agent 修 agent 破坏的东西”也许成立，但放松严格引导通常很快出问题；工具可以日常用，选择与责任仍必须落在人身上。（较多人） > 我可以每天用 LLM 扩展方案空间，但做出来的东西要是我的，选择和责任必须停在我这里。（@EastLondonCoder）

认为手写代码没有消费者可见的特殊价值

• 消费者要的是便宜可用的软件，不是手工艺品；从劳动价值论看，手写与否无关紧要。（少数人） > 消费者不关心代码是不是手写的，他们要的是便宜的软件产出。（@bklosky）

认为简单提示只能做原型，不能替代主导

• 不引导、不理解 LLM 输出，就只能得到能跑但没有未来规划的草图；生成音乐式“像样却无话可说”的风险同样适用于 vibe coding。（少数人） > Suno 生成的音乐听起来像合格的音乐却无话可说，vibe coding 的软件也类似。（@EastLondonCoder）

有价值的补充

• 圈复杂度只是可维护性度量之一，SonarQube 等指标可以接入 agent 工作流，所以“无法度量可维护性”的说法站不住脚。（@davedx）
• AI 把大重构从月/年压缩到小时，这是原文漏掉的反转：架构决策的可逆性显著提高。（@donatj）
• 如果主要维护者变成 AI，God Object 等反模式未必是坏结构；设计重点可转向数据语义、不变外部契约和迁移策略。（@jdw64）
• 批评 AI 的作者自己的静态站也依赖 Cloudflare、Mailchimp、Postmark、Isso；二十年前开发者也许会选择自托管，因此 NO-AI 优越感像 NO-CLOUD 一样可疑。（@themgt）
• 专家不遵守规则，而是靠直觉和权衡制定规则；对新范式最狂热的往往刚皈依、还没体会权衡的人。（@t43562）
• 把风筝当成滑翔机，是一次性提示开发生命周期的典型误判。（@itomato）