YC CEO Garry Tan 发了一条推：他和 AI 代理每天部署 37,000 行代码。听起来像 AI 编程的胜利宣言。
然后波兰开发者 Gregorein 去审查了 Garry 网站的前端代码。发现大量臃肿——重复的 CSS 声明、不必要的封装层、AI 生成的注释比代码还长。37,000 行里的很大一部分是不应该存在的。
这不是一个"AI 写的代码质量差"的故事。这是 AI 编程叙事正在撞上它一直回避的问题：当审查速度跟不上生成速度时，代码量不是生产力指标——是技术债积累速率。
37,000 行到底意味着什么
一个中大型前端项目——比如一个有支付、用户系统、后台管理的 SaaS 产品——用传统方式开发，核心代码大约 10,000-30,000 行。每天部署 37,000 行意味着 AI 一天写了整个产品的代码。
问题是：没有人能在一天内审查 37,000 行代码。一个经验丰富的高级工程师的 code review 速率大约是 200-400 行/小时。37,000 行需要 90-180 小时——即使把代码审查拆成 5 个工程师，也需要 2-4 个工作日。每天部署意味着没有人审查上一批代码的时候，下一批已经写完了。
这不是"AI 让工程师更高效"。这是"AI 让技术债的积累速度从月级变成了天级"。过去，一个五人的工程团队花三个月写的代码会积累三个月左右的技术债——然后花两周做一次重构。现在，AI 在一天之内写的代码可以在一周之内积累出需要一个月重构的技术债。
关键不是代码能不能跑——是代码跑了一年之后，谁敢动它？
AI 编程的真正瓶颈不是"能生成多快"
过去一年里 AI 编程的叙事是"AI 在 SWE-bench 上从 2.5% 到了 16.1%"。速度是唯一被谈论的维度。
但 Garry Tan 的 37,000 行暴露了另一个维度——不是生成速度，是审查带宽。代码质量是审查出来的，不是生成出来的。但当你的生成速度超过了审查带宽——你的代码质量就不是 AI 的能力决定的。是你的"不审查"决定的。
这不是 AI 的问题。这是人在被 AI 提速之后，忘记了自己是最后一道防线的角色。一个工程师用 Cursor 写代码——AI 建议了一段，他看一眼觉得"差不多"，点接受。重复 100 次。100 次之后，项目里有 100 段"差不多"的代码。每段单独看都没问题。合在一起——CSS 重复了三遍、事件监听器有两个做同一件事、错误处理路径互相覆盖。"差不多"的叠加效果不是"差不多"——是"失控"。
这和上周苹果的研究形成了精确的呼应——单个神经元可以绕过 LLM 的安全对齐。两件事在说同一个东西：系统的脆弱性不在于单个组件的质量。在于组件的叠加效应没有被任何人在任何时候完整审查过。
好消息是——AI 也可以审查 AI
同一周，AI 审计代理在 Cloudflare CIRCL 中发现了 7 个漏洞。AI 写代码，AI 审查 AI 写的代码——这个闭环正在形成。但关键问题是：审查的那个 AI 是谁训练的？如果也是同一个基础模型——它在审查自己写的代码时会不会有盲区？
Garry Tan 的故事不会有太大影响——他发完推，被扒出代码质量问题，过几天大家就忘了。但这件事应该在每个用 AI 编程的团队墙上贴一张便签："每天部署多少行"不是 KPI。"每天被审查通过多少行"才是。 如果你说不出今天的代码是谁审查的——那就是没人审查。而没人审查的代码，不是资产。是定时债务。