前Google可读性计划负责人Titus Winters：AI对工程的价值不在加速旧工作而在启动新项目

Titus Winters在播客中描述了一个他在多家公司的工程师同行中反复听到的图景：与一年前相比，代码产出量大幅上升，故障率也上升了大约30%，但交付的功能数量基本没有变化。如果按传统的开发者生产力指标来解读，这看起来像是原地踏步——甚至因为故障上升而偏向负面。

Winters认为问题出在指标本身。他说，人们关心错了东西。传统的生产力衡量——功能交付数、迭代速度、代码行数——度量的是在已知工作类型上的吞吐量。AI的独特贡献可能不在这个维度上，而在于降低了项目的可行性门槛：让那些以前因为人力成本、复杂度或时间跨度而不值得启动的项目变得现实。

这个判断有他自己的工程经历作为底色。2010年，他加入Google后不久参与了一次覆盖约2.5亿行C++代码的大规模重构，当时整个代码库由约一万名工程师维护，而执行重构的团队只有十二人。没有大语言模型，他们靠MapReduce解析整个代码库的抽象语法树、匹配调用模式、自动生成编辑、分片分发、封锁旧模式、最后删除旧API。这套专用工具链后来催生了clang-format。Winters的类比逻辑是：让十二个人完成一项涉及2.5亿行代码的迁移，靠的不是让每个人写得更快，而是工具链改变了这件事的可行性边界。

Winters把同样的逻辑投射到AI上：它的价值不在于让同一个工程师用更短时间写出同样的代码，而在于让一个团队能够启动以前根本不会考虑的项目——也许是跨整个代码库的架构迁移，也许是一个以前因维护成本过高而被否决的系统设计。从故障率角度看，AI目前可能是负面的；但从可行性角度看，它打开了新的工作空间。

这个论点的边界也值得注意。首先，'以前不可行'是一个反事实判断——很难严格证明某个项目在没有AI的情况下确实不会被尝试。其次，Winters引用的30%故障上升来自他与同行工程师的非正式对话，不是受控测量或公开数据集。他本人也承认，仅从故障角度看，这项技术目前可能是负面的。他的乐观建立在另一个尚未被量化的维度上：那些因AI而启动的、以前不存在的项目。

Winters的建议不是放弃度量，而是改变提问方式。与其问'AI让同样的工作快了多少'，不如问'AI让哪些以前不会做的事情变成了可能'。前者容易量化但可能遮蔽了真正的变化；后者更难测量但可能指向AI对软件工程更深层的影响。