6 月 19 日，巴西开发者 Vinicius Brasil 在他的个人博客上发了一篇短文，标题直白到近乎挑衅：「当我拒绝 AI 代码，即使它能跑」。文章在 Hacker News 上获得 237 个赞、167 条评论——对一个没有产品发布、没有融资消息、纯粹讨论工程实践的个人博文来说，这个热度本身就是一个信号。
仅仅两天后，Flask 和 MiniJinja 的作者 Armin Ronacher 发布了一篇更长的文章「The Coming Loop」，从另一个方向切入了同一个问题：当编码 Agent 开始在一个「编程循环」（harness loop）中不停歇地自我迭代、无需人类中途介入时，产出的代码正在变得越来越不可理解——「我为代码设置了很高的标准，我想理解我交付的代码。」
两篇文章相隔 48 小时，来自两个不同大陆、不同背景的资深工程师，但它们的结论惊人地一致：AI 编码工具的速度已经超过了人类工程师理解和审查代码的速度，而行业还没有准备好面对这意味着什么。
五条拒绝理由，一条底线
Vinicius Brasil 列出了他拒绝 AI 代码的五条具体标准：
- 当 diff 比问题本身还大，拒绝。
- 当代码引入了未经证明就需要的抽象，拒绝。
- 当代码在本地能跑但让整个系统更难推理，拒绝。
- 当无法用自己的话解释代码的实现方式，拒绝。
- 当信任的是 AI 的输出而不是自己的理解，拒绝。
这些规则没有一条是关于「代码能不能跑」的。全部指向一个更深层的工程判断：代码的功能正确是入场券，不是毕业证。
他在文章中描述了一种认知过载：「即使我遵循了好的实践——从 plan 模式开始、把大任务拆成小阶段、小批量交付——审查那些我没有真正思考过的代码，仍然让我感到认知过载。」他说，用 AI 完成大任务仍然需要几天，而「更多时候，我拒绝 AI 的所有改动，然后从头开始。第一次会话和第二次的区别不是 LLM 模型，而是屏幕后面的人。」
Hacker News 上一位评论者把这概括为一句更狠的话：「你只有在认为自己比 AI 蠢的时候才应该接受 AI 代码。」（panchtatvam）
数字在说话
这种个人层面的挫败感正在被数据验证。根据 GitClear 对 1.53 亿行代码的分析，AI 辅助的代码存在系统性质量问题：代码改动率（churn——两周内被修改或删除的代码比例）显著上升，代码复用率下降。独立研究发现，包含 AI 辅助代码的 Pull Request 比纯人类代码多出 1.7 倍的问题。
Of Ash and Fire 的工程领导力指南引用了更具体的数字：组织在广泛采用 AI 编码工具后的六个月内，技术债务增加 30-41%；高级工程师在初级开发者大量依赖 AI 助手时，代码审查时间增加 20-35%。2024 年 Uplevel 对 800 多名开发者的调查显示，96% 的受访者对 AI 生成代码的可靠性和质量表示担忧，67% 的人报告调试时间反而增加。
速度提升正在被维护成本的增加所吞噬。
循环放大了问题
Armin Ronacher 的分析解释了为什么这个问题不是在变小，而是在变大。他的文章标题「The Coming Loop」指的是一种新的编程范式：工程师不再直接与 LLM 对话，而是编写一个外部循环（harness）来驱动 LLM 持续工作——把任务丢进队列，机器接手、尝试、停下来，然后由另一个机器或 harness 判断是否完成。如果没完成，继续循环。
Ronacher 坦诚地写道：「对于我真正在乎的代码，我还没有用这种方式取得太多成功。」他观察到，当模型在一个循环中无间断工作 30 分钟或更久时——比如 Claude Code 配合 Fable 模型——产出的代码比去年秋天人工介入较多的流程「更差」。
原因在于模型的固有倾向：它们「对异常有致命恐惧」（Karpathy 语），倾向于为每个可能的失败添加局部防御，而不是从根本上消除错误状态。循环会放大这种行为——每次迭代多加一层防御，系统表面上看起来更健壮，实际上变得更难理解。
「当你在循环后面加入更多循环，每个迭代添加另一个小防御，系统慢慢地变得更不可理解，同时看起来更健壮。你越放手，这种情况就越严重，」Ronacher 写道。
问题不在「能不能写」
这场讨论指向一个根本上不同的判断。过去两年，AI 编码的对话一直围绕着能力：模型能不能生成正确的算法？能不能补全函数？能不能通过 LeetCode 测试？
Vinicius Brasil 和 Armin Ronacher 同时把坐标移到了另一个轴上：可维护性。不是在问「AI 写的代码能不能工作」，而是在问「AI 写的代码值不值得维护，以及六个月后谁还能看懂它。」
Of Ash and Fire 的分析把这种模式称为「vibe coding」——基于对需求的模糊感觉快速生成代码，对实现细节和长期影响缺乏深入理解。这种做法的危害在代码库规模扩大时加速累积：不一致的架构模式、重复的逻辑、浅层的抽象、脆弱的测试。
一个被广泛引用的数据点是：AI 生成的代码被复制粘贴的频率更高，写完后短时间内被修改的频率更高，维护的一致性比人类编写的代码更差。
新的工程纪律
Vinicius Brasil 和 Ronacher 都不是 AI 反对者。Brasil 使用 coding agent 已有一段时间，承认它们「令人印象深刻」。Ronacher 是 Pi 的核心贡献者——一个正在被用于构建这些编程循环的工具。他们的立场不是拒绝 AI，而是拒绝用工程判断换取速度。
这正在催生一套非正式的、但越来越清晰的工程纪律：
第一，理解优先于合并。代码必须能被解释，不只是能运行。Ronacher 写道：「在压力下，或在与其他人的讨论中，我希望能够解释系统做了什么，而不需要先让一个 clanker 解释给我听。」
第二，克制优先于全面。AI 倾向于为每个可能的问题写防御代码。好的工程应该让错误状态不可表示，而不是为每种异常准备 fallback。
第三，人类审查不可替代。企业需要建立 AI 特定的代码审查标准：要求开发者标注哪些代码是 AI 生成的，审查者必须验证开发者理解实现而不只是代码能跑，对认证、授权、输入验证和数据处理的审查需要额外严格。
第四，知道什么地方不该用。不是所有代码都适合 AI 生成。安全关键的认证授权、核心业务逻辑、性能关键路径、新的架构模式——这些领域需要比 AI 当前能提供的更深的结构性思考。
速度之后
6 月下旬这两天里发生的事情，比看起来要重要得多。它标志着 AI 编码工具正在从「能不能」进入「该不该」的阶段。Vinicius Brasil 的个人博文之所以在 Hacker News 上引发 167 条讨论，不是因为他说了什么惊人的新发现，而是因为他精确地表达了一种正在大量工程师中累积但尚未公开凝聚的情绪。
Ronacher 把这种情绪的边界画得更清楚。他不是在反对循环——「我毫不怀疑这就是未来的方向。」他在问的是，在这个未来到来时，「我们如何不放弃判断，如何保留好的工程规则，如何确保负责任的人能够继续监督。」
这不是关于 AI 能不能写的争论。是关于写完之后的每一天。