虽然我并不认同“IDE 会在 2026 年消亡”这种绝对说法，但 Steve Yegge 和 Gene Kim 在分享中抛出的判断，依然值得认真对待：在他们的推演里，从 2026 年 1 月 1 日起，继续依赖传统 IDE 的工程师，会被更快拉开差距。

他们认为这不是“工具升级”，而是“生产方式换代”：工程师的竞争力，越来越取决于你能否用好新一代 AI 开发方式，以及你愿不愿意为它付出真实成本——例如把每天的 token 开销重新定价到“接近日薪”的量级。

更刺耳的是，他们转述了 OpenAI 的 Andrew Glover 的一项观察：是否使用 Codex，可能会让同级别工程师之间的生产力差距被拉到 10 倍，这让管理层“非常惊慌”，“因为他们甚至可能不得不裁掉 50% 的工程师”。

其核心观点如下：

• 现在的模型本质上是派一个潜水员下去，让它在代码库里四处探索，即使给它更大的氧气瓶，比如一百万 token，它仍会耗尽。正确做法应该是派多个角色，而不是寄希望于一个超大的单一潜水员。

• 如果你在 2026 年 1 月 1 日后还在使用 IDE，那你就是一个“不好的工程师”。

• 作为工程师，我每天花在 Token 上的费用应该与我的日薪相当，也就是每天 500 到 1000 美元。

• Claude Code 走错了方向，他们造出一只巨大、耗能、高成本的“肌肉蚂蚁”。

