🏠

固执开发者之死

原文: https://steve-yegge.medium.com/the-death-of-the-stubborn-developer-b5e8f78d326b

作者: Steve Yegge

翻译：费米

---

【编者按】

所谓聊天式编程，Chat Oriented Programming, CHOP 恰恰说明，聪明如 Steve Yegge, 至少在2024年底，还没想明白Function Call工具调用在LLM如何工作， 更不可能明白其的意义。但他显然明白Agent Loop。他其他的探索毫无意义。他 的文风一如既往。他的论断蕴含在上一个论断里因此十之八九正确。但他和 Ghostty 作者Mitchell Hashimoto不一样，他有观点基本没作品。

---

【关于作者】

Steve Yegge，美国程序员、博主。14 岁高中毕业，18 岁加入海军核动力学校 成为核反应堆操作员，后毕业于华盛顿大学计算机系。1998-2005 年在 Amazon 任高级软件开发经理，2005-2018 年在 Google 任 Senior Staff Software Engineer。以博客 "Stevey's Drunken Blog Rants" 闻名，文章以长篇、坦诚、 充满个人观点著称，2011 年一篇意外公开的内部文章（"Google Platforms Rant"）被广泛传播，深刻影响了业界对平台战略的认知。代表作包括 Google 内部的代码智能平台 Grok、Rhino on Rails（将 Rails 移植到 JavaScript）、 图形化 MUD 游戏 Wyvern。2022 年加入 Sourcegraph 任工程主管。2025 年与 Gene Kim 合著《Vibe Coding》。多年来持续写作和发声，是软件行业最有争议、 也最难以忽视的博主之一。

---

五月份我写了篇稿子，叫《初级开发者之死》。捅了马蜂窝。后来好几个大公司 的动向都印证了我的论点——而且不光软件行业，其他行业也在发生同样的事。 这是个真实的、根本性的问题，尽管对几乎所有人都挺不方便。

我那篇捅马蜂窝的文章，核心前提很简单，可以用软件项目里两类不同的任务来 理解。

任何一个有经验的项目经理都知道：但凡有点规模的项目，背后都隐含着一张任 务图（task graph），由多个任务组成，各有子任务和依赖关系。

图中很多节点是叶子节点（leaf-node tasks），比如"写个认证库"或者"把那些 单元测试现代化"。这类任务通常比较独立，边界清晰。我们经常把这些叶子任 务交给初级开发者去做，因为范围小。

另一类任务是以各种方式组合叶子任务，交付整个项目及其所有子项目。造车的 话，你可以把每个零件都 3D 打印出来——LLM 对代码做的事，差不多就是这个 意思。但总得有人把车装起来。

那些更高层的、任务图内部的节点，往往涉及大量的规划和协调。

问题来了：大概从五月份开始，LLM 已经能完成大部分叶子任务，甚至一些高层 内部任务，哪怕在大型软件项目上也是。这很棒。但留给人类的，主要是更难的 规划和协调节点。这些任务不是那种你能交给初级开发者去做的。

所以初级开发者到底该干什么？他们要怎么升级？

我的呼吁：他们最好学会聊天式编程（chat-oriented programming，CHOP），" 否则"。

以上就是我那篇稿子的大意。有点过于简化，但今天够用了。那篇文章确实引起 了轰动。但我觉得人们没有完全理解的是，就算喧嚣已经平息，问题本身并没有 结束——它才刚刚开始。

这其实不光是初级开发者的事

回头看，"初级"这个标签不太对。我和很多人聊过"初级"这个词用在软件开发者 身上是否准确，大家都同意这不是最恰当的说法。确实有一类开发者正在被甩在 后面，但这显然比"初级开发者"要微妙得多。

不过初级开发者确实受到很大影响，这值得担忧。

