大数跨境

精灵不是问题,人类才是瓶颈——与 Kent Beck商榷「AI时代的软件工程」

精灵不是问题,人类才是瓶颈——与 Kent Beck商榷「AI时代的软件工程」 软件工程3.0时代
2026-10-03
15
导读:如果未来可以被低成本地重新生成,为什么还要害怕烧掉它?

2026年8月,Rise8在纳什维尔举办了 Prodacity 2026培训活动。极限编程创始人、敏捷宣言首位签署者Kent Beck发表了题为“Software Engineering in the Age of AI”的演讲。同台还有美国太空司令部司令Stephen N. Whiting将军等政府与行业领袖。

(详见:https://www.rise8.us/videos/kent-beck-software-engineering-in-the-age-of-ai)

Beck在这场演讲中阐述了他对AI时代软件工程的核心判断。他称 AI为“精灵”(genie),因为它实现你的愿望,却给你不想要的东西。他的核心框架是“功能 vs 未来”(features vs futures):每一个功能都会烧掉一些未来改变的选择,因此需要在功能之间停下来巩固。演讲结尾,他展示了一个修订后的“努力—产出—成果—使命”链条,并引用古德哈特定律批评以代码行数衡量生产力的做法。

值得注意的是,Beck并非 AI的反对者。他在自己的开发实践中积极使用 AI,称之为“最有趣的编程体验”。他提出的不是“AI不能用”,而是“AI需要被人类判断驾驭”。这个出发点值得尊重。问题在于,他由此推出的许多具体结论,正在被工程现实超越。

一、Beck的主要观点

综合演讲内容,Beck的核心观点可归纳为以下七点:

  1. “AI不比人类更会编码”:AI生成的 C编译器“hello world 都跑不起来”,只是“C编译器-ish”,看似合理不等于能工作。

  2. “全自主总是脱轨”:每次尝试完全自主的暗工厂,它总是脱轨,脱轨过程还很有娱乐性。

  3. “功能消耗未来”:每加一个功能就烧掉一些未来改变的选择,所以必须在功能之间停下来巩固、重构、增加可选性。

  4. “技艺已经过时”:仔细命名、分解、缩进这些过去表达技艺的活动,杠杆作用已经大幅下降,“三本书都该扔了”。

  5. “规格驱动开发就是瀑布”:写好规格让 AI生成软件,本质上是瀑布开发,而瀑布从未成功过。

  6. “代码行数不是使命”:代码行数、PR数、token量不能衡量使命。古德哈特定律说,当一个度量变成目标,它就不再是好度量。

  7.  “人类必须坐在驾驶座上”:增强开发仍然是人类过程,人类必须在每个功能之间喘气、擦刀、验证、重构。


二、哪些观点显然是对的

在与Beck商榷其主要观点之前,必须承认 Beck的许多判断有坚实的工程基础:

AI生成代码必须验证。一项覆盖 4,442个 Java任务的研究发现,所有被评估的LLM都产生了缺陷,包括硬编码密码、路径遍历漏洞和 XXE注入。另一项研究发现LLM在框架约束下生成漏洞程序的比率高达 18%到 50%。Carlini本人也承认,“程序员部署他们从未亲自验证过的软件,是一个真实的担忧”。

代码行数不是价值度量。古德哈特定律在这里完全适用。AI能生成 20万行代码,和使命是否推进无关。这一点 Beck说得对,而且说得漂亮。

完全无验证的全自主在复杂系统中风险极高。大规模研究发现,Agent编写的代码在后续开发中导致更多下游失败,任务解决率下降 1.0到 13.0个百分点。

迭代优于一次性规约(Spec)。RoycE的原始论文确实指出瀑布不成立,因为后期决策会影响前期决策。大用户量、长期运行的系统必须迭代,这一点没有争议。

这些共识是 Beck演讲中最稳健的部分。但 Beck从这些共识出发,推出了七个过度外推的结论,值得商榷。

三、值得商榷的七个观点

1. “AI不比人类更会编码”——一个已被超越的判断

Beck讽刺说,AI生成的 C编译器“hello world 都跑不起来”,只是“C编译器-ish”。

AnthropiC研究员Nicholas Carlini用16个Claude Opus 4.6智能体在共享仓库中并行协作,近2,000次会话、约 $20,000成本,产出了10万行 Rust代码的 C编译器,能在x86、ARM、RISC-V上构建Linux 6.9内核,通过GCC torture测试集99%,成功编译了PostgreSQL、SQLite、Redis、FFmpeg和QEMU,还能运行Doom。

这已经不是“hello world 都跑不起来”。从“hello world 都跑不起来”到“编译 Linux 内核”,这是工程成熟度的差异,不是能力有无的差异。编译器质量确实还不及人类专家——Carlini本人也承认——但这是关于当前局限的判断,而非关于能力边界的判断。

更关键的是,Beck的比较基准是“人类程序员”。但人类程序员是什么水平?大量生产代码充满未处理边界、隐藏耦合、复制粘贴和没人敢改的模块。人类之所以看起来“可信”,不是因为人类代码更正确,而是因为我们学会了在人类代码周围建立组织性防御:代码评审、测试、监控、事故复盘。AI代码不是更不可信,它只是还没有被嵌入同样的制度信任结构。Carlini的实验中,高质量测试正是让 16个智能体保持正轨的核心机制——不是人类的逐行审查,而是可执行、可复现的验证管道。

2. “全自主总是脱轨”——Harness工程正在改写这个判断

Beck说“每次尝试完全自主的暗工厂,它总是脱轨”。

Harness-of-Harness框架(见论文:https://arxiv.org/pdf/2609.01481)将自主编码 Agent 的执行组织为规划—编码—测试的迭代循环。在 Codex/GPT-5.5、OpenCode/DeepSeek-V4-Pro、Pi/MiniMax-M3 三组配对测试中,HoH 平均相对增益 52.25%,最大增益 82.86%。在一次超过 70次迭代的多日部署中,HoH自主开发了一款具有连贯剧情、完整核心机制和人类可玩体验的第一人称射击游戏。

OpenAI的 Harness Engineering 实验更具说服力:3 名工程师、5 个月、1,500 个 PR、100 万行代码,没有一行由人类手写,没有一行经过人工代码审查。团队构建了名为 Symphony的编排系统,将项目管理工具变成编码 Agent的控制平面,完全移除了人类在代码审查和合并环节中的参与。

Beck把“缺乏 Harness 工程的全自主开发会脱轨”等同于“全自主开发必然脱轨”。这是两个完全不同的命题。脱轨不是因为自主本身,而是因为 Harness设计得不够好。把 Harness问题归因于“没有人类在场”,等于把工程问题误诊为原则问题。

3. 功能 vs 未来:一个前 AI时代的稀缺性思维

Beck的核心框架是“功能 vs 未来”:每加一个功能,就烧掉一些未来改变的选择。

但 AI正在改变这个前提。

Nubank将数百万行代码的单体架构迁移至子模块,通过 Devin Agent实现了 12倍的工程效率提升和超过 20倍的成本节约。Bun的创始人 Jarred Sumner用 Claude AI将原本需要 4年开发的 JavaScript运行时底层重写压缩至两周,成本从 $300万降至约 $16.5万。JetBrains为 Rider集成 AI Agent到重构引擎后,每个任务的中位成本从 $0.33降至 $0.12,token 消耗量减半。

Beck说 “我一个人一周就能搞出无法修改的烂摊子”。这是真的。但同样一个人,用同样强度的 Agent辅助,也可能在一周内把这个烂摊子重写三遍。问题不在于功能烧掉了未来,而在于你的工程流程是否把重写和重构变成了低成本操作。如果是,那么“功能 vs 未来” 的权衡就不再是一个零和博弈。

4. “技艺过时了”——技艺被民主化了,而非消亡

Beck说:他的三本技艺书都该扔了。

对的部分:过去那种以人类阅读体验为中心的代码美学,确实不再是最高优先级。错的部分:技艺没有消失,它只是从手工编码行为转移到了系统设计、验证策略、任务分解和 Harness设计上。

Chris Lattner——Swift、LLVM和 Clang的创造者——在审阅 Claude C编译器代码后评价:“好的软件依赖于判断、沟通和清晰的抽象。AI放大了这一点。”、“AI编码是实现的自动化,因此设计和治理变得更加重要。”

真正的技艺从来不是慢,而是知道在哪里慢、在哪里快。SNCF Connect & Tech 的 SDD实验证明,将两个月的前期投入放在产品与规格上,配合三周的 AI实现,可以在加速交付的同时产出高质量文档资产,用于新成员入职和测试维护。这是技艺,不是技艺的消亡。

5. “规约驱动开发就是瀑布”——忽略了反馈循环的质变

Beck把“写好规约,AI生成软件”类比为瀑布。

SNCF Connect & Tech 的实验恰好反驳了这个类比。他们的 SDD 流程分为两个阶段:前两周由产品负责人和开发者结对隔离工作,在生成任何代码之前精炼产品愿景并构建文档;后三周完成实现。结果是可以加速交付,同时产出高质量的文档遗产。

Beck把 SDD 等同于“写一个完美规约然后祈祷”的瀑布,忽略了一个关键区别:瀑布的失败是因为需求Spec无法被执行和验证,而 AI可以把Spec变成可运行、可测试、可迭代的产物。这不是瀑布,这是把迭代压缩到人类感知不到的程度。形式化方法到实现的鸿沟也没有 Beck说的那么大。ReDeFo等多智能体框架正在用形式化规格弥合自然语言需求与精确可执行代码之间的差距。Intent Formalization已被列为 AI Agent时代可靠编码的核心挑战,而不是无解难题。

6. 代码行数不是使命,但“使命”也不是度量

Beck对古德哈特定律的引用很漂亮。

但“使命”本身也不能被度量。这正是问题所在。Beck批评早期度量扭曲系统,然后诉诸一个更晚、更难归因、更模糊的“使命”。这在管理上不可操作。你可以用使命讲故事、激励团队,但你无法用使命做资源分配、优先级排序和绩效判断。

更诚实的做法是:承认所有度量都是局部的、可被博弈的,然后设计多层度量加上定性判断和快速纠偏机制。OpenAI的 Harness Engineering 团队就是这样做的:他们跟踪 token消耗量、PR数量和代码行数,但把这些作为系统健康指标而非目标本身。真正的质量信号来自测试通过率、回滚率和端到端任务完成率。用不可证伪的“使命”否定一切可操作度量的价值,在管理上是不可操作的。

7. “人类必须坐在驾驶座上”——人类应该往上走,而非留在环路中

Beck的整场演讲,本质上是在说:AI太快了,人类跟不上,所以我们要慢下来。

但历史给我们的教训恰恰相反:当工具速度超过人类速度时,正确的反应不是让工具减速,而是重新设计人类在环路中的位置。

OpenAI的工程师在 Harness Engineering实验中,角色从代码生产者转变为“环境构建者和系统设计者”。SNCF Connect & Tech的开发者变成了“Agent的指挥家”。Symphony编排系统的存在,正是因为人类不需要逐行审查代码,而需要定义规则、约束边界、审核异常。

Beck说“增强开发仍然是人类过程”。但如果“人类过程”意味着人类必须坐在每个功能之间喘气、擦刀、验证、重构,那这个定义太窄了。增强开发的人类过程可以是:人类定义 Harness、设计验证标准、设定约束边界,然后让 Agent 在结构化的自主循环中持续运行。

结语:别把缰绳当成方向

Kent Beck是一位伟大的工程师,他的“功能 vs 未来” 框架在人类主导的开发时代非常深刻。但他对 AI的判断,带有一种可以理解的防御性:他把自己几十年积累的技艺、节奏和判断力,当成了软件工程的永恒常量,而不是特定技术条件下的历史产物。

精灵不是问题。精灵只是一面镜子,照出我们流程里的浪费、验证里的空洞、度量里的自欺。

真正该问的不是“如何别让精灵烧光你的未来”,而是:如果未来可以被低成本地重新生成,为什么还要害怕烧掉它?

【声明】内容源于网络
0
0
软件工程3.0时代
由于大模型(LLM)正在改变着千行百业,软件工程(SE)更是首当其冲,迎来软件工程3.0新时代:模型驱动研发、模型驱动运维。本公众号将致力于研究SE3.0时代的软件研发新范式、理论与方法,介绍SE3.0时代的工具与实践。
内容 633
粉丝 0
软件工程3.0时代 由于大模型(LLM)正在改变着千行百业,软件工程(SE)更是首当其冲,迎来软件工程3.0新时代:模型驱动研发、模型驱动运维。本公众号将致力于研究SE3.0时代的软件研发新范式、理论与方法,介绍SE3.0时代的工具与实践。
总阅读6.2k
粉丝0
内容633