@TAKAKING22: “制约开发速度的是信任” 借助AI,代码不断增多。但能让团队确信“这个改动可以放心交付”的依据,却没有以同样的速度增加。Kent Beck写道,这种差距会导致项目失败。 独自与AI一起实现……
摘要
Kent Beck 认为,在 AI 时代,制约软件交付的关键因素是信任,而不是代码生成速度;测试和结对编程等极限编程(XP)实践能够建立发布软件所需的信心。他还推广了自己即将开设的付费课程,主题是以优化信任为目标的 AI 辅助开发。
查看缓存全文
缓存时间: 2026/11/01 01:40
『制约开发速度的是信任』
AI让代码不断增加。但团队能够确信“这个改动可以放心交付”的依据,并没有以同样的速度增加。Kent Beck写道,这种差距会导致项目失败。
独自与AI一起推进实现,省去了讨论和评审,看起来就会更快。但如果同事原本能通过这些交流理解改动的意图,并在下次自行做出判断,那么被削减的就不只是等待时间。
以下是详细内容。
・对客户而言,信任能节省时间
Beck将对产品本身的信任,与对产品开发和交付过程的信任区分开来。信任只能一点点建立,崩塌却只需一瞬间。如果客户能够信任产品,就能把原本用于提防故障的时间,用在自己本来想用这款产品完成的事情上。
・测试与结对工作,各自提供不同的依据
Beck认为,极限编程(XP)的各项实践应当相互配合,共同建立信任。有了测试,就能确认代码是否仍然保持预期行为。结对工作,则意味着还有另一个人知道为什么要这样实现。两者都能成为放心迈向下一次改动的理由。
・即使能大规模生成,也要小步验证
AI可以一次生成大规模改动。但改动越大,就越难确信整体都能按预期运行。因此,Beck强调将改动拆小,并逐一验证。他的想法是,在实现过程中稍作停顿,反而能更快地走到可以放心交付的那一步。
・独自快速推进时,哪些东西会变得不可见
Beck强烈反对让所有人都走向独自与AI一起开发的模式。写出来的代码会作为成果留下。相比之下,与他人共同思考时消除的误解,以及通过评审传播的理解,却很难量化。这篇文章也在介绍他本人的一门付费课程,探讨如何在AI时代继续开展这些工作。
如果只有改动的作者能够解释“为什么可以放心发布”,那么团队的工作就还没有完成。在回顾AI帮我们节省了多少小时时,也想问一句:“能够放心接手这项改动的人,是否变多了?”
信任是决定性的制约因素
来源:https://newsletter.kentbeck.com/p/trust-is-the-binding-constraint 团队积累代码的速度,比积累信任的速度更快。两者之间的差距——缺乏信任的代码——正是项目失败之处。
两年来,我一直在这份通讯中反复思考这个观点。信任积累得很慢,却会在一瞬间消失。大多数建立信任的工作都是不可见的。AI为那些可见的部分浇上了助燃剂。代码的产出速度前所未有,而那些创造信任的实践——协作、测试、评审、共同理解——却悄然成为追求单人速度的牺牲品。
所以,我要为此开一门直播课。
可靠软件背后的人类实践将于11月9日和10日在ByteByteGo Live开课。这是我与ByteByte新合作的一部分,旨在帮助我以可持续的方式面向更广泛的受众分享观点。
每天包括2小时讲授,随后是1小时的自由问答。为期两天,大致沿着我一直在这里阐述的论点展开,将其具体化:
- **信任问题。**对产品的信任与对过程的信任。为什么信任崩塌的速度比修复更快,以及为什么信任的经济效应如此重要——值得信赖的软件让客户少花时间防范风险,多花时间使用产品。
- **创造信任的XP实践。**测试、结对、持续集成、规划、客户参与团队、持续部署、重构、可观测性。把它们视为一个系统,而非一张检查清单。
- **背后的原则。**人性、互利、改进、流动、冗余。将XP的价值观——沟通、简单、反馈、勇气、尊重——作为创造信任的系统,而非墙上的标语。
- **以信任为优化目标的AI辅助开发。**这是我最想讲清楚的部分。微调悖论:代码的可信赖程度随改动规模的平方而下降。AI倾向于大批量改动,信任则需要经过验证的小步推进。单人模式与多人模式:所有人都会推动你走向独自使用AI开发,而这是一个巨大的错误。在正确的地方放慢速度,才能走得更快。
这门课面向工程师和工程负责人。课程采用直播形式,因此你可以实时与我辩论——每天一小时的问答是这种形式中我最喜欢的部分。
我还确保了一些实际安排。每节课都会录制,所以即使时区不合适,你也可以之后补看。许多人会通过公司的学习与发展预算报销,ByteByteGo会提供发票,以及一份可以发给经理的邮件模板。
照我的惯例,还得加上一大堆说明。这是一门付费课程,而且并不便宜。如果你的团队成员已经完全互相信任,AI工作流也运转顺畅,那么你就不需要它。(我从没见过这样的团队,但从统计学上说,你们应该存在。)此外,所有观点都与我在这里写过的内容有关——课程是经过浓缩和深入推演的版本,配有在你的团队中开展的练习,而不是我的团队。
如果觉得有用,可以在这里报名:
来直播中与我辩论(https://live.bytebytego.com/?fpr=kentbeck-bbg)
(通过这个链接,你可以查看现有课程的详细信息和当前价格,也让他们知道是我推荐你来的)
还有一件事。这门课回答了过去一年里我每周都会被问到的问题:“好吧,我相信你说的信任很重要——那么,周一我到底该做什么?”这就是面向周一实际行动的版本。希望到时见到你,也希望你来与我辩论。
相似文章
@dotey: https://x.com/dotey/status/2055097242755706984
资深开发者常因过于强调代码复杂性而无法与业务团队有效沟通,而业务团队真正关心的是消除不确定性。文章建议开发者用“能不能试个更快的办法”来拉通双方案,并指出AI虽能快速写代码,但承担责任的仍是人类。
@thinkszyg: AI 编程速度悖论:写代码快了 48%,Review 慢了 6 倍。Review 流程怎么重建? SD Times 分析 25 万开发者数据:AI 让编码提速 48-58%,但 AI 生成的 PR 在 Review 环节卡 4-6 倍时间…
文章指出AI编程使编码速度提升48-58%,但代码审查时间增加4-6倍,安全漏洞增加,并提出了三步重建审查流程的方案,包括AI预审、聚焦架构决策、以及使用微软开源的ASSERT框架进行行为验证。
@Pragmatic_Eng: 任何认为软件工程会‘消失’的人都不了解这份工作。@KentBeck,XP和TDD的创造者,关于…
Kent Beck认为,即使AI不断进步,软件工程也不会消失,因为编码涉及建立信任、理解和联系,而这些是无法自动化的。
@hylarucoder: 当 AI 写代码的速度超过团队理解代码的速度,我们靠什么守住软件的命门? 从编译器、架构骨架、只读契约,到重构循环和可抛弃实现,整理了我最近对 AI 时代代码治理的一些思考。
作者探讨当 AI 编码智能体的代码产出速度超越团队理解速度时,如何通过编译器硬约束、架构骨架、只读契约、重构循环与可抛弃实现等五层治理手段,对抗系统熵增与人类认知破产,守住软件的可维护性。
工程纪律
一位开发者讨论了在使用AI编码代理时,代码生成速度超过理解速度,如何保持工程纪律和架构完整性的挑战,并寻求避免创建低质量软件的最佳实践。