一个问题在于，让初级开发者成长为高级开发者的那条路径，已经断裂——或者 说至少受损了。我借用 Matt Beane 博士的一个贴切类比，他描述了同样的现象 发生在初级外科医生身上，原因是手术机器人的出现。情况非常相似：任务图的 叶子节点被自动化了，所以不需要那么多初级从业者了。

但有些初级工程师抓住了这些新工具，飞起来了——相当于自我升级。而许多高 级工程师反而在走向被淘汰的方向。所以到底是什么情况？

我最近和两家截然相反的公司聊过——一家是初级开发者积极采用 chop，但高 级开发者固执地拒绝，说这是花架子。另一家是高级开发者已经用上了 chop， 但初级开发者拒绝用，理由是他们认为这会抢走自己的工作。外面简直是疯了。

所以要准确描述这个问题并不容易。怎么一句话说清楚哪些开发者处境最危险？

我们最终归结为一条原则：如果你不把聊天式编程作为主要工作方式，你就在被 淘汰。

不能使用 chop 的合理理由确实有，但正在迅速消失。

所以你怎么叫它都行，但在我看来，随着时间的推移，那些拒不采用的人只会越 来越像是固执。

聊天式编程

为什么我专门强调聊天式编程？因为和 LLM 聊天，就是让那些任务图叶子节点 被 3D 打印出来的方式。这是整个流程中不可分割的一部分。

聊天，正是当下编程越来越普遍的开展方式。说"软件工程师"这个职业正在被永 远改变，所有编码——甚至更新——最终都将通过聊天完成，这不算言过其实。 而且别忘了，你聊天的对象是一个会严重幻觉的东西，所以这并非我们希望的那 种一帆风顺的飞跃。但它的提升太大了，经济力量正在把所有人推向那个方向。

在我的博客里，我把这种现象称为聊天式编程（Chat-Oriented Programming）， 简称 CHOP（或者就叫 chop）。Chop 不只是未来，它已经是现在。如果你没用 它，你正在被用的人甩在后面。

我打算不再把这句话说成是"我的观点"了，因为到这个地步，它已经进入公认事 实的范畴。在 Sourcegraph，我们有很多合作伙伴和客户在和我们分享他们内部 研究的成果，覆盖各种编程助手。这让我们比大多数人有更广阔的视野。

总的结论是：转向 chop 能让企业工程师的生产力至少提升 30%——哪怕工程师 们一边抱怨一边觉得自己用起来更慢。这个数字是保守的，有些报告的数字更高。 而且那些研究很多都是早期的。

这个基础生产力提升会继续增长，因为基础模型、工具和 chop 本身的艺术都在 成熟。而且上限不是 100%（两倍）。在某些场景下，轻松达到 10 倍、20 倍甚 至更多。

朋友们，这玩意儿上瘾。随机的正反馈就是这么带劲！光凭多巴胺冲劲，chop 就很好玩——帮你弥补那些气得跺脚骂娘的时光。

所以 chop 是真实存在的东西了。已经在发生了。据我上次了解，ChatGPT 仍然 是世界上用得最多的编程助手，而它不做代码补全，只做 chop。Chop 有大批拥 趸。

唯一还有争议空间的地方，是 chop 能持续多久。我的未经证实但有根据的猜测 是：至少三年。实际上我觉得很有可能持续十年——看看汇编语言用了多久才死 透¹。

这就是我的判断：我们还要和 chop 打很多年交道。

唱唱反调：也许短期内会有更好的东西

还有一帮非常聪明的人持不同意见，我想尽量公平地呈现他们的观点。他们不否 认 chop 今天存在。但他们倾向于认为 chop 是短命的，因为它会被各种形式的 自主智能体（autonomous agents）取代。

这种分歧的根源有两点。第一，chop 很难。你得是一个熟练的计算机使用者才 能用好它。不一定是熟练的开发者，更像是熟练的 hacker。你得打字快、读得 快、工具用得好，有足够的 chops（咳咳）去手动搬运大量文本和上下文。

所以很多人担心 chop 不适合大众。而大众手里有钱，这当然就成了一个眼下 （2024 年底）值得关注的问题。

