George Hotz 这次说得很重。
5 月 24 日，他在博客《The Eternal Sloptember》里批评 AI agent 被大规模引入软件开发。他的核心判断是：agent 并没有真正学会编程，而是在更熟练地生成“像程序”的东西。
这句话危险的地方，不在于它反 AI。
Hotz 过去 6 个月并不是站在门外看热闹。他自己用 agent 参与过 tinygrad 的部分代码开发，也用它辅助做 USB-PCIe 芯片逆向。他承认 AI 在搜索、快速原型、不要求长期维护的任务里有用。
但他不接受一个跳跃：能写代码片段，不等于能当软件工程师。
我更在意的也是这个跳跃。软件工程的难点，常常不在“把代码写出来”，而在验证、收尾、维护和负责。AI agent 把前半段做得更快，却可能把后半段变得更难。
Hotz 真正反对的，是“像对了”的代码
Hotz 描述的体验很具体：agent 很快给出大量进展，文件改了，函数补了，测试也可能过一部分。然后问题出现了。
边界条件没想清楚。修一个 bug 又带出新 bug。开发者开始改 prompt、换模型、重跑任务，等一个刚好能过的结果。
这和传统代码补全不是一回事。
GitHub Copilot 这类工具更像副驾驶，主要帮人补句子、补函数。到 Devin、Claude Code、Cursor 里更主动的 agent 叙事，目标已经变成跨文件修改、调试、测试和交付。争议也从“能不能补全”变成“能不能承担工程闭环”。
可以把差异压成一张表：
| 场景 | AI agent 目前更像什么 | Hotz 担心什么 | 团队该怎么用 |
|---|---|---|---|
| 搜索资料、定位线索 | 更快的搜索器 | 混入错误依据 | 让人复核来源和结论 |
| 快速原型 | 草稿机 | 原型被误当交付物 | 明确标注不可直接上线 |
| 跨文件改动 | 高产改码工具 | 缺陷藏得更深 | 提高 review 门槛，而不是降低 |
| 长期维护 | 还不稳定的代理 | 无法解释设计取舍 | 关键路径必须有人负责 |
这里的重点不是“AI 没用”。
它有用，但用途要放对位置。搜索、试错、搭骨架，AI 能省时间。架构判断、边界设计、回归验证、长期维护，它还不能替团队签字。
软件工程师最实际的动作，是把 agent 输出当成陌生人提交的 PR。能跑不够，能解释才算数。尤其是权限、支付、数据迁移、并发、底层驱动这些位置，不能因为代码是 AI 写的就少看一眼。
高手和大组织，承受 AI 低质输出的能力不同
Hotz 对个人和组织做了区分，这点很关键。
高水平个人或小团队，反馈快，代码上下文在脑子里。agent 写错了，人能马上停下来，删掉，重写，或者换一种方式问。工具在他们手里更像放大器。
大组织的情况复杂得多。
需求被拆细，评审链条变长，很多管理指标还停留在提交量、需求吞吐、测试通过率和 demo 进度上。agent 一旦把代码产量拉高，组织最先看到的是“更多产出”。真正的成本，可能躲到返工、重构、线上问题和新人接手时才出现。
这不是说大公司一定会被 AI 伤到。没有足够证据，不能下这种结论。
但现实约束摆在这里：组织越大，越容易把局部效率误读成整体效率。尤其当底部表现者用 agent 生成更多代码时，review 压力会转移给少数能判断质量的人。
技术管理者需要做的不是急着禁用，也不是急着全员推广。更稳的做法是先改评估口径：
| 管理动作 | 不建议只看 | 更该增加的观察项 |
|---|---|---|
| 采购 Copilot、Cursor、Claude Code 或内部 agent | 授权人数、生成代码量 | review 时间、返工比例、缺陷回归 |
| 推动团队使用 agent | demo 数量、需求关闭数 | 关键模块事故、测试可信度 |
| 评估个人效率 | commit 数、PR 数 | 代码可读性、交接成本、问题定位速度 |
| 扩大到核心系统 | 短期吞吐 | 维护 3 到 6 个月后的质量变化 |
如果团队还没有能力做好 code review，就不适合先把代码生成速度拉满。
如果已经采购了工具，也不必立刻回退。更现实的动作是分层使用：非核心脚本、内部工具、原型验证可以放开；核心业务、底层系统、迁移脚本和安全相关模块要保守。把 AI 输出纳入更严格的 PR 模板，而不是让它绕过人的判断。
Hotz 提到过“听说 Apple 正推动工程师使用 AI”。这类说法目前只能按传闻处理，不能写成确认政策。更可观察的变量是：大型软件系统在引入更多 AI 辅助开发后，缺陷修复速度是提高，还是边角问题变多。
这比听一家公司怎么表态更重要。
旧的质量信号正在失效
Hotz 更深一层的怀疑，指向 LLM 路线本身。
过去看代码，很多信号有参考价值。命名顺、结构清楚、注释像样、测试能跑，通常说明写代码的人理解了问题。现在这些信号没那么可靠了。
因为 LLM 很擅长生成“像工程产物”的文本。
它能模仿代码风格，能补齐常见模式，也能给出看似合理的解释。但 Hotz 认为，这不等于模型真的完成了人类开发者会做的建模过程：理解系统状态、约束、因果关系和长期后果。
这也是他提到 world models 的原因。真正可靠的编程 agent，不能只靠统计模仿语言分布。它需要更扎实地理解程序运行的世界，知道一个改动会怎样影响状态、接口、硬件、依赖和未来维护。
这个判断和 Yann LeCun、Gary Marcus 等人对纯 LLM 路线的怀疑有相近之处：语言能力很强，不自动等于世界理解足够强。
当然，反过来也要说清楚。现在的 agent 并不是一无是处。很多工程师已经能用它加速搜索、写样板代码、生成测试草稿、搭原型。问题只在于，组织不能把这些能力直接外推成“它能负责软件工程”。
接下来最该观察的不是模型发布会上说自己会写多少代码，而是几个更硬的指标：
- AI 生成代码进入主干后，返工比例有没有升高；
- review 时间是减少了，还是被隐性转嫁给资深工程师；
- 线上事故和回归缺陷有没有集中出现在 AI 参与较多的模块；
- 新成员接手 AI 生成代码时，理解速度是变快还是变慢。
这些指标不性感，但更接近工程真相。
回到 Hotz 的文章，它最有价值的地方，不是给 AI 编程判死刑，而是提醒团队别被“像对了”迷惑。
代码能生成，只是开始。谁能判断它对不对，谁能在半年后维护它，才是软件工程真正的门槛。