Why Software Factories Fail

核心论点

industrie 全行业都在搞"关灯工厂"——人不读代码、不写代码，AI 全自动生成。StrongDM、OpenAI Symphony、Ramp、Stripe、Brex 都在宣传"75% 的代码由 agent 生成"。但 Faros AI 数据显示：自从用了 AI 编程，PR 评审质量暴跌、事故率 +242.7%、人均 bug +54%。Matt Pocock 的判断：代码库正在以前所未有的速度崩坏。

为什么模型不能自己维护代码质量

问题不在工具，在模型训练层面。SWE-bench 等 benchmark 的评分标准只有两条：修了要修的 bug（FAIL_TO_PASS），没破坏别的东西（PASS_TO_PASS）。没有任何机制惩罚代码可维护性的退化。所以模型到处加 try-catch、暴力类型转换——测试通过但代码质量烂。

更深的问题是：测试秒级反馈，但烂架构的代价是几周几个月后才暴露——没法 backprop 到当初那个决策。RL 训练中可维护性没有快速可靠的判据（oracle），所以没法奖励好设计。

作者给的实际方案：4 阶段人机协作

• Product Review：先写清楚要做什么、为什么做，粗略 HTML 原型定争论
• System Architecture：API 契约、数据模型、时序图，人 agent 之间对齐
• Program Design（最被忽视）：类型签名、文件树 diff、关键函数签名——这些是 agent 最容易搞错但最便宜的纠偏环节
• Vertical Slices：垂直切（每层端到端跑通），不要水平切（DB→Service→API→前端），因为水平切中途没法验证

分布：~40% 任务直接 oneshot；中型任务合并 product+system；大型任务才走全流程。30 分钟规划省几小时评审。

适合收藏的原因

• 不卖药：作者自己公司也试过 3 个月关灯工厂，失败了，含着泪重写——用亲身经历说话
• 根因分析到位：不是"你用不好"，是 RL 训练的 reward 结构没有可维护性信号
• benchmark 现状的清醒认知：现有 benchmark 没法衡量可维护性，所以 benchmark 分数提升 ≠ 代码质量提升
• 实操方案：不是空谈哲学，4 阶段方法可以直接用在团队里
• 前沿信号：点名了 SWE-Marathon、DeepSWE、Frontier Code 等试图解决可维护性评测的新方向

关联内容

本文基于作者在 AI Engineer World's Fair 2026 的主题演讲。同一 repo 还有另一篇 ace-fca.md（Advanced Context Engineering for Coding Agents），是他的另一个核心演讲。配套 YouTube 视频累计播放量超百万。

分类标签