虽然我并不认同“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