聊天式编程很难，但很多人相信自主智能体就在转角，它们会替你完成所有重活。 你只需要写简短的提示词，抽查一下结果，少了很多苦力。

他们相信这些通用的自主软件智能体可以解决 chop 太难、太累的问题。实际上 有些人声称智能体能完全接管任务图——至少对小企业是这样——让不懂技术的 CEO 自己就能发布应用，不需要雇那些烦人的开发者。

我觉得这些人绝对是抽了大麻。但他们很多人资金充足，所以有机会去试一把， 一路上烧投资人的钱就像烧航空燃油。这让我想起当年的打车大战。钱能烧多久 呢，我很好奇²。

人们认真做 LLM 驱动的自主智能体至少已经 18 个月了——

更新：Devin 在我发这篇文章的后一天正式发布了 GA，还附带了客户成功案例。 有意思的是，客户用它做批量重构和迁移。看起来——这支持了我在这里的所有 论点——Devin 的团队明智地收窄了他们的野心和承诺，聚焦在特定用例上，而 不是"什么都能做"。他们的网站上写的：用于前端应用修复、生成后端变更的" 方案"（嗯 LLM 早就能做了）、以及批量重构。所以他们基本上是在网页应用生 成器上套了一层批量重构工具。

事实是：那些改变行业的新技术——改变我们编码方式的技术——总是一样的增 长路径：渐进式的。它们一开始小而能用——刚好够好，值得你用。然后随着时 间的推移，通过多次公开发布，慢慢长成庞然大物。至少，如果它们一开始就不 错的话。

例子：IDE、高级语言、Web 编程、云计算、移动计算、CI/CD——这些东西都是 这样长大的。就连 LLM 本身，也是神经网络三十多年公开可见的渐进式改进的 结果。

所以你预期通用自主智能体也会这样，对吧？

那么，它们在哪儿呢？如果我漏掉了什么，请告诉我。但据我所知，还没有人推 出任何可用的东西来开始迭代。

到这一步，我怀疑还在场上的投资人，是在指望一个"大爆炸"式的突破，一次性 把这事儿推起来。因为现在如果只是涓涓细流，那就完蛋了。

我的意思是……也许吧？有可能吗？我本人持悲观态度。

但也许存在某种中间地带：不像完全通用的自主软件智能体那么雄心勃勃，但仍 然是很大的生产力倍增器，能帮你处理任务图中比普通 LLM 聊天多得多的部分。 我觉得，这是有可能的。

寻找中间地带

这方面我极为尊重一个人的意见：Idan Gazit，GitHub Next 的高级研究总监。 他今年在拉斯维加斯的 ETLS 上做了一个精彩的演讲。Idan 不是 chop 的狂热 粉丝。我们为此深谈过一次，那家伙真酷。

我确实理解他的观点。本质上他骨子里是个 HCI 的人³，所以他当然不希望 Copilot 用户在那儿折腾任务图管理和上下文搬运。他想要一种每个开发者都能 用的 AI 模式，不偏袒那些高手。

Idan 对 chop 的不满——或者说他的 chop beef（搅碎的牛肉）——挺有道理： LLM 知道答案，但它除了告诉你之外什么也做不了。你可以说它的 agentic 程 度，嗯，和碎牛肉差不多。你，程序员，必须完成所有把上下文"剁碎"进聊天会 话、再把答案"塞回"代码库的劳动。

抱歉，太晚了。这像是在打我自己和你的脸来保持清醒。

重来。你，程序员，必须完成所有获取上下文和整合答案的劳动。基本上就这个 意思。Chop 涉及大量的获取和整合。一遍又一遍，循环往复。如果你在用聊天 优先编程，这现在就是工作的很大一部分。

Chop 的这些苦力活，感觉明显应该由你的工具来处理——我想每个人都会同意。 基于这个出发点，Idan 在寻找比聊天更强大的东西，一种今天任何普通程序员 都能用、不需要学太多新东西的模式。

