肯特·贝克：增强式编程意味着，你不必再因为实现成本而拒绝一个想法。

肯特·贝克：这位“精灵”并不擅长管理软件的未来。

肯特·贝克：它与使命是否得到推进没有关系。

一边是代码越来越便宜，另一边是团队仍然不知道该不该合并、能不能上线、出了问题如何回滚。代码生成速度已经发生变化，软件工程里那些费时间的部分却没有一起消失。

肯特·贝克在演讲中举了一个典型的考核场景：AI生成了20万行代码，听起来很惊人。但这只是投入和产出的数字，不能说明用户有没有用上功能，也不能说明业务或任务向前走了多少。20万行并不是一次基准测试结果，而是他用来质疑“把代码量当生产力”的例子。

备注：极限编程（XP）创始人、测试驱动开发（TDD）先驱肯特·贝克在美国纳什维尔举行的Prodacity 2026上发表了这场演讲。演讲讨论的是AI参与开发之后，软件工艺、迭代方式和团队考核应该怎样调整。

以下为演讲内容，我们进行了翻译与整理。

能生成代码，还不能替代工程判断

肯特·贝克把大模型称为“genie”，也就是会满足愿望的精灵。这个称呼里既有喜欢，也有提防。他很享受与AI编程，因为过去受限于个人技术栈、很难动手的项目，现在可以迅速试验。但精灵交付的东西经常只停在“看起来像完成了”。

在他的文章《Genie Tarpit》中，他这样描述问题：

肯特·贝克：“Complexity piles on complexity until even the genie can't pretend to make progress any more.”

肯特·贝克：复杂度会一层层堆上去，直到连这位“精灵”也无法继续假装项目还在推进。

这里的风险并不抽象。一个Agent可以在几分钟内补齐接口、数据库访问和前端页面，测试也可能显示为绿色。可一旦需求涉及旧数据迁移、权限继承、支付幂等或跨版本兼容，语法正确只能说明程序通过了很低的一道门槛。

比如让Agent给结算系统增加优惠券功能，它可以顺手改完价格计算、订单字段和展示页面。Diff看起来完整，单元测试也能通过。但生产库里已有订单该怎么处理？重复回调会不会二次抵扣？老版本客户端拿到新字段会不会崩溃？这些问题很难靠“再生成一次”自动解决。

开发者的工作因此向结果判断移动：先定义什么叫完成，再检查模型有没有绕过约束。测试需要覆盖行为，而不是只覆盖AI刚刚写出的实现。

Kent Beck指出，AI很擅长生成看起来可信的代码，但“像完成”不等于真的可用

每个新功能都在消耗代码库的下一步

代码库刚建立时，可选方案很多。第一个功能落地后，接口、数据结构和兼容策略开始固定。后续功能越多，能低成本改变方向的空间通常越小。Kent Beck把前者称为Features，把后者称为Futures。

肯特·贝克：“Features—what the code does now.”

肯特·贝克：Features指代码现在能够完成什么。

Futures则是代码下一步还能变成什么。它不是一个待办列表，而是系统保留下来的选择权：一个字段能否安全迁移，一条接口能否保持兼容，一个模块能否拆开重写，一次失败发布能否在十分钟内撤回。

AI会放大这组矛盾。过去，一个团队可能需要几年才会把系统堆到“改一处坏三处”；现在，一个人连续接受Agent生成的改动，也可能在一周内抵达同样的位置。功能增长得很快，结构却没有时间消化变化。

肯特·贝克给出的做法很朴素：完成一个功能后停一下。消除重复，补上可观察性，检查命名和边界，必要时把刚写完的实现扔掉再做一次。短期看，这些动作没有新增需求；长期看，它们是在买回下一次修改的空间。

这套方法也改变了代码评审的目标。评审者不能只问“需求有没有实现”，还要看这次提交锁死了哪些决定：是否把第三方返回结构直接传进核心域模型，是否让数据库字段同时承担多个含义，是否把权限判断散落到各个入口。Futures往往就藏在这些小地方。

红线表示连续增加功能后，系统可修改空间逐步耗尽；绿线表示在功能之间主动整理结构

开发者的工作移到变更链路上

在《Beyond the IDE》中，Kent Beck把新的开发流程概括为：

肯特·贝克：“Intention for feature or structure → genie makes changes → review changes.”

肯特·贝克：先表达功能或结构上的意图，再由AI完成修改，随后审查这些变化。

过去，IDE主要优化的是中间那一段：查找文件、输入代码、补全语法、运行测试。Agent把“动手修改”压缩以后，耗时会转移到意图拆分和结果核验。开发者不必逐行敲出实现，但要持续决定下一步应该让系统发生多大的变化。

这不是把程序员改造成“提示词操作员”。

一个提示词结束后，开发工作往往才进入密集区。模型不知道团队能承受多大的迁移窗口，也不知道某个看似多余的兼容分支正在保护哪一批老客户。上下文可以交给模型读取，责任仍然落在人和团队的流程上。

