@obie:二十六年过去,编程智能体打破了极限编程的大多数假设,却没有动摇其最好的理念。所以……
摘要
极限编程(XP)早期实践者 Obie Fernandez 认为,编程智能体颠覆了极限编程的大部分原始假设,但其核心原则并未改变,他因此为 AI 驱动的软件开发时代重新构想了 XP。
查看缓存全文
缓存时间: 2026/10/28 05:32
二十六年后,编程智能体打破了 eXtreme Programming 的大部分假设,却没有打破它最好的思想。所以我为智能体时代重写了 XP。https://t.co/SAxElsOI6a
eXtreme Programming:面向编程智能体时代的重新审视
我已经不记得原因了,但在 2000 年初,我设法成为最初的 XP 邮件列表最早的订阅者之一。因此,Ross Rankin 和我决定让他的初创公司 Media Ocean 成为佐治亚州亚特兰大第一家全面拥抱 eXtreme Programming 的公司。我们有结对工作站,先写测试,玩计划游戏,并且多年来忠实地进行每日站会,最终发展到数十名工程师。正因如此,在 2000 年 12 月一个寒冷彻骨的冬夜,Paul Gale、Chris Gardner、Andrew Fuqua 和我创立了亚特兰大 XP 用户组。它非常成功,2003 年我主办了一次聚会,那次聚会改变了我的人生。我们请 Martin Fowler 吃晚饭,他鼓励我加入 ThoughtWorks,不久之后我就被录用了。
从那以后,我职业生涯中的大多数项目都是以某种形式的 XP 来管理的。多年来,我有幸结识或与许多 XP 传奇人物共事,比如 Kent Beck 和 Ron Jeffries,甚至还和 Ward Cunningham 结对过。(是的,我的编号是零。)我甚至聘请了 Robert Martin 本人到 Hashrocket 指导我的团队。换句话说,我近距离亲历了 XP 和 Agile 的崛起(以及衰落),它比职业生涯中任何其他经历都更深刻地塑造了我对构建软件的思考。
这段历史让我对我们当前正在经历的时刻深信不疑——毕竟我上一次亲历整个行业彻底自我重塑时,就在现场。
我们就像那个冲出悬崖却还没往下看的卡通人物。每个人都获得了这些惊人的神奇创造力量,正在所有地方、同时生成多得离谱的代码。而据我所见,几乎每个软件开发团队目前都在争论是该猛踩油门还是猛踩刹车,有些团队甚至同时踩两边!人们很害怕,而且其中很多人有充分的理由害怕。
我以前见过这一幕。正如人们所说,历史不会重复,但会押韵。
千禧年时的软件开发图景
企业界 XP 早期采用者第一个、也是最喜欢的假想敌是“前期大设计“(BDUF)。做“瀑布“的团队花几个月时间编写需求,等需求被“扔过墙“交给程序员时,早已过时。反馈周期以年为单位。程序员对设计自己实现的系统毫无发言权,那是城堡塔楼里的分析师和架构师的工作。
讽刺的是,XP 解决的第二个问题更为普遍,但如今几乎没人再提了。90 年代和 2000 年代的大多数软件开发完全没有流程。那是牛仔时代。我知道,因为在 XP 之前,我就是他们中的一员。把东西做完,然后扔过墙给 QA。假设你有 QA 的话,否则就在生产环境里现场发挥,听天由命。
Extreme Programming 很有道理,它把当时被视为“最佳实践“的东西一路推到极致。比如,测试好,那就一直测试(例如 TDD);代码审查好,那就每写一行都审查——很多人可能没意识到这正是全职结对编程的目的;集成好,那就持续集成;客户反馈好,那就把客户(例如产品负责人或利益相关者)搬到和程序员同一个房间里。在那个满是散发着异味的胖络腮胡程序员的年代,最后这一点常常遭到极其强烈的抵制!但我们是为理智和成果而战的叛军!坚持打这场正确的仗,而且它确实管用。然后 Scrum 毁了这一切。然后 ChatGPT 出现了,接着是 AGI(大概吧?),所以我们正在经历技术奇点?还有……
先停一下,因为你知道吗?
两种失败都卷土重来了
新的 BDUF 是没人读的机器生成计划。前几天我看着一个朋友在 Confluence 里一页又一页地滚动浏览 AI 生成的垃圾内容。他解释说没人读这些,但总有人指挥 Claude 把这些“Confluslop“变成 Jira 史诗和用户故事。然后想必会有某人的 Claude Code 接手去真正干活?没人确切知道。我感觉他团队里的每个人就是整天坐在那台机器前按回车键。他们对此并不特别满意,但考虑到六位数的年薪,我想趁还能拿就还算不错吧。他们知道这不会持续太久,因为这纯属胡闹。
新的没有软件开发流程的蛮荒之地,正是 vibe coding。我写的书通过 Ruby on Rails 教会了一代程序员重“约定优于配置“。编程智能体彻底颠覆了这一点,连 DHH 本人都为之着迷。现在每个开发者(无论是 vibe 还是别的)都拥有无穷无尽的配置旋钮和开关,它们存在于不知多少量的非结构化英文提示词中,用来基于模型当天随口吐出的任何东西来“创造软件“。十个开发者,每人十个智能体,他们交付的东西会带来架构和设计方法的指数级爆炸。听起来耳熟吗?
在读这篇文章的你们中,凡是认真对待自己职位中“工程师“部分的人,都在受苦。抱怨遍布 X、LinkedIn 以及全世界每个 Slack 频道。这些失败就是 2026 年 10 月此刻的危机。
好消息是,尽管到处一片混乱,XP 仍能启发接下来会发生什么。拿出有效的部分,把旋钮拧到 11 档,再给结果起一个朗朗上口、人们能团结在其周围的品牌名。我称之为 Impatient Programming(急不可耐编程),简称 IMP。从业者是 Imps(小恶魔),我们要给我们的机器拴上紧皮绳。😈
想了解更多?
这篇文章只是导言的上半部分。其余内容在网站上:当智能体编写大部分代码时,结对编程、测试先行、简单设计和计划游戏如何变化,以及取代 XP 那 29 条规则的 29 条新规则,每条新规则都并列着 1999 年的原始版本。一些聪明人已经写了文章指出我哪里错了,我们已经把它们发布了。网站上还有我们在 ZAR 构建的一系列护栏工具,用来约束我们的智能体保持诚实,外加一个涵盖各种技术栈的数百个工具的目录。现在全部开放在 https://impatientprogramming.org。
相似文章
@obie:2000年,我加入了最初的极限编程(XP)邮件列表。在工作中我们有结对编程工位,我们先……
ZAR 的 CTO Obie Fernández 介绍了「不耐烦编程」(IMP),这是针对使用编码智能体构建软件的团队,对极限编程 29 条规则的重新审视,同时还提供了护栏工具以及 539 个相关工具的目录。
@svpino:许多长期坚持的原则和实践在智能体编程时代依然适用,而许多则不然。我们都在努力搞清楚……
本文探讨了传统软件工程原则在智能体编程时代的演变,强调了软件工程师对AI驱动开发的实验性适应。
@Pragmatic_Eng: 旧软件工程模式因编码代理而回归。Dax Raad(@thdxr),AI编码代理OpenCode的联合创始人…
Dax Raad,AI编码代理OpenCode的联合创始人,认为像领域驱动设计这样的旧软件工程模式正在重新变得相关,因为编码代理虽然高效,但需要更多的防护措施;这些模式曾因冗长而令人痛苦,而现在AI处理了这些冗长部分。
@simonw: 我花在编程代理上的时间越多,就越确信它们让软件工程变得更难…
作者认为,尽管编程代理功能强大,但它们使软件工程更具挑战性,并需要非凡的纪律性,讨论中提到了Opus 4.6和GPT-5.2等最新的AI模型。
还有人注意到,开发 AI 智能体的人正在忘记软件工程的基本原则吗?
一位从业者认为,AI 智能体开发者正在重新发现一些基础软件工程早已解决的问题,例如输入验证、数据建模、进程隔离和访问控制,而氛围编程却忽略了这些贯穿各个环节的共性问题。文章呼吁将成熟的设计与架构原则应用于智能体工作流。