这很重要。如果开发者不用学那么多，那是个好消息。更多的程序员会用 AI， 更多的开发者能活过向 LLM 转型的过渡期。我很支持。Copilot Workspace 是 GitHub 在这个雄心勃勃的方向上的第一次尝试。我希望他们能成功。

Idan 有句很有见地的话：不管谁撞上了那个神奇配方，所有人都会跟着抄。所 以从某种意义上说，我们都在同一条船上，试图搞明白编程明天到底长什么样。

虽然我为他们加油，但我自己不会押注这个。我假设需要好几年才能造出足够可 靠的智能体，可以放进开发者的工作流里，指望他们不需要任何培训或苦力就能 用。

Chop 自带问题

与此同时，你今天就能用 chop——任何支持聊天的编程助手——立刻更快地完 成工作。这是好消息。

不那么好的消息是，如果你没耐心，你确实得学新东西。Chop 本身固有的难度 加上它的新颖性，催生了一系列衍生问题。怎么教？怎么学？怎么面试？当然， 还有怎么度量？

我和出版商、研究者、行业大拿都聊过。每个人都在某个层面上理解，聊天式编 程是编程的下一个大进化阶段。上一次这么大的是从汇编跳到高级语言。

但没人知道怎么教 chop。没有资源。还是第零天。我们还没搞明白具体怎么干， 它就已经在发生了！听起来很像当年的 CI/CD，对吧？一堆最佳实践围着篝火口 口相传？

对于企业来说，没人知道怎么度量 Code AI 的影响——这个术语广义上包括所 有用 AI 加速软件开发的已知方法，chop 是其中一个大头。

如果你不确定它是否有效，你怎么能 justify 公司在 Code AI 上持续投入一大 笔钱呢？

Code AI 的指标

巧了，传奇人物 Gene Kim 和我正在密谋搞点东西出来。从今年夏天在 ETLS 认 识 Gene 以来，我们就一直在合作。这期间我越来越佩服他。他是你见过的最积 极、最鼓舞人心的人，他的热情有感染力，能点燃人。说真的，要不是 Gene 整 晚发短信催我"发！！"，我今天都发不出这篇文章。

更重要的是，Gene 有很多超能力——包括梦寐以求的"无限精力"DLC，而这通常 不会和"伤痕智慧"以及"无限耐心"同时出现。但 Gene 全都有。

和我一样，Gene 也对 chop 对他个人生产力以及整个行业的影响着迷。为了探 索"怎么教"这个问题，他和我做了一次 Zoom 结对编程，收获巨大。如果你想看 chop 的实际效果，这是个很深的兔子洞。在我们的 session 里，Gene 用 chop 开发了一项新超能力——让他成为世界上剪辑 YouTube 视频片段最快的人。低 阶超能力？没错。

但他在不到三小时里就获得了。你们感受一下！

为了帮助解决影响度量的问题，Gene 打算做他当年对 CI/CD 做过的事：DORA 指标。Gene 是那个改变行业的倡议的奠基人之一，和 Nicole Forsgren 博士以 及 Jez Humble 一起。现在，Gene 的计划是对 Code AI 做同样的事。

思路是定义一套严谨的行业标准指标，帮助公司判断自己是否在做正确的事。这 些类似 DORA 的指标需要集体努力。Gene 还有一个和互联网共同发明人 Vint Cerf 共享的神级超能力——我见过的只有他们俩有这本事。Vint 曾非常严肃地 告诉我："我的超能力是能把人召集起来。"Gene 也有召集和凝聚专家的罕见天 赋。而他为这个问题组建的团队是世界级的。

连 Idan 也在里面。自然。我们不是闹着玩的。

但这些内容对这篇文章来说太多了——它已经像野草一样疯长了。唉。不过我可 以剧透一点：我们发掘出的最重要的指标维度之一是"可选性"（Optionality）。 Chop 不一定让你在已经擅长的事情上快很多。但它会让你在不擅长的事情上快 得离谱——那些你一直拖着、因为觉得不值得花力气去做的事。