AI负责生成变更后，开发者的时间转向限定边界、审查Diff、验证风险和观察发布结果

一次写完的Spec，只是换了外套的瀑布

Agent能力增强后，Spec-driven development重新流行起来。理想流程是先写一份足够完整的规格，再让模型一次生成实现。如果结果有问题，就继续扩充Spec，直到软件符合要求。

Kent Beck认为，这套思路很容易回到瀑布模型：把关键决定提前锁定，默认后面的开发只是执行。问题在于，软件上线之后出现的用户行为、数据分布和运行故障，会反过来改变前面的决定。

肯特·贝克：“Spec-driven development doesn't work if you're playing The Compounding Game.”

肯特·贝克：如果团队在做一个需要持续积累价值的长期项目，单靠Spec驱动并不奏效。

演讲中，他对这种流程的评价更直接：

肯特·贝克：“That's exactly waterfall development.”

肯特·贝克：这正是瀑布式开发。

一次性并非完全不可用。处理一份临时数据、制作不会再维护的小工具，目标清楚，结束点也清楚，让Agent一次完成很合理。可服务已经承载用户、数据库不能随意重建、旧客户端仍在访问时，团队需要小步部署、观察和迁移。Spec必须跟着反馈变化。

肯特·贝克还谈到使用Lean进行形式化证明的体验。形式化方法能够证明模型中的某些性质，却不能自动消除形式化规格与真实实现之间的距离。从规格落到C、C++或ARM64代码，仍然要处理运行环境、工具链和实现偏差。对长期系统来说，证明完成也不代表以后不再变化。

一次生成适合结束点明确的任务；长期系统需要部署、观察和调整形成闭环

代码量和PR数，离任务结果还有两层

演讲最后，肯特·贝克把软件工作的衡量方式画成一条链：Effort、Output、Outcome、Mission。

Effort是投入，例如工程师时间、模型调用次数和Token成本；Output是团队交付的东西，例如代码、PR和功能；Outcome是用户行为发生了什么变化；Mission才是组织想完成的任务。

AI最容易推高前两项。它可以在很短时间内生成大量代码，也能让仓库里出现更多提交。如果团队把代码行数或PR数量设成目标，开发者会自然地优化这些数字：拆出更多提交，保留更多生成代码，减少看起来“不产出”的重构时间。数字变好，系统未必更可靠。

一个支付团队增加了十个功能，Output很高；如果失败率上升、客服工单增加、用户在收银台退出，Outcome就在倒退。政府软件也是一样。交付页面数量不能说明任务是否更快完成，最终要看一线人员是否减少等待、关键流程是否缩短、异常能否更早发现。

这也意味着，AI生产力不能只在代码仓库里衡量。团队至少要把指标向后移：功能有没有被使用，故障有没有增加，变更失败后多久能恢复，人工处理量是否下降。离Mission越近，归因越难；但离Mission太远，指标又很容易被“做出来”。

Kent Beck将软件工作拆成投入、产出、用户结果和使命四层，代码量只位于前半段

评论区争论：Futures只是技术债换了个名字吗

评论区里，获得较多点赞的一条留言认为，写代码从来不是瓶颈，理解代码才是。

这条评论补上了演讲的现实语境：生成能力提升以后，理解并没有随之自动扩容。

也有人不买账。一条评论把整场演讲概括为“给技术债换了个Futures的新名字”。这个质疑有道理，两者确实在描述代码结构对后续开发的影响。但“技术债”通常回头看已经形成的负担，Futures强调的是眼前还剩多少选择，以及团队能否主动把选择买回来。

名称是否新颖并不影响工程判断。只要一次提交让下一次变化更困难，团队就需要把这部分成本放进评审；如果整理结构只满足个人审美，却没有降低修改、测试或发布风险，也不必为了“工艺”无限延期。

一位网友认为理解代码才是瓶颈，另一位网友质疑Futures只是技术债换名

写在最后

AI参与开发以后，最先变便宜的是代码生成。需求边界、架构取舍、数据迁移、权限核对、上线观察和故障恢复，并不会因为模型能写函数而自动完成。开发者少写一些代码，不等于工作减少；很多时间会移到决定改什么、验证改得对不对，以及判断这次交付是否值得。

团队可以从现有交付链路动手：先控制Agent一次修改的范围，再把Diff审查和行为测试做扎实，接着补齐日志、灰度与回滚，最后把考核从代码量和PR数移向用户结果。生成速度已经足够快，下一步要解决的是，团队能不能在这股速度里继续看清系统。

参考链接：

https://www.youtube.com/watch?v=F8fBgDCf2Y4

——好文链接——

AI不是新物种，而是软件！黄仁勋：如果产品不安全，就别发布，与其争论末日，不如解决失控风险

程序员的基本功重新变得重要！Total TypeScript作者：别把整个需求塞给Agent，上下文一长，模型就会走进“变笨区”

程序员最大的风险不是被AI替代，而是“认知投降”！Chrome前负责人：代码写完了，人却看不懂系统