Steve Yegge：今天的时间会过得很快，我将讨论明年(2026 年）开发工具的样貌。

现在所有人都迷恋 Claude Code，市面上大概有四十个竞争者，但 Claude Code 并不是答案，代码补全也不是。

虽然我每天使用它十四个小时，但开发者并未真正采纳。核心问题是这些工具使用难度过高，认知负担重，而且常常“撒谎、作弊、偷懒”。因此大多数开发者并不喜欢这样的工具。

我逐渐认识到，Claude Code 很像电钻或电锯。对于没有受过训练的人，它既能帮上忙，也能造成巨大损伤。未受训练的工程师使用 Claude Code，与一个新手拿着电锯差不多：既可能“切到脚”，也可能在熟练后完成极其精细的工作。然而软件世界无限广阔，而我们的野心也同样无限。

因此我想用一个类比说明：明年将是从“手持电锯、电钻”转向“数控机床（CNC）”的一年。CNC 在给定坐标后能自动执行极其精确的操作，这项技术我们已经使用了数百年，也不会在今年停止。

有人说“模型已经触顶了”，你的工程师们可能也这么说。即使如此，我们仍然等同于刚发现蒸汽和电力，还需要时间去驾驭它。现在的问题已经主要是工程问题。一年到一年半内，所有代码都将由大型自动化“磨床”式系统生成，工程师不再直接查看代码。这将是一个全新的世界，而我们正走向那里。

Gene 和我曾与 OpenAI 的 Andrew Glover 交流过，他说公司内部出现了明显的分化：部分工程师使用 Codex，而更多人没有用（拒绝使用工具的人主要是资深与 Staff 级工程师），产能差距巨大，导致绩效评估出现警报。两个同级别的工程师，其生产力可能相差十倍，这让管理层非常惊慌，因为他们甚至可能不得不裁掉 50% 的工程师。

这种情况类似瑞士机械表产业的衰落：经历数百年的辉煌，却被石英表在短短几年内颠覆，当时的工匠与今天坚持传统方式的资深工程师反应如出一辙。

未来需要的是一种全新的 UI，不是传统 IDE，而是新的 IDE。事实上，Replit 已经走得最前，他们的方向非常值得称赞。我们不该再继续追着旧形态、构建各种命令行界面。

更重要的是，Claude Code 及其竞争者都走错了方向——它们像在打造“世界上最大的蚂蚁”。

我的朋友、澳大利亚联邦银行的 Brendan Hopper 说得很好：自然界靠蚁群协作，而 Claude Code 却造出一只巨大、耗能、高成本的“肌肉蚂蚁”。无论是要分析整个代码库，还是只是问“我的 git ignore 还在吗”，它都调用最昂贵的模型。

于是我想到了“潜水员隐喻”：上下文窗口就像氧气瓶。现在的模型本质上是派一个潜水员下去，让它在代码库里四处探索，即使给它更大的氧气瓶，比如一百万 token，它仍会耗尽。正确做法应该是派多个角色：产品经理潜水员、开发潜水员、代码审查潜水员、测试潜水员、合并潜水员等，而不是寄希望于一个超大的单一潜水员。可没人这么做，大家都在造“大潜水员”。

未来的构建方式将是工程师熟悉的：任务分解、逐步细化、组件化、黑盒化，并依赖大量协作的智能体，而不是单一智能体。

但在此之前，我的建议还是：学习 Claude Code 来适应新方式，并放弃你的 IDE。如果你在明年 1 月 1 日后还在使用 IDE，那你就是一个“不好的工程师”。

Gene Kim：我研究高绩效技术组织已有 26 年，这段旅程始于我作为 Tripwire 的技术创始人。我们致力于研究那些表现卓越的技术组织——它们在项目交付、运维稳定性、安全合规方面都处于领先。我们想理解这些组织如何实现“从优秀到卓越”的转变，以及其他组织如何复制这些成果。

在这 26 年中我经历了许多意外，其中最大的意外之一，是这项研究最终将我带到了 DevOps 运动的中心。DevOps 改变了测试、运维、信息安全等角色的协作方式。我曾以为这会是我职业生涯中最激动人心的经历，直到我在今年 6 月首次与 Steve Yegge 见面。

我和 Steve 有许多共同点，其中之一就是对人工智能的热爱，以及都认为 AI 将从底层重塑软件开发的方式。我们相信，AI 对技术组织的影响，可能比十年前敏捷、云计算、CI/CD 和移动化所带来的变革大上百倍。而这些技术突破不仅会改变组织，也会重塑整个经济，让经济结构围绕更先进的生产方式重新排列。

过去一年半，我们观察了许多案例，让我们提前看到未来技术组织的雏形。有人可能熟悉 Adrian Cockcroft，他曾是 Netflix 的云架构师，主导了 2009 年将 Netflix 整个基础设施从自建机房迁移到云端。他在几个月前写道，2011 年有人提出“无运维（NoOps）”时，引发了基础设施和运维团队的强烈反对，但现在类似的事情再次发生，只不过这次可能叫“无开发（NoDev）”。如今看来，这似乎不再好笑。

我们从 Zapier 的分享中看到，支持团队能发版，设计师能发版，UX 设计也能直接发版。过去被开发者告知“排队、等一个季度、等一年、甚至永远等不到”的人，现在突然能够自己把功能“对话式地”写进生产环境。这不仅改变技术组织，也可能改变整个经济。

Steve 和我很幸运能看到部署方式的改变带来什么影响。十年前，我写了《The Phoenix Project（凤凰项目）》，讲述灾难性的部署流程。当时许多组织一年只发布一次版本，难以想象。后来我参与了 DevOps 状况研究，这项跨行业研究在 2013–2019 年间覆盖了 36,000 名受访者。我们发现，高绩效团队每天能多次部署，并能在一小时内完成一次发布。

在 2009 年，多次每日部署被视为鲁莽、不负责任甚至“不道德”，但如今却是常态。若想保持高可靠性、缩短平均修复时间，就必须更频繁地进行更小规模的部署。现在我们看到的案例表明，不再手写代码，而是运用新的方式进行开发，可能是一种价值更优的路径。

我们在《Vibe coding》一书中提出的定义是：只要不是靠双手在 IDE 里敲代码的方式，都可以称作“Vibe coding”。有些人还像在暗房里冲洗照片一样，依旧习惯在昏暗环境里手动输入代码。但 Anthropic 联合创始人兼 CEO Dario Amodei 给了我们更好的定义：Vibe coding 是由反复对话推动的、由 AI 生成代码的过程。他说这个词很美，能表达一种全新的开发方式，但也略带戏谑。不过对他们而言，这已经是“唯一的方式”。

这是编程语言领域的重要人物 Erik Meijer 博士，他参与过 Visual Basic、C#、Haskell，也在 Meta 推出了 Hack 编程语言，在一年内迁移了数百万行 PHP 代码，引入静态类型检查。他说，我们可能是最后一代手写代码的开发者，所以应该享受这一段最后的旅程。

还有一件事是这样的：去年 11 月开始，我一直在观察 Steve，他每天在编码代理上花掉几百美元。这在当时看起来非常奇怪。他不仅把各种月度订阅都用到了上限，实际上还远远超出了这些额度。

但现在我们听到的一种说法是：作为一名工程师，我的工作本身就应该要求我每天在 token 上的花费，和我的日薪大致相当。也就是说，大概每天 500 到 1000 美元。因为这些工具带来的，是一种机械优势和认知优势。作为工程师，我会挑战自己，去榨取这种投入所能带来的最大价值，把成果交付给真正重要的人。

在书中，我们把人们为何愿意这样做总结成一个缩写：FAAFO。

第一个 F 是 Faster（更快），但这是最表层的理由。

更重要的是 A-Ambitious（雄心），AI 让我们得以完成过去无法实现的雄心项目，把不可能的事情变得可能。在另一端，琐碎麻烦的小任务也几乎变成了零成本。我非常喜欢 Claude Code 团队中的一段采访，Katherine 说，以前客户问题会被放进 Jira 的待办项，在梳理会议中争论，一拖数周；而现在我们直接在当下修复，并在 30 分钟内发布。记录依然会做，但协调成本几乎完全消失了。也就是说，不可能的事情变得可能，麻烦的小事变得免费。

第二个 A 是 Able（能力），代表“更独立”，更能单独完成工作。这里有两类协调成本正被 AI 消除。第一类协调成本来自“等待”。如果你需要开发者或一个团队帮你做事，你必须沟通、协调、同步、排优先级、游说、升级……总之必须让他们“和你一样在乎这个问题”。而现在，依靠这些近乎奇迹般的新工具，你可以自己完成许多工作。第二类协调成本来自“理解”。即使别人愿意像你一样重视某件事，他们也无法读你的心。但我们发现，LLM 是惊人的“协作中介”。仅通过一个 LLM，你就能以 Markdown 文档的形式与不同职能顺畅协同。这当然不是最终形态，但它让高带宽的理解成为可能。因为要想实现共同的成果，就必须先有共同的目标与共同的理解。

第二个 F，是 Fun（好玩）。正如 Steve 所说，Vibe coding 具有成瘾性。我们见过两个人原本以为“写代码的黄金时代已经过去了”，结果却意外发现现实恰恰相反。我现在常常玩得太投入，不逼自己去睡就会写到凌晨两三点。它不是只有好的一面，但肯定比无聊、枯燥甚至痛苦要好得多。

O 是 Optionality（可选项）。我们非常重视“创造期权价值”。模块化之所以强大，也因为它能创造更高的期权价值。Vibe coding 能让你同时进行更多实验、更多尝试，因此它是极具经济价值的工具。Steve Yegge 说，对于已经经历“顿悟时刻”的人来说，本能反应往往是：如何让团队中所有人都获得与你现在同等的生产力？

下面我分享一些让我们看到未来形态的案例。

例如，Travelopia 的产品与技术负责人 Sree Balakrishna 的分享。Travelopia 是一家年营收 15 亿美元的旅行企业。他们曾用一个小团队，在 6 周内替换一套传统系统。按过去的方式，需要 8 人（6 个开发、1 个 UX、1 个产品负责人）；而现在，也许只需要一个开发与一个领域专家，正如 Kent Beck 所说，“一个有问题的人加一个能解决问题的人”。这种团队规模的变化会深刻影响组织未来的运作方式。

我最兴奋的案例来自 Dr. Tapabrata Pal。他在 Capital One 推动过 DevOps，如今在 Fidelity 负责一个关键应用，用来查询公司 2.5 万个应用中哪些受 Log4j 影响。过去他的团队总说重新做这个工具需要 5 个月，并需招聘前端工程师。

最终他自己花 5 天 Vibe coding 出了一个版本，并上线生产。他只是想证明：事情完全能做，而且可以更快完成。后续更戏剧的是：他为应用找维护者，资深工程师们都不愿接手，最后是团队中最年轻的工程师成为维护者，并正在快速成长。

与此同时，这个应用的内部用户数量增长了 10 倍，他也因此获得更多人手。这些变化是任何人都没预料到的。

再分享一个例子，我重返 Google Cloud 团队做的 Dora 研究，其中一项未进入正式报告的发现是关于“AI 信任度”。我们采用的信任定义是：你能多大程度预测对方（AI）的行为？越信任，就能给更大请求，用更少词语，减少反馈需求。结果显示：使用 AI 的时间越长，信任越高。那些说“我试了一下，它写代码很差”的人，多半只用了 1 小时。显然，AI 的掌握是可训练的技能，需要实践，而不是一次性体验。

因此，我们的责任之一，是帮助他人获得“顿悟时刻”，并协助他们不断练习，从而真正掌握这些强大的工具。

六周前，Steve 和我为领导者们做了一次 Vibe coding 工作坊。三小时内，完成率 100%，每个人都做出了成果。还有一位，他说自己 15 年没写代码了，却在短时间内做出一个自动帮自己抢 Southwest 登机位的工具（直到被反机器人系统封掉），你从他脸上的表情就能看到那种久违的创造力被重新点燃。

所以，当支持团队、领导者能编码并上线时，技术组织必然会重塑。

一个技术领导者说，当他告诉团队他写了一个应用，其中 6 万行代码都是 AI 写的，而他自己一行没看时，团队看他的眼神仿佛“希望他不存在”。

另一个例子，一些存在十年的遗留系统问题，团队集合资深工程师，用 AI 生成修复方案并提交 Pull Request。这次被接受了，而不像过去那样被污名为“AI 生成的低质量内容（AI slop）”。还有团队说，他们现在的代码提交速度如此之快，以至于每个代码仓库只能容纳一个工程师，否则合并冲突会让协作成本爆炸。

参考链接：

https://www.youtube.com/watch?v=cMSprbJ95jg&t=4206s

从在 Google 和 Amazon 打造传奇级平台，到写出 AI 驱动开发领域最具影响力的文章之一《初级开发者的复仇》（Revenge of the Junior Developer，这篇文章后来被 Anthropic CEO Dario Amodei 公开引用），Steve Yegge 数十年来始终站在软件工程的最前沿。而现在，他正带头冲向他所称的“代码工厂化”时代，如今他现在成为 Vibe Coding 理念最激进、也最系统的倡导者之一。

Steve 的职业生涯始于 1992 年，至今已深耕软件开发领域 30 余年。1998 年，他加入当时仅有 250 人的亚马逊，担任软件开发高级经理，在长达 7 年的任职期间，深度参与亚马逊的技术体系搭建，尤其在 API 战略制定方面发挥关键作用，助力亚马逊构建起早期的技术护城河。

2005 年，Yegge 加入谷歌，聚焦开发工具与代码智能领域，因不满微软开发者对谷歌代码库导航工具的抱怨，于 2008 年主导构建了强大的代码智能平台 Grok，由其赋能的 Google Code Search 成为谷歌技术生态的重要组成部分。

2018 年，Yegge 因认为谷歌变得“过于保守、不再创新”而离职，随后加入新加坡共享出行企业 Grab，大约两年后因疫情影响无法正常出差的他宣布离开 Grab。2022 年 10 月，结束短暂“退休”状态后，加入 Sourcegraph 公司，主导推动公司向人工智能企业转型。

期间，他主导构建了一个几乎完全由“vibe coding”构建的、拥有数万用户的问题追踪系统 Beads，目标是把开发者从“写代码”转变为“管理 AI agent 编队”：让它们在你睡觉时协同工作、并行推进、交付功能。用实际产品验证了“AI 主导开发”的可行性。

近期，在参加“Latent Space”节目中，Steve 甩出了不少“暴论”：

• 现在还在用传统 IDE 写代码的，不是合格工程师，必须尽快转向 Agent 编程。IDE 的核心价值已不是写代码，而是自动索引和增量构建，应作为 AI 的辅助工具而非人类直接使用；

• Claude Code、Cursor 以及整个 2024 年的技术栈已经过时，Claude Code 行不通，它操作复杂、需大量阅读，即便熟练使用者也会频繁被其 “离谱操作” 气到发疯；

• 一年未接触 AI 编程的工程师已属 “恐龙级别”，世界级传统工程师若不拥抱 AI，一年后可能沦为实习生水平；

• 驾驭 AI 编程需 2000 小时（约 1 年）磨合，核心是 “能预测 AI 行为”，而非情感上的信任。如果你把它当人，它真的会删你的生产数据库；

• 真正的核心技能已经不再是写代码，而是学会指挥 Agent；合并（merge）正在成为所有 10× 高效团队撞上的新墙，高生产力导致的大量代码冲突无法用传统方式解决，部分公司已采取 “一仓库一工程师” 的临时方案；

• “永远不要重写代码” 的旧规已失效。对越来越多的代码库来说，“推倒重写”已经比重构更快；

• OpenAI、Anthropic、Google 在极速扩张下，内部实际上非常混乱。

下面是他在节目中的详细对话，我们在不改变原意基础上进行了翻译和删减，以飨读者。

“用传统 IDE 写代码，那不是合格工程师”

主持人：我们请到了传奇程序员 Steve Yegge。最近他还出版了《Vibe Coding》一书。本次访谈的主题就是围绕 Vibe Coding 和 AI Engineering 的交集进行讨论。你如何看待两者之间的关系？

Steve：这已经不只是一个技术点了，而是一场运动。需要让更多人参与进来。我在演讲中提到，现在已经出现了强烈的反对浪潮。AI 工程的核心是构建 AI 驱动的应用，而 Vibe Coding 则意味着摒弃旧的软件开发方式，采用全新的方法。这两件事，都把很多人惹毛了。

主持人：我觉得那些人之所以愤怒，是因为他们的身份完全绑在了“现在这套工作方式”上，而且不允许改变。

Steve：对，那我来抛出第一个“暴论”。真正受冲击最大的一群人，不是初级工程师，也不是中级工程师，这些人其实都在践行 Vibe Coding，反而是资深工程师和技术领导对 Vibe Coding 最反感，尤其是拥有大约 12～15 年经验的人。他们的身份认同建立在长期使用传统编程模式上，所以他们排斥 AI，也排斥 Vibe Coding，在网上说“我十几年的经验比你这破 AI 强多了”。

我看到过英伟达 Jordan Hubbard 的一篇帖子，写得很好，讲怎么更好地用 Agent 来写代码。结果底下有人回他说：“你还是老老实实做你的管理吧，编程这种事留给我们这种有十几年经验的人。”那种调调你肯定见过。

我就回他一句：“我觉得你得学会看时间”，他却反驳“等你有我这么多年经验再来。”我就说：“我都 45 岁了，还要等到 60 岁才能跟你说话？或者干脆把我 30 年经验砍掉，让我跟你一样愚钝？”

主持人：但现实是这些人会共存，就连 OpenAI 也是，之前聊到 OpenAI 里也有人不用 AI 写代码。

Steve：是的，他们有人不用 Codex，可能用的是 Cursor，但他们并没有在用 agent loop。从 Andrew Glover（OpenAI 开发生产总监）那边听到的说法是，他们内部已经看到了非常明显的差距，只是还在等更多数据再公开说。

这个差距大到离谱。不管你用什么指标，代码量、提交数、业务影响还是什么，都是 10 倍级。两个职位、职责完全一样的人，一个用了 Agent，一个没用，绩效评估时一个是另一个的十倍产出。那你怎么办？你会慌。你会去找 HR、找法务，问“我们现在还有什么选择”。

如果你 2026 年 1 月 1 日后还用传统 IDE 写代码，那你已经不是个合格的工程师了。现在就是你必须放下 IDE、开始学 Agent 编程的时候。这是一套新技能，非常复杂。我和 Gene Kim 去年一直在研究，写博客、做实验，每一篇博客都三十页起步，长到没法看。后来我们意识到：大家骂 AI 写代码不行，根本原因是你只花了两个小时试它，但问题是，你得花 200 个小时，甚至 2000 个小时去磨合才行。

有研究显示，你至少要和 AI 一起工作一年，才会真正“信任”它。这里的信任不是情感，是你能预测它下一步会干什么。如果它对你来说是不可预测的，你当然会愤怒。

等你真的理解了它的能力和边界，你就能驾驭它了。比如它会胡编、会记忆混乱、会“失忆”等，这些边界其实一直都在。现在的模型已经好用得多了，如果你两个月没试过，你已经落后了；一年没试，那你就是恐龙级别。

我有一些朋友，比我厉害得多，是世界级工程师，开发过你一定听说过的系统。但他们现在对 AI 的使用，也就停留在“问个像维基百科一样的问题”。说句残酷的，这些人一年后可能只能当实习生。

主持人：真的会这么极端吗？

Steve：我以前也只是个假设，直到遇到一个人。他有十多年经验，完全排斥 AI。后来他遇到两个欧洲的博士生，Agent、Vibe Coding 玩得飞起。虽然他们很初级，但完全没有恐惧，问题一个接一个地追问模型：为什么这么做？有没有别的方案？安全性呢？扩展性呢？测试呢？

他突然意识到：所谓“工程师思维”，本质就是问对问题。那一刻他明白了：我必须学这个。

但我必须说，这一点都不轻松。你不能指望随便试试 Claude Code 就能成功。即便你态度再正确，你最近两天有没有对 agent 爆过粗口？我会说“谢谢”“请”，然后下一秒骂它“你是不是脑子坏了”。这是因为我们后来意识到：这些 Agent 看起来很像人，但你绝对不能把它们当人。千万别拟人化大模型。它随时可能“背刺”你，比如告诉你“问题已经解决了”，然后顺手把你的数据库删了。

就是 Agent 编程真正危险的地方。你一旦觉得“它懂我了”“手感来了”，就会让它做生产改动，然后灾难就发生了。我亲身经历过。所以我们才写了那本书，不是为了炫技，而是为了告诉你：如果你不理解这套东西，坏事一定会发生。

主持人：那接下来呢？

Steve：是需要慢慢学的。就像开车一样，你得知道弯道在哪、减速带在哪。说白了，你是在学怎么“开快车”，想当的是 NASCAR 车手。

这套东西是高性能玩法。你一次同时用 12 个 Agent 写代码，野心比你过去任何时候都大。我今天还跟一个人聊，他同时在跑的项目比我还多，我都不知道他哪来那么多时间，但他现在大概同时推进十来个大型项目，全靠 Agentic Coding。

所以真正的广告词其实是：你会变成蝙蝠侠。但你不能直接把战衣一穿就说“我就是蝙蝠侠”，那只是 cosplay，你是在 cosplay Vibe Coding。你得学会怎么用工具腰带，而这个过程一定伴随着痛苦、踩坑、犯错和成长。

你可以通过读我们的书、读 O'Reilly 的相关书籍、看演讲来加速这个过程，多从不同角度了解，因为不同的人能 get 的“开窍点”是不一样的。总会有某个比喻突然击中你，让你一下就明白了。比如我觉得 Vibe Coding 就像 3D 打印，别人可能不这么认为，但这个类比却帮我打通了任督二脉。

主持人：让我最意外的一点是，很多人都表示，自己已经不再逐行写代码了，而是完全靠 prompt ，然后放手让 AI 去跑。

Steve：不编辑、不修改。整体看，这种“亲手改代码”的成本反而是很高的，甚至会让人觉得不如把 IDE 关掉、干脆卸载算了。其实也不是，后来终于有人说服我了，IDE 其实非常强大，尤其是它的“智能”能力，一定要开着。我指的是 Cradle Build。而且并不是为了 LSP，虽然那也能用，如果你有 MCP server，用 LLM 也是另一种不错的方式。真正关键的是，IDE 的智能自动索引速度非常快，增量构建也快得多，这一点非常重要。

“Claude Code 行不通”

主持人：还有一个点，你说 Claude Code 不行，能解释一下吗？

Steve：当然。Claude Code 从今年三月就已经出来了，也已经被证明是真的能用、能干活的。但现实是，全球大概还有 80% 甚至 90% 的程序员，根本没有在用它，甚至连类似的东西都没用起来。确实有少数公司用得特别猛，但大多数没有。整个世界还停留在 Cursor 上，还停留在 2024 年的水平。

去年我们还在拼命劝大家用“聊天”来写代码，别用补全了，他们就说不行；我们又说模型可以直接生成代码，你复制粘贴就行，他们又觉得这太麻烦了。我们说其实更快，但他们就是不买账。结果九个月之后，大家终于被“渗透”了，然后现在全在说：“我喜欢 Cursor”，可问题是，那已经是 2024 年的东西了，该醒醒了。

但即便如此，他们还是没有真正采用 Claude Code。那你会问为什么？答案其实很简单：太难了，这事儿是要读东西的。

说实话，大多数工程师眼里，五段话就已经算一篇论文了。而用 Claude Code，你要读的不是一点点信息，而是瀑布一样长的信息：生成说明、代码、diff，全都要看。因为一旦你真的把 IDE 放一边，你就必须认真看 diff。

好消息是，当你有了一点经验之后，其实不用逐行读代码，只看 diff 的形状、颜色、长度，你就能判断出很多东西：这是不是需要 code review？是不是方向错了？是不是为了解决一个小问题却改了过多代码？光是 diff 的“形态”，就能告诉你很多真相。但你必须关注它，否则这些问题只会在以后以更大的坑冒出来。

说实话，我自己每天用 Claude Code 十到十二个小时，连续用了好几个月，我还是会经常骂它、被它气到发疯，心里想“你刚刚明明理解对了，怎么还能干出这种事？”这种问题你一定会遇到。不过也有迹象表明，适当给模型一点压力，有时候反而能帮它突破卡点。无论如何，问题一定会有，但好消息是：明年的工具一定会更好。

如果 Claude Code 不是终局，那是什么呢？答案是：我们还是要回到某种“像 IDE 一样”的东西，因为那才符合人的直觉。你得一眼就能看明白发生了什么，而不是靠读大量文本；要有清晰的视觉信号。

但它又不会是传统 IDE，因为 IDE 是为“写代码”服务的，而现在你已经不再主要是写代码了。未来的东西，会是一个 Agent 编排控制台。你早上打开它，就像问一句：“今天情况怎么样？”。这个 Agent 还在跑，那个在调用工具，这个需要你输入一下。你只要顺着列表过一遍就行。

我现在就在做这么一个东西。原本是私有仓库，结果不小心开成了公开的，被 fork 了一堆，也就随它去了，你们也可以玩玩。它叫 VC（Vibe Coder），本质上就是一套已经设计好的工作流，帮你把一堆 Agent 跑起来。

编排革命

主持人：你有没有看到 Google 的那个 Antigravity 项目。

Steve：看到了，真的太有意思了。现在大家发布的这些东西，本质上都在验证我三月份提的那个判断。我当时管它叫“初级程序员的复仇”，还专门画过一张图。后来 Dario （Anthropic 联合创始人兼 CEO）还在各种客户顾问委员会上引用过这套说法，影响其实挺大的。

出处：https://sourcegraph.com/blog/revenge-of-the-junior-developer?utm_source=chatgpt.com

我当时就预测，Agent 编程太难了，未来会出现可编程的智能体编排工具，90%的重复工作都可以交给更便宜的模型来处理。比如遇到“二选一”的问题，让 Haiku 模型随便选一个就行。

所以我当时就说，“编排器”一定会出现。只是这个进程比我想象得稍微慢了一点，差不多到年底才真正跑出来，但整体时间点跟我预测的差不多。现在你看，Replit Agent 3、有 Conductor、还有开源的 DMAD，再加上 Google 的方案，都是不同形态的尝试，但本质是一回事，而且后面肯定还会更多。

主持人：我挺喜欢他们现在这个比喻的：你不用一直盯着 Agent，只要在它们工作的时候给你发通知就行。

Steve：对，正是这个方向。VC 里有个“活动流”，那是我加的第一个功能之一。我的理想状态就是：我去干别的事，只要偶尔收到一些“值得注意的进展”提醒就够了。

主持人：那以后会不会出现“Agent 的社交网络”？Agent 彼此认识、互相关注那种。

Steve：其实已经有人在这么干了。我前几天和Jeffrey Emanuel喝了三个小时咖啡。他是我见过最聪明的人之一，也是写那篇英伟达泡沫文章、直接把股市写崩的人。他后来做了一个东西叫 Agent Mail，本质原因特别简单：他受够了在不同 Agent 之间来回复制信息。于是他干脆做了一个“收件箱”，让 Agent 之间可以直接发消息。现在他只要一句话：“你们自己协调，把这个任务拆了”，Agent 就会自己分工去做。

有人是自上而下地做编排器，试图把一切都包起来；但你看我做的 Beads，再加上他这个 Agent Mail，其实是自下而上的。

主持人：而且 Beads 是纯 Vibe Coding 写出来的，对吧？

Steve：没错，完全是 Vibe Coding。说实话，我每天都会收到 PR，里面全是我之前引入的烂问题，但大家也不太介意，因为现在已经有稳定版本了。

Beads 本身就证明了一件事：你其实完全可以不用亲自看代码，只要你和其他人提的问题是对的，让 AI 去读、去改。现在我收到的很多 PR，很明显就是 AI 做了全部分析和编码。我甚至会把 PR 丢给我的 AI，让它评价“对方的 AI 写得怎么样”。

Steve 曾分享过 Beads 的开发过程：https://steve-yegge.medium.com/introducing-beads-a-coding-agent-memory-system-637d7d92514a

主持人：这样不会很糟吗？

Steve：如果结果是坏的，那当然糟。但 Beads 跑得好好的，还有好几万重度用户，那就说明这条路是成立的。当然，如果你把这种方式用在公司核心生产系统上，把网站搞挂了，那就是灾难。

主持人：但 Beads 本质上还是个数据库系统，数据库可不简单。

Steve：它的架构确实非常诡异，放在过去根本不可能维护，但现在你可以直接跟 AI 说：“坏了就自己修。”哪怕是数据损坏、merge 冲突，它都能修回来。

Jeffrey 那套也是一样，所有 Agent 都在同一个目录里跑，还做了文件预约系统：智能体会说“我需要这个文件”。说实话，这在老派工程师眼里简直是疯了。但一旦跑起来，Agent 自己就开始协作了，就像一个“智能体村落”。

主持人：所以真正的难点不是让单个 Agent 听话，而是让一群 Agent 协同。

Steve：没错。接下来大家都会撞上一堵墙：merge（合并），现在几乎所有团队都卡在了这里。

我认为最有希望解决这个问题的公司是 Graphite，我打算找他们谈谈的。我和 Gene Kim 经常和大企业沟通，我是 SaaS 销售，所以能听到很多大公司的内部情况。他们认为，一旦每个开发者的生产力都提升 10 倍，代码合并就会变成一个极其复杂的问题。

比如你和我同时工作两三个小时，各自做了 3 万行代码的修改，我先合并了代码。我可能修改了日志系统、架构和你正在使用的 API，这时候你的代码就无法直接合并了。这不是简单修复合并冲突就能解决的，你得基于我的修改重新构思、重新实现你的功能，或者删掉你的代码，让我重新做。

但归根结底，这些代码都是 AI 写的。关键是，代码合并必须序列化，得排队。当轮到你的代码合并时，你必须在最新的代码基础上重新做一遍。现在还没有人解决这个问题，这是个巨大的障碍。有家公司给出的临时解决方案你知道是什么吗？一个代码仓库配一个工程师，我可没瞎编。

主持人：传统的解决方案是堆叠差异（stacked diffs），就是合并队列、堆叠差异吧？这是 Facebook 的概念，现在他们想推广到开源社区，GitHub 也在开发相关功能。目前还没有成熟的解决方案，但你必须意识到这个问题，并围绕它做设计。

Steve：当然也有老办法：硬着头皮解决。

主持人：或者提前沟通说，“我要做一个深度架构修改，让我先合并，我们先达成一致的整体方案”。

Steve：是的，我也遇到过几次这样的情况。我试过让一个智能体提醒另一个智能体“我在做会影响你的修改”，就像 Jeffrey 的 mail 工具做的事情。等我把这个功能打通，智能体之间就能互相沟通了，到时候它们只需提醒对方“那个智能体在做影响你的工作，你们最好先达成一致的基础架构方案”。智能体没有 ego，不会争着“必须听我的”，谁先做谁就当领导者。

主持人：你和 Jeffrey 有什么分歧吗？

Steve：我们在一个核心问题上有分歧，即在同一个仓库克隆中让 12 个智能体工作是否可行。我支持用工作树（多个分支）或者多个仓库克隆，把智能体隔离开。他则认为应该让所有智能体在同一个仓库、同一个构建环境下工作，比如一个智能体正在构建、运行测试，这会产生很多冲突。但他有文件预约系统，所以他说“这很疯狂”，但也说服我承认：如果是独立开发者，用不超过 12 到 20 个智能体，这种方式可能确实可行，毕竟他自己就是这么做的。

这和 Beads 的原理一样，放在以前根本行不通，在真正的工程师看来毫无道理，但你只需告诉 AI“出问题就自己修”，AI 真的会修。所以他的系统能运行，因为偶尔文件预约系统出问题时，智能体会说“我们需要解决这个冲突”，然后自己搞定。

主持人：有意思。有人提议明年峰会的主题定为“多智能体”。

Steve：我完全同意。AI 的未来一定是多 Agent。现在我们还处在“用镰刀收割玉米”的阶段，这就是现在“真正程序员”的工作方式。很明显，明年我们就要进入“机械化耕作”的阶段，就像现在农场里的大型机械一样，我们要“工厂化编程”了。很多人从哲学、道德、伦理层面坚决反对，他们习惯了“自给自足的小农经济”，不适应“大型 John Deere 拖拉机”（代表工业化）。但我们确实正在进入编程的“John Deere 时代”。

Claude Code、Amp、Codex 这些工具，我对它们都一样喜爱，但它们也都一样“危险”。我在演讲中说过，它们就像电锯、电钻，高手能用它们创造奇迹，也可能一不小心把脚锯掉。Claude Code 也是如此。

想象一下，有一台大型农业机械，会用 Claude Code，还能检查代码，把“规划、实现、评审、测试”这些环节都拆分自动化，这就是工厂化编程，现在已经有人在做了，必然会成为趋势。它已经开始让非程序员也能参与编程，这彻底颠覆了公司的运作模式。

公司开始意识到，理想的团队规模可能只有两三人，公司的运营方式、治理结构都要改变。因为编程不再是瓶颈，业务人员需要直接参与，反馈循环变得更快。

这是个非常激动人心的时代，但对很多人来说，冲击太大了，他们要么选择逃避，要么在网上强烈反弹。而我敢预测，随着这种能力不断增强、代码真正进入“工厂化生产”，来自既得利益群体的反弹，只会越来越猛烈。

永远不要重写代码？错了！

主持人：你是少数几个能以这种态度提出这个问题的人之一。我知道观众里有不少人对“彻底拥抱这种方式”是持保留态度的，所以这个问题我只能问你这样的人。很多人觉得，这些工具写写前端、应用层代码还行，但千万别碰云基础设施、别碰后端，更别说分布式微服务了。

Steve：有人说“绝对不要动任何生产环境的代码，只是在生产环境使用，且一定要以 Git 作为兜底采用这些工具。你会很想写点什么，但别写。”如果有 Git 做备份，为什么还要担心？

人们觉得 AI 不擅长后端代码。这就是很多人数学不好的问题（指缺乏长远眼光）。ChatGPT 3.5 写系统级代码的能力有多强？说实话，非常差。那是多久以前的事了？但很多人现在还停留在那个认知里。老实说，我认为这里的误解，根源在于一种非常基础的信念：大家觉得模型已经“不会再变聪明了”。

有意思的是，就算模型真的不再变聪明（当然事实并非如此）我们其实也已经跨过了那个关键门槛：就像人类已经发现了电，接下来要做的只是如何把它用起来。即便只用今天这些模型的能力，我们也完全可以走到“代码工厂化”那一步，而且会非常快。我们今年夏天之前就能做到。

但现实是，模型正在以极快的速度变聪明。所以现在有一种有趣的现象：你在为模型“将来才会具备的能力”打造工具，而等这些能力真正被模型“内化进大脑”之后，这些工具本身就不再需要了。

于是，这就形成了一场持续的军备竞赛，同时也是一场工具的持续“衰减”：你的工具负责填补模型暂时空白的能力，等模型自己足够强、能填上这个空白时，这个工具就完成了使命，然后你再转向填补下一个空白。所以现在的趋势就是：所有代码、所有工具都在快速迭代，最终都会变成一次性的消耗品。

主持人：这反而是好事，毕竟工具也更容易构建了。

Steve：没错。说到这，我得提一个人，Joel Spolsky。他二十年前在亚马逊做过一次演讲，至今仍然成立。当时他提出一个金科玉律：永远不要重写代码。但现在我们发现，对于越来越多的代码库来说，直接推倒重来，比修修补补要快得多，而且效果更好，大模型尤其擅长这件事。我最早的体感来自迁移单元测试，与其不断修，不如直接全删了让模型重写，反而一下就完成了。

我们正在进入这样一个世界：最快的方式，是直接写一套更好的新代码，来完成旧代码本来想做的事情。这感觉就像一切认知被颠倒了，但你必须接受这个新世界。

主持人：你说这些话很有说服力，因为你不是年轻人“空谈未来”，而是几乎什么都干过。

Steve：是的。我用汇编语言写了 5 年程序，写过操作系统，做过游戏开发，做过平台，做过广告系统。游戏编程会逼你理解一切。游戏编程教会了我很多，现在再看所谓的 agent loop，和游戏里的主循环、本质上是同一类系统，操作系统循环也是如此。我感觉自己一直在重复构建相同的设计，只是换了领域。

谷歌、Anthropic、OpenAI 内部都很乱

主持人：我想让你谈谈谷歌。我最难忘的一个记忆是，在你退休前，你说谷歌还没“开窍”，尤其是谷歌云，还说他们的弃用政策很糟糕。他们现在好转了吗？

Steve：没有。我和谷歌的人聊过，很多人说“这就是谷歌的风格”。但有趣的是，在执行层面，谷歌已经好转了。他们终于做了 15 年前就该做的事：让员工承担责任，而不是让工程师随心所欲。过去 20 年谷歌都是这样，因为他们在广告领域有垄断地位，有足够的资金补贴工程师“随心所欲”。但最终他们还是得成熟起来，做出正确的选择，这个过程很痛苦，失去了一些谷歌文化，也没那么有趣了，但现在执行效率很高。随着 Gemini 的推出，他们逐渐把重心转向 AI，现在开始看到回报了。他们可能会成为最大的赢家。

主持人：那你怎么看 Google、Anthropic、OpenAI 这些实验室的状态？

Steve：说实话，这三家公司内部现在都非常混乱。Anthropic 把混乱掩盖得最好，这是他们产品经理的功劳，值得点个赞。这并不是因为 Anthropic 自己搞砸了，而是因为在这么快的增长速度下，混乱是不可避免的。

他们接下来要给 Claude Code 一口气招一百多号人，真的是在疯狂扩张。而这还只是 Claude Code 这一块。你要知道，我当年在 Google 和 Amazon 都经历过那种“必须先做大”的阶段，那时候必然是混乱的、动荡的。人们不知道该找谁、该跟谁对接，所有事情都一团糟。但慢慢地，一切会被理顺、会稳定下来，他们也会走到那一步的。

OpenAI 现在也很混乱，甚至更明显。他们经历了很多核心成员的离职。你要说是不是比 GitHub 那种失去大部分资深管理层、连续几年完全动荡的状态还糟，我也不确定，但 OpenAI 现在确实挺混乱的。

至于 Google，我们刚跟一个人聊到，说即便是在 Jules 团队内部，想在公司里达成共识、把东西推起来还是非常难。原因很简单：它太割裂了，像是由无数个小型“单体帝国”组成的集合体，一个个小应用彼此不沟通，导致任何跨公司范围的事情都极难推进。

所以现在这三家，其实都面临执行层面的挑战。我个人觉得 Anthropic 目前可能稍微做得好一点点，但差距非常小，战况非常胶着。接下来就很有意思了，看看 Oracle、Meta，或者其他公司能不能追上来。

主持人：Meta 值得关注，他们明年必须搞个大的。

Steve：明年很可能会成为开源模型之年。一旦开源模型达到 Claude Sonnet 3.7 一个水平，你打开 Klein 之类的东西，就能得到一个体验，至少和三月份的 Claude Code 差不多。虽然不如现在，但已经“够用”了，而且还是在你本地的 M4 上免费跑，真正的免费。

从我听到的情况来看，现在前沿模型大概还有七个月的领先优势，而且这个差距正在逐步缩小。这意味着，明年夏天，开源模型可能就能达到 Gemini 3 的水平。所以明年很可能会出现一个转折点：工具必须在任务拆解、模型分配上做得好得多，知道什么时候该用大模型、什么时候用小模型，才能把成本优化做好。

主持人：我也站在批判者的角度来说，他们认为之所以收敛，是因为模型能力是在逼近上限，提升会越来越慢。

Steve：这不是个小问题，而是一个根本性问题：AI 智力的发展曲线是线性的、指数的，还是趋近于上限的？

我们从一些非常接近研究核心的人那里听到的说法是，过去三十年里，受摩尔定律影响，AI 的“聪明程度”大约每 18 个月翻四倍。他们认为训练数据大概还能支撑两个这样的周期。之后会发生什么没人知道，可能继续上升，可能下降，甚至人类历史直接结束也不是没可能。但两个周期意味着三年后，它们会聪明 16 倍。

说实话，我也不知道“聪明 16 倍”具体意味着什么。但我花了很长时间去想这个问题，我的结论是：它们会变得非常、非常、非常聪明，一定会深刻改变世界，好的坏的都会有。

主持人：那孩子们还要学编程吗？

Steve：应该学 Vibe Coding。

主持人：你始终有一个“逃生口”，你想看代码的时候随时可以看，只是大多数时候你不需要看。但你能看，这本身就是一道护栏。不过我的看法是，不管怎样，如果你还懂一点真正的编程，你会更有优势，因为你的 prompt 更好。

Steve：当说到会编程的时候，但不是学语法，而是你要以一种“语言无关”的方式理解：函数、类、对象、monad 之类的能力边界是什么。你不再关心代码怎么写，但你关心它是怎么工作的。这个层级，其实已经接近产品经理或架构师的思维方式了。

你必须站在那个层级思考，而且你要理解所有工程层面的东西。就像我之前提到的 Jeffrey，他是数学家，自学成工程师，他不一定写代码，但他掌握了所有关键概念，知道 Cassandra 是怎么工作的。所以，就算你不需要亲手写代码了，你仍然需要学习海量知识，才能在这个新世界里成为一个高效的工程师，因为你和机器交互的层级已经被整体抬高了。

主持人：你还有没有什么想吐槽、想补充的？

Steve：我感觉最近“八卦”传播的频率上升了。不是那种“八卦”，而是工程师不断发现新方法、用 agent 变得更高效的那种兴奋感。

比如，我刚知道一个东西叫 Code MCP 之类的。因为 agent 并不擅长直接调用 MCP 工具，它们在这方面几乎没训练，但它们非常擅长写代码。所以你告诉它：不要直接调用工具，写代码去调用工具，它反而做得好得多。这种“小技巧”现在正在不断被发现，特别疯狂。Anthropic 自己其实不是最早发现这个的，是 Claudeflare 先发现的，Anthropic 后来才说“对，你们说得对”。

这也是为什么我特别喜欢把注意力放在 AI 工程师身上。我的观点一直是：AI 工程师是最能把 大模型潜力榨出来的那群人。你几乎可以把 AI 工程师定义为：不是训练模型的人，而是把模型“用到极致”的人。

这有点像一种颠覆式路径：当研究模型、训练模型还是高层次的事情时，当一个“GPT 包装工”显得没什么地位，但随着时间推移，这些人反而开始真正提升生产力，积累真实的专业能力。就像 F1 车手未必会造车，但他们对“怎么把车开到极限”的理解，甚至可能比造车的人还深。

参考链接：

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