写在前面
大家好，我是源码七号站的技术分享者。今天想和各位聊一个可能会颠覆你认知的话题：传统编程方式真的要被淘汰了吗？
最近，硅谷资深工程师 Steve Yegge 在一档播客节目中抛出了一系列"惊人言论"，引发了整个开发者社区的激烈讨论。作为在 Google、Amazon 工作超过 20 年的技术老兵，他的观点值得我们认真思考。
这篇文章会比较长，但我会尽量用通俗易懂的语言，带你全面了解这场正在发生的 AI 编程革命。
一、一位技术老兵的预言
1.1 Steve Yegge 是谁？
在开始正式讨论之前，让我先介绍一下这位"炸场"的主角。
Steve Yegge 不是什么新手程序员，而是一位从 1992 年就开始写代码的资深工程师。他的履历堪称传奇：
- 1998-2005：在亚马逊工作 7 年，当时亚马逊只有 250 人。他参与构建了亚马逊早期的技术体系，尤其在 API 战略制定方面发挥了关键作用
- 2005-2018：在 Google 工作 13 年，主导构建了著名的代码智能平台 Grok，Google Code Search 就是基于这个平台
- 2022 至今：加入 Sourcegraph，主导公司向 AI 企业转型
他还写过一篇极具影响力的文章《初级开发者的复仇》，连 Anthropic CEO Dario Amodei 都公开引用过。可以说，这是一位真正理解软件工程本质的技术大师。
1.2 那些"惊人暴论"
在最近的访谈中，Steve 提出了一系列颠覆性观点。在源码七号站看来，这些观点虽然激进，但并非空穴来风：
关于工具选择：
- 2026 年后还在用传统 IDE 写代码的，不能算合格工程师
- Claude Code、Cursor 以及整个 2024 年的技术栈已经过时
- IDE 的价值不再是写代码，而是作为 AI 的辅助工具
关于学习成本：
- 掌握 AI 编程需要 2000 小时（约 1 年）的深度实践
- 核心不是"信任" AI，而是能准确预测它的行为
- 一年未接触 AI 编程的工程师已属"恐龙级别"
关于技能转变：
- 最受冲击的不是初级工程师，而是 12-15 年经验的资深工程师
- 世界级传统工程师若不拥抱 AI，一年后可能沦为实习生水平
- 真正的核心技能不再是写代码，而是指挥 Agent
听起来是不是很夸张？别急，让我们一步步拆解这些观点背后的逻辑。
二、为什么传统 IDE 不再适用？
2.1 编程范式的根本转变
要理解为什么 IDE 不再适用，首先要明白：我们现在做的事情，本质上已经不是"写代码"了。
传统编程流程是这样的：
- 思考解决方案
- 打开 IDE
- 敲代码实现
- 调试修改
- 提交代码
而 AI 编程时代的流程变成了：
- 描述你想要什么
- AI 生成代码
- 检查生成结果
- 调整指令让 AI 修改
- 验证并提交
看出区别了吗？你的角色从"代码编写者"变成了"需求描述者 + 代码审查者"。
2.2 IDE 的新定位
Steve 强调，IDE 并不是完全没用，而是用途发生了根本改变：
传统用途（已过时）：
- 代码编辑器
- 语法高亮
- 代码补全
新时代用途：
- 自动索引代码库
- 增量构建系统
- 为 AI 提供上下文信息
简单说，IDE 从"给人用的工具"变成了"给 AI 用的辅助系统"。这就像汽车从马车进化而来，虽然都叫"交通工具"，但驾驶方式已完全不同。
2.3 实际案例：从怀疑到信服
文中提到一个很有意思的案例。有位拥有十多年经验的资深工程师，完全排斥 AI 编程。后来他遇到两个欧洲博士生，这两位虽然经验很浅，但熟练使用 Agent 和 Vibe Coding。
这两位博士生的工作方式是：不停地向 AI 追问
- 为什么要这么做？
- 有没有别的方案？
- 安全性怎么样？
- 能扩展吗？
- 测试覆盖如何？
这位资深工程师突然意识到：所谓"工程师思维"，本质就是提出正确的问题。而这一点，使用 AI 的人反而做得更好，因为他们可以更快速地探索各种可能性。
从那一刻起，他明白了：必须学习这套新方法。
三、Claude Code、Cursor 为什么"过时"了？
3.1 Claude Code 的问题
很多人可能会问：Claude Code 不是很强大吗？怎么就过时了？
Steve 的解释是：不是能力过时，而是使用方式过时。
Claude Code 从 2024 年 3 月就发布了，确实能干活。但问题在于：
- 操作复杂，需要阅读大量信息
- 生成说明、代码、diff 全都要看
- 即便是熟练用户，也经常被它的"离谱操作"气到发疯
- 全球 80%-90% 的程序员根本没真正用起来
用 Steve 的原话说："即便我每天用 Claude Code 十到十二个小时，连续用了好几个月，我还是会经常骂它。"
这听起来很真实，对吧？在源码七号站的实践中，我们也遇到过类似问题。
3.2 真正的难点：信息过载
为什么 Claude Code 难用？核心问题是：信息量太大。
Steve 说得很直白："大多数工程师眼里，五段话就已经算一篇论文了。"而用 Claude Code，你要读的是：
- 瀑布一样长的生成说明
- 大量的代码改动
- 详细的 diff 对比
虽然有经验的人可以通过"diff 的形状、颜色、长度"快速判断问题，但这本身就需要大量练习。
3.3 未来会是什么样？
Steve 认为，未来的工具会是：Agent 编排控制台。
想象一下，你早上打开电脑，看到的不是代码编辑器，而是一个任务管理界面：
- 这个 Agent 正在实现用户登录功能
- 那个 Agent 在优化数据库查询
- 另一个 Agent 需要你确认一下架构方案
你要做的就是：
- 看看哪些任务完成了
- 检查哪些需要你介入
- 分配新的任务
- 继续干其他事
这就像管理一个团队，而不是亲自写每一行代码。
四、2000 小时定律：为什么需要这么长时间？
4.1 不是学语法，是学相处
很多人误以为，学习 AI 编程就是学几个提示词（prompt）技巧。但 Steve 强调：你需要的是 2000 小时的深度磨合。
为什么需要这么久？因为你要学会的不是"怎么用工具"，而是：
- 预测 AI 的行为：知道它会在哪里出错
- 理解能力边界：什么能做，什么不能做
- 掌握沟通技巧：如何描述需求才能得到想要的结果
- 应对意外情况：当 AI 出错时如何快速修正
这就像学开车。考驾照可能只要几十小时，但真正成为老司机，需要几年的实际驾驶经验。
4.2 信任 ≠ 盲目依赖
研究显示，你至少要和 AI 一起工作一年，才会真正"信任"它。但这里的信任不是情感上的信任，而是：
"你能预测它下一步会干什么。"
Steve 特别警告：千万不要把 AI 拟人化。
他亲身经历过：有时候 AI 会说"问题已经解决了"，然后顺手把生产数据库删了。如果你真把它当人，觉得"它懂我了"，就会放松警惕，然后灾难就发生了。
正确的态度是：
- 保持警觉和验证
- 理解它的工作原理
- 知道在哪些场景下可以信任，哪些场景必须小心
4.3 那些"恐龙级"工程师
Steve 提到一个残酷的事实：一年未接触 AI 编程的工程师已属"恐龙级别"。
他举了个例子：一些世界级的传统工程师，开发过你肯定听说过的系统，但现在对 AI 的使用还停留在"像查维基百科一样问个问题"。
他的预测很直白：这些人一年后可能只能当实习生。
听起来很极端？但想想看：
- 如果你的同事用 AI 的产出是你的 10 倍
- 如果你的工作方式还停留在一年前
- 如果新入职的年轻人已经熟练掌握 Agent 编程
这个差距确实是致命的。
在源码七号站的观察中，我们已经看到了这种趋势：那些率先拥抱 AI 工具的开发者，工作效率确实有了质的飞跃。
五、Vibe Coding：不是炒概念，是新范式
5.1 什么是 Vibe Coding？
Vibe Coding 不是一个具体的工具，而是一种全新的编程思维方式。
传统编程：
- 我知道要写什么代码
- 我逐行实现功能
- 我调试修复 bug
Vibe Coding：
- 我描述想要什么结果
- AI 生成实现方案
- 我验证和指导调整
Steve 用了一个很形象的比喻：这就像从手工收割玉米，进化到使用大型收割机。
很多人从哲学、道德、伦理层面反对这种方式，因为他们习惯了"自给自足的小农经济"，不适应"大型工业化生产"。但这就是趋势。
5.2 为什么资深工程师最抗拒？
这里有一个有趣的现象：最抗拒 Vibe Coding 的，往往是拥有 12-15 年经验的资深工程师。
原因很简单：
- 他们的身份认同建立在"我会写复杂代码"上
- 他们花了十几年掌握的技能似乎被贬值了
- 他们在网上说"我十几年经验比你这破 AI 强多了"
Steve 遇到过这样的回复。有人说："你还是老老实实做管理吧，编程留给我们这些有经验的人。"
他的回应很犀利："我都 45 岁了，还要等到 60 岁才能跟你说话？或者干脆把我 30 年经验砍掉，让我跟你一样愚钝？"
这不是技术之争，而是认知之争。
5.3 初级工程师的"复仇"
Steve 写过一篇文章叫《初级开发者的复仇》（Revenge of the Junior Developer），核心观点是：
AI 时代，反而是初级工程师受益最大。
为什么？因为：
- 他们没有包袱，敢于尝试新工具
- 他们不会被"传统做法"束缚思维
- 他们更愿意花时间学习如何与 AI 协作
在 OpenAI 内部，已经出现了明显的差距：使用 Agent 和不使用的工程师，产出差距达到 10 倍。
想象一下，两个职位、职责完全一样的人：
- 一个用了 Agent，完成了 10 个功能
- 另一个没用，只完成了 1 个功能
绩效评估时，HR 和管理层会怎么想？
六、Agent 编程：未来已来
6.1 什么是 Agent 编程？
如果说 Vibe Coding 是思维方式，那 Agent 编程就是具体实践。
简单说，Agent 是一个能够自主完成任务的 AI 智能体。你给它一个目标，它会：
- 分析任务
- 制定计划
- 执行步骤
- 遇到问题时自己调整
- 最终交付结果
更厉害的是：你可以同时运行多个 Agent，让它们并行工作、相互协作。
6.2 多 Agent 协作：像管理一个团队
Steve 正在开发的 VC（Vibe Coder）系统，就是一个 Agent 编排控制台。
想象这样的场景：
- Agent A 负责实现前端界面
- Agent B 负责后端 API
- Agent C 负责数据库设计
- Agent D 负责写测试用例
它们同时工作，遇到需要协调的地方会互相通知。你要做的就是偶尔看看进度，确认一些关键决策。
这就像你在管理一个团队，而不是单打独斗。
6.3 实际案例：Beads 系统
Steve 开发了一个叫 Beads 的问题追踪系统，完全用 Vibe Coding 构建，现在有几万用户。
最神奇的是：他自己基本不看代码。
- 收到 PR（代码提交请求）时，他会把 PR 丢给 AI
- 让 AI 分析"这个改动怎么样"
- AI 评价完，他决定是否合并
- 如果有问题，让 AI 去修
这在传统工程师看来简直疯了，但系统运行得很好。
Steve 说："很多 PR 很明显就是 AI 做了全部分析和编码。我甚至会让我的 AI 评价'对方的 AI 写得怎么样'。"
这就是未来的协作方式。
七、新世界的新挑战
7.1 合并地狱（Merge Hell）
当每个开发者的效率都提升 10 倍时，一个新问题出现了：代码合并变成了噩梦。
想象这样的场景：
- 你和同事同时工作 2-3 小时
- 你各自做了 3 万行代码的修改
- 你的同事先合并了代码
- 他可能改了日志系统、架构、你正在用的 API
这时候，你的代码就无法直接合并了。你不是简单修复冲突，而是要基于他的修改重新构思、重新实现。
问题是：这些代码都是 AI 写的。那怎么办？让 AI 重新生成一遍？
7.2 临时解决方案
一些公司给出的临时方案是：一个代码仓库配一个工程师。
这听起来很疯狂，但目前确实有公司在这么做。因为当产出提升 10 倍时，传统的协作方式彻底失效了。
7.3 未来的解决方向
Steve 认为，解决方案会是：
- 智能 Agent 之间的通信：Agent 可以互相告知"我在做会影响你的修改"
- 自动化的合并策略：AI 自己判断如何合并代码
- 工作流编排：在代码生成之前就规划好架构，避免冲突
这方面，Graphite 等公司正在探索新的方案。但这确实是整个行业都在面临的挑战。
在源码七号站的实践中，我们建议：
- 增加代码 review 频率
- 采用更细粒度的任务拆分
- 使用 feature flags 隔离变更
- 尽早合并，避免长时间分支
八、重写 vs 重构：游戏规则改变了
8.1 Joel Spolsky 的金科玉律
软件工程界有一条著名的规则，来自 Joel Spolsky（Stack Overflow 创始人）：
永远不要重写代码
理由很充分：
- 重写会丢失多年积累的 bug 修复
- 重写风险极大
- 重构总是更安全的选择
这条规则统治了软件行业二十多年。
8.2 新时代的新规则
但 Steve 发现：对于越来越多的代码库，直接推倒重来比修修补补更快。
为什么？因为：
- AI 可以快速理解旧代码的意图
- AI 可以用更好的方式重新实现
- 重写的成本大幅降低
Steve 最早的体感来自迁移单元测试：
- 传统方式：一个个修改测试用例，耗时耗力
- AI 方式：全部删除，让 AI 重新生成，反而一次成功
他说："我们正在进入这样一个世界：最快的方式，是直接写一套更好的新代码。"
8.3 这意味着什么？
这个转变的意义深远：
- 技术债不再那么可怕
- 重构成本大幅降低
- 可以更频繁