Chop 因此让你在每个阶段都能并行探索多个选项。比如，你不受限于你已知的 编程语言；你可以让 LLM 用你想尝试的任何语言来做。数据库后端也一样。只 要接口基本相同，LLM 能快速为同一个接口创建多个子系统，让你直接对比。

这极大地扩展了你（和你公司）愿意去啃的范围——这对公司所有层面的规划都 有巨大影响。同时也提高了结果的可信度，因为在每个关键节点上，你都试了好 几个选项。

我们认为应该量化和度量这一切，Gene 正在从其他领域引入最顶尖的"可选性" 专家来帮忙。关注他的 Twitter！

尾声

以上就是我的全貌。我不看好通用自主智能体（编辑注：虽然 Devin 今天的发 布看起来有希望，因为他们收回了那些疯狂的说法）。我正和几家做专用和半专 用智能体的公司在聊，这是个有意思的想法。但都还在早期，未经证明。我祝他 们顺利，但不抱期待。

我不是想画一幅美好的图景。Chop 的普及在未来一段时间内还会颠簸不平。自 从五月份以来，我对它的缺点了解了很多。它和常规编程非常不同——比如幻觉 问题。人们对这种程度的模糊性的容忍度各不相同。你可能会以为 chop 的学习 曲线在变平，但看起来它反而在变陡。

而且这超出了很多人的舒适区，或者他们心目中程序员工作"应该"是什么样子的。 你得投入大量时间才能切换过来，然后你的工作就完全不一样了。这对人们的期 望很高。

一旦你真正开始用 chop，你会失望地发现它的好处非常不均匀——让人很不舒 服。有些人获得的收益比其他人多得多。它明显偏袒有特定技能的开发者。而且 不同任务之间的效果也不一样。我的朋友 Eric Fritz 博士，在过去一年里自己 从怀疑论者变成了皈依者，他对如何描述这些特质有一些有趣的想法。值得一看， 我保证。

但底线是：chop 虽然我说它不可避免，但不幸的是，它远不是一个线性的加速 器——不像人们以为的那样。尽管有"经过验证"的生产力提升，chop 也"已经证 明"了自己是个刻薄的麻烦制造者：不直观、不均匀、不可预测。难怪那么多人 希望它只是一个短暂的过渡阶段。

我和 Sourcegraph 的同事们坚定地站在一个阵营：我们相信你就是那个在叶节 点之上管理任务图的智能体。我们相信这个管理者是人，不是模型。我们不会坐 等自主智能体的研究得出结论、等那些通用系统被造出来、发布、测试。

去他的。我们只想给我们自己（和你们）需要的能力，让 chop 更快。

这在实践中意味着什么？两件事，而且对任何编程助手都适用。第一，让 LLM 的输入更快——通过加速上下文获取和提示词复用。第二，让处理输出更快—— 比如通过一个智能应用按钮（smart-apply）。

当然，LLM 的方案通常涉及更多类型的集成——比如运行工具或检查日志——在 这些集成成熟之前，你得靠手动苦力来处理。但拥有一个编程助手已经是巨大的 提速了。尽管有缺陷和空白，编程助手的体验比直接用裸的 Claude 或 Gemini/GPT 要好，因为它们简化了大量 LLM 输入输出的工作。一切都取决于你 的编程助手对聊天这种模式的支持有多好。

可以说，市面上有数不胜数的编程助手——正如 Idan 观察到的，它们通过互相 抄袭在某种程度上趋同。这就像选车，或者选航空公司。功能集大致相同，但那 些可调的旋钮都拧到了不同的位置。

举例：有些助手把你锁定在某个模型上；其他给你选择。有些追求零配置的即开 即用体验，你不需要动脑子就能用；其他给你更多控制权。有些更关注个人用户； 其他主要关注企业。有些要求你用他们的 IDE，其他则作为插件住在你的 IDE 里。

