Why Software Factories Fail

副标题：harness engineering is not enough。熄灯工厂（没人读代码）为什么行不通——因为再多的循环也抬不动天花板：好设计没有快速的 oracle，RL 奖励不到它。

作者: Dex (HumanLayer) 2026-07-24 原文 ↗ Keynote 视频 ↗

一句话论点

再多的 harness 工程或循环叠满，也无法解决一个本质上是模型训练的问题。harness 能抬高地板，但抬不动天花板。

工厂的演进：从"有人实现"到"无人读码"

"软件工厂"指把意图变成上线代码的端到端流水线。半个多世纪里，每一代都在试图把人从环里挤出去——直到熄灯工厂把最后那个人（代码审查者）也去掉。

熄灯工厂把审查者也挤掉，工作退化成"要烧开多少片海洋"。但 Dex 论证：这条路在当下行不通。

它正在出问题：质量在崩

自 2025 年底大家集体上车 AI coding 工具，Faros AI 的报告显示：PR 审查质量大幅下滑，事故和每开发者 bug 飙升。这是相关信号，方向上"感觉是对的"。

Faros: 合并前代码质量下降——审查评论 +25%、更长 +22.7%、31.3% 的 PR 完全跳过审查 — 合并前：审查评论 +25%、更长 +22.7%、**31.3% 的 PR 完全跳过审查**。

Faros: 生产质量下降——每 PR 事故 +242.7%、月事故 +57.9%、每开发者 bug +54% — 生产环境：每 PR 事故 **+242.7%**、月事故 +57.9%、每开发者 bug +54%。

为什么：harness 抬地板，不抬天花板

很多人说效果不好是"技能问题"——多花 token、别读代码就行。Dex 的反论：这不是 skill issue，而是模型训练问题。更多 review agent 和 token 能抓住低级错误（抬高地板），但天花板由 RL 教会模型的东西决定，而好设计是还不知道怎么教的东西。

harness 工程的所有努力（左）都在抬地板；天花板（右）由训练决定，而好设计还没有可靠的快速评分器。

机制：RL 的奖励信号只有一个维度

Claude Code 一年从零做到 ~$4-9B 营收，赢在第一家在 harness 内 RL 模型——用即将发布的同一套工具训练。但让模型更擅长写代码的循环，瓶颈不在循环，而在"评分"——它往往任性到只有一个维度。

SWE-bench 的奖励只有 FAIL_TO_PASS + PASS_TO_PASS：修好了吗？没弄坏别的吗？——对侵蚀可维护性，零惩罚。

SWE-bench 怎么给一条轨迹打分

以一个真实的 fastlane bug 为例。模型看不到 golden patch 或评分用的 test patch：

SWE-bench 单任务评分流程：bug report + base commit → agent 写 patch → 扔掉测试改动 → 补上 benchmark test patch → 跑整套 — 模型从 base commit 出发，只看到 bug report。写完 patch 后，评分器**扔掉它对测试文件的所有改动**（防作弊），补上 benchmark 的 test patch，跑整套——都过才得 1。

关键推论

模型怎么到达正确答案不重要。测试过了就赢，但对代码库可维护性的侵蚀——到处套 try-catch、lazy 类型转换、复制粘贴——没有任何惩罚。

锋利的一刀：时间尺度的错配

这是整件事最反直觉的地方。测试反馈是秒级的，所以 RL 能跑几百万个循环。但坏架构的代价函数以月、年计——它第一次显现，是在有人为改一行而打开那个文件的时候。而那个事故，无法 backprop 回导致它的决策。

测试给你秒级反馈；坏架构的代价以周/月/年计。这个错配意味着可维护性进不了 RL 的奖励。

死循环

如果一个模型能可靠地分辨代码好坏，它可能一开始就写出好版本了。但可维护性没有快速的 oracle，所以我们没法在 RL 里奖励它——于是模型继续产出测试能过、却悄悄侵蚀代码库的代码。

前沿在逼近，但别押注

第一批试图给"可维护性"打分（而非停在 pass/fail）的 benchmark 正在出现，但 Dex 仍不打算把代码库押在任何一个上面——judge 模型只能走到这一步。

