AI 写了 75% 的代码，工程师却越来越慌：“黑灯软件工厂”的问题不在 harness，而在模型本身
内容提要
Dex Horthy指出，AI编程模型因训练方式缺陷，无法学会代码可维护性，导致“黑灯软件工厂”失败。他建议重开人工评审，用AI加速前置对齐流程，以提升代码质量。
延伸解读
“黑灯工厂”的代价：数据与亲历
Faros AI 报告显示，大规模采用 AI 编程后，PR 评审质量下降、无评审合并比例上升，线上事故和人均 bug 数同步走高。Dex Horthy 亲历数月“黑灯”实验后，团队被“AI 味”代码淹没，不得不回头排查三个月无人读过的代码库。这些迹象表明，完全依赖自动化而放弃人工评审，短期内可能提速，但长期会积累技术债务，最终拖慢交付。
模型训练的结构性缺陷
当前编程模型的强化学习以“测试是否通过”为奖励信号，无法惩罚糟糕的架构设计，因为可维护性的代价往往数月后才显现。Dex 指出，基准测试如 SWE-bench 的任务时长仅十几分钟，奖励二元，模型只会“让测试变绿”，而不关心代码是否在应付了事。这导致模型天生学不会“可维护性”，再精巧的 harness 也无法弥补训练层面的根本问题。
解药：重开评审，前置对齐
Dex 建议用 AI 加速产品评审、系统架构、程序设计和垂直切片四步前置对齐，而非完全跳过人工评审。他认为，烂 PR 太多才是评审负担的根源，而前期三十分钟的规划能省下数小时返工。通过 AI 辅助对齐，评审更快、编码更快，但人依然逐行读代码，保持对代码的实质所有权。
Q&A
什么是“黑灯软件工厂”？
“黑灯软件工厂”是指完全自动化、无需人工干预的软件开发流程，由Dan Shapiro提出。在这种模式下，代码评审被取消，团队依赖测试、监控和灰度发布来保证质量，线上事故直接路由回工厂自动生成补丁，用户反馈也直接进入队列。
为什么Dex Horthy认为“黑灯软件工厂”走不通？
Dex Horthy认为，当前编程模型在训练时只关注测试是否通过，无法学会代码可维护性，因此无法在没有人类持续介入的情况下维护和改善代码库质量。他通过自身实验发现，长期运行黑灯工厂会导致代码库质量下降，线上事故增多，最终不得不重新引入人工评审。
编程模型在训练时如何评估代码质量？
编程模型在训练时使用强化学习，奖励信号主要基于测试是否通过。例如，在SWE-bench Multilingual基准中，模型生成的补丁会应用标准测试补丁，如果新旧测试都通过则获得奖励，否则不获得。这种机制无法惩罚糟糕的架构设计，因为可维护性问题往往在数月甚至数年后才显现。
为什么Claude Code能成为现象级产品？
Claude Code成功的关键在于，模型厂商将模型与最终分发的harness绑定在一起训练，使模型从训练阶段就熟悉工具调用和多步任务解决。相比之下，之前的Aider、CodeBuff等工具只是将模型适配到外部工具链，缺乏这种协同训练。
Dex Horthy提出的“前置对齐四步法”是什么？
前置对齐四步法包括：1. 产品评审：明确问题和期望行为；2. 系统架构：确定组件契约、数据模型和约束；3. 程序设计：细化类型定义、方法签名和调用栈；4. 垂直切片：确定实现顺序和跨仓库协同。这套流程旨在通过前期规划减少后期返工，提高代码质量。
为什么说“烂PR太多”是评审负担的根源？
Dex Horthy认为，如果被大量PR淹没，真正的问题不是PR数量多，而是烂PR太多。一个对齐良好的PR读起来是享受，因为评审者只需确认方案；而烂PR即使只有20%的返工，也会给评审者和提交者带来巨大的情绪和认知负担。
当前有哪些下一代评测基准在探索评估代码可维护性？
下一代评测基准包括：SWE Marathon（Abundant AI）设计长达400小时的任务，如克隆Excel；DeepSuite（Data Curve）选择未实现的功能以避免数据污染；Frontier Code（Cognition）面向多PR任务，引入裁判模型和测试失败惩罚机制。这些基准试图更全面地评估代码质量。