这些都是一些相当根本的选择，对很多开发者来说意义重大。取决于你的偏好和 公司需求，你可能会倾向于——或者被迫使用——某个特定的编程助手。记住， 虽然它们做的大致是同一件事，但它们呈现功能的方式可能非常不同。

但我认为有这么多的选择是好事！竞争催生创新。

人们经常问我："编程助手 X 有什么功能是其他没有的？"我觉得这不是正确的 问题。如果你把它们看作汽车型号——因为它们确实既多又复杂——那么编程助 手之间的差异，可以大到像悍马、兰博基尼和电动自行车之间的区别。正确的问 题是："哪个最适合你？"

最重要的是要知道：它们全都酷得要命，如果你用它们来做 chop，你会飞起来。 别再想代码补全了。那东西只有在 LLM 不帮你写代码的时候才有点用——而这 应该是永远不会发生的，至少趋势是这样。只要你让 LLM 替你干活，任何支持 聊天的编程助手都会让你立刻成为更好的开发者。就是今天。

反过来也一样：如果你不用 chop，你就是在爬。你就跟那些顽固的汇编语言守 旧派一样——1990 年还在用 asm，因为编译器生成的代码不够快。一群固执的 混蛋。听着耳熟吗？

他们既对又不对——编译器生成的代码确实不如手写代码可靠（听着耳熟 吗？）……在当时。一旦编译器赶上来了，他们的末日就到了，他们的自鸣得意 被一扫而光。

同样的事情很快就会发生在你身上——如果你发现自己还在手工写代码的话。

这对很多人来说是一颗极难吞下的药丸。药剂师告诉我，很多患者搞混了栓剂和 口服药，试图去吃栓剂。我觉得这真是一个绝妙的比喻。Chop 不直观，偏袒能 人，生产力提升不均匀，工具支持还不完善，而且很难度量。而且你不该去吃它。

这些确实是 tough bananas。但除非你想把一切都赌在自主智能体短期内突然不 烂掉上，那你最好立刻开始学 chop。因为要学的东西很多，而且大部分你得在 做中学。

今天就到这儿！如果你想要一个总结，就在标题里。

我这次的呼吁，给今年画个句号，和五月份一样：他们最好学会聊天式编程，" 否则"。否则……他们的牛肉就被剁碎了。你懂的。

天，真的很晚了。我收工了。

该让你的团队跳进来了，开始试着停止写代码。

那是 LLM 该干的事。

---

【译编聊】

看着他胡言乱语，我也有感触。

AI 智能体编程到底该怎样搞，我有非常不同的看法。但这里先不展开，只聊三个读完忍不住想的问题。

Emacs 作为 IDE 会死吗？

不会因为 AI 死。它过去三十年活下来的方式，从来不是因为它对多数人最好用， 而是因为它可编程——你用 Lisp 把它改造成你自己的东西。这个特质面对 AI 反而成了优势：你可以把 LLM 调用、补全、上下文注入织进编辑流里，而不是 被 IDE 供应商定义的"AI 功能"框死。Emacs 会以 Emacs 的方式活——活得不 大，但活得硬。

程序员是升华还是变墓碑？

两样都会发生。Yegge 文章的走向暗示了：顽固的人拒绝适应，于是成为墓碑； 而那些把新范式当技能学的人，从写代码升华成定义问题、设计系统。代码本身 在贬值，"知道该写什么代码"的能力在升值。

到底该信什么？

不确定本身比任何一个答案都值钱。Yegge 猜了一个方向（Agent Loop），他自 己也承认看不清。那些言之凿凿的预测——记得区块链要改变一切吗？——后来 大多成了笑话。不确定才是诚实的立场。

Yegge 这文章的效果就是：他从不说你该怎么做，他让你自己去察觉。读着他的 怒骂，你会忍不住自问——我是不是就是那个顽固的人？

也许这就够了。