“没有人写代码，也没有人读代码”——这是StrongDM今年年初为自己的Agentic开发平台打出的口号,也是HumanLayer创始人Dex最近撰文正面开怼的对象。他在博客《Why Software Factories Fail》里说,把AI编程再堆更多循环、测试和审查机器人,解决不了棕地生产系统的可靠性问题,因为瓶颈根本不在生成代码的速度上,而在模型训练和评测方式本身。这篇文章的份量不止于一次口水战:它把过去半年“熄灯软件工厂”叙事里被绕开的那部分事实,重新摆回了桌面。
需要说明,Dex经营着一家做人机协同工具的公司HumanLayer,他站在“人仍需要介入”这一边并不意外——但这不妨碍他把StrongDM、OpenAI摆到台面上对照着讲。
“熄灯工厂”离量产还差一份进展报告
StrongDM二月发布的lights-off software factory,主张很直白:你才是瓶颈,模型已经够用,代码是免费的,那就多发布。这套说法听起来眼熟——“软件工厂”这个词本身能追溯到1968年NATO软件工程会议,每一代技术都会重新讲一遍“把工程师从琐碎劳动里解放”的故事。OpenAI的Ryan Lopopolo二月写了harness engineering,四月又在演讲里介绍了OpenAI自己的软件工厂Symphony——同一套叙事,不同公司在各自复述。
但StrongDM从2月到6月的weather report更新稀疏,没有交出任何决定性数据证明“无人读代码”真的跑通了。直到7月23日,团队才在Hacker News上和网友对话时松口说会有更正式的更新——这说明项目还在推进,不是已经黄了,只是这半年里,证据一直没跟上口号的速度。
瓶颈从没消失,只是从写代码搬到了评审代码
Faros AI拿真实项目数据做了份报告:AI编程工具铺开之后,PR评审的评论更多、更长,31.3%的PR干脆跳过评审直接合并;与此同时每PR事故率涨了242.7%,月度事故涨了57.9%,人均缺陷数涨了54%。
这份数据只能算相关性信号,不是因果证明——Faros自己没有把“AI编程工具导致质量下滑”钉死,Dex在文中也提醒读者对这类数据保持警惕。但方向感是清楚的:生成代码变快了,评审和验收却没跟上。
更隐蔽的一层限制在于模型本身。哪怕是最新的frontier benchmark,模型也能考出高分,但基准测试考的是单次任务完成度,不是在一个背着十年历史包袱、有一堆隐性约束的生产代码库里长期维护的能力。Dex援引开发者Addy Osmani的说法:一个人自己vibe coding写个只有十几个人会用的小工具,和一个团队维护还要再撑一个季度的十年企业系统,两者几乎没有共同的约束条件——行业里流行的建议,常常是这两拨人在互相教对方怎么活。就连“agent自己写出来的代码库”,维护到三到六个月后也会开始变慢,加新功能的方式必须跟着变。
对工程负责人而言,预算该往前挪
这篇文章真正想劝的人,是负责AI编程工具采购和交付流程的工程负责人:不能因为代码生成提速就顺手砍掉评审预算。2022年那套流程里,团队提前花一小时对齐需求和架构,能把原本六小时的评审压缩到二十分钟——这个道理AI时代没有变,只是省下来的时间,得重新投进规划、架构评审和验收标准,而不是拿去多跑几个循环。
循环再多,也补不上没做的需求对齐
对维护复杂生产系统、拥有历史约束代码库的团队来说,harness engineering(评审机器人、adversarial review、linter堆栈)仍是必要条件,但离“全自动交付、不用人读代码”还差着一整层模型能力和人工判断——这一层,目前没有任何公司拿出决定性数据证明已经补齐。