Benchmark	做法	局限
SWE-Marathon	~400 小时大任务（"克隆整个 Excel"），复合奖励通道	仍未直接评设计
DeepSWE	构造现实里从未建过的大任务	解决污染，不解决质量
Frontier Code	mutation testing + judge model 审查 diff 代码质量规则	judge 模型只能走到这

mutation testing 的逻辑：如果模型写的"新测试"在修复前的代码上也能通过，那这个测试就是废的——没有真正验证任何东西。

解药：重新点亮，四阶段前置规划

不是放弃 AI，而是接受约束、把代码审查放回去、用前置规划把审查成本压下来。每一层都是一次本会在最贵的时刻（code review）才做的隐含决策。30 分钟规划省下几小时审查。

大多数模型偏爱"水平计划"（数据库→服务→API→前端），走的过程没法触碰方案。垂直切片反过来：API 契约+mock→前端→接服务→数据库，每一步都测试/迭代。

水平 vs 垂直：每步能不能“碰一下”

这是“垂直切片”最容易混淆的一点。区别不在“建什么”，而在落地节奏——是按技术栈一层层铺完再拼，还是先打通一条端到端最小路径、每步都能验证：

左：按层铺（DB→服务→API→前端），每一层写完都没法独立验证。右：先打通一条贯穿所有层的端到端最小路径（①API+mock→②前端→③服务→④DB），每一步都能 curl 或点浏览器确认没跑偏，再逐步加厚。

实例：给笔记加“标签”，走一遍四阶段

用同一个功能走一遍，体会每层到底“对齐了什么”——每一层都是一次本会在 review 时才被迫做的决策，提前到写代码之前。

① 产品评审 — 不碰技术，只钉用户视角：

问题：笔记太多，找不到
成功标准：3 秒内用标签筛出相关笔记

别描述——直接画 mockup。一张粗糙的 HTML 截图（笔记列表 + 彩色标签 chip + 顶部筛选栏），比三段文字更能终结争论。易犯的错：一不留神漂进“用什么数据库”——记下来留给后面，回到用户看到的东西。

② 系统架构 — 组件之间怎么连，不进代码细节：

UI → API → NoteService → Store     （POST → addTag → insert → 201 Tag 返回）

POST /api/notes/:id/tags  { name: string } → { tag: Tag }

CREATE TABLE tag (
  id         BIGSERIAL PRIMARY KEY,
  name       TEXT NOT NULL,
  note_id    BIGINT REFERENCES note(id),
  created_at TIMESTAMPTZ DEFAULT now()
)

③ 程序设计 — 最被低估：代码的形状（架构图管不到、agent 最易翻车处）：

# 调用栈（diff 突出“变了什么”）
noteEditor
+  handleAddTag
+    TagClient.add(noteId, name)   → POST /notes/:id/tags
+    refreshTagChips

# 文件树
+ src/note/tag-client.ts      # 新 — 封装标签 API
~ src/note/note-editor.ts     # 改 — 接入标签输入框

# 类型与签名
interface Tag { id: TagId; name: string; noteId: NoteId }
addTag(noteId: NoteId, name: string) -> TagId

④ 垂直切片 · 先打通端到端最小路径，每步能验证

① API 契约 + 假数据   ✅ curl 能打出标签
② 前端消费假数据      ✅ 浏览器能看到标签 chip
③ 接到真 NoteService
④ 接到真数据库

约束理论（2026 版）

与其拼命想 10-100x 加速、说服自己代码质量不再重要，不如拥抱约束、安全地 2-3x 加速

摸清约束 —— 和模型多打交道，建立直觉
在约束的竞技场里优化 —— 别让它做做不到的事
寻求杠杆 —— 人类精力花在规划/架构/程序设计
读代码 —— the dang code

核心洞察

洞察	含义
harness 抬地板，不抬天花板	天花板是 RL 教的，好设计还教不会
测试通过 ≠ 代码好	秒级反馈 vs 月级代价的时间错配
熄灯工厂必然失败	没有可靠验证器，代码库 3-6 个月开始崩坏
前置对齐是跨时代杠杆	现在要下沉到"程序设计"（类型/签名）这一层
垂直切片 > 水平计划	过程中可重新引导，而非在 2000 行另一头发现灾难

来源：Why Software Factories Fail — Dex (HumanLayer)，基于 AI Engineer World's Fair 2026 keynote。Faros AI 数据图与 SWE-bench 评分流程图来自原文。