看完 Steve Yegge 这期访谈，我更确定：AI 淘汰的不是程序员，而是旧开发方式
阅读时间：4 分钟
这篇文章，是我看完一条 YouTube 访谈之后，忍不住想写下来的。
最近我刷到 Steve Yegge 的一场长谈。
老实说，点开前我没抱太高期待。
这两年关于 AI 的讨论太多了。
模型更强了，工具更多了，行业要变了，类似的话几乎天天都能看到。
热闹当然有。
但真正能留下来的判断，并不多。
这期不一样。
里面有几句关于 coding 的看法，很刺耳，也很难装作没听见。
更关键的是，说这些话的人不是站在行业外围做观察的人。
Steve Yegge 做了 40 年软件工程，待过 Amazon 和 Google，也看过几轮技术代际怎么替换掉旧习惯、旧工具、旧岗位。
所以当他开始认真谈 AI 编程，我不会把它当普通流量观点看。
有些判断，我不一定百分之百照单全收。
但有一个核心结论，我基本认同：
AI 真正淘汰的，不是程序员，而是旧开发方式。
如果你今天还主要把 AI 当成一个“IDE 里的高级补全插件”，这场变化迟早会撞到你身上。
为什么这句话比“AI 取代程序员”更值得警惕
过去两年，大家最常说的一句话是：
“AI 不会取代程序员，但会用 AI 的人会取代不会用 AI 的人。”
这句话当然没错。
但它已经太温和了。
因为现在的问题，已经不只是“你会不会用 AI”。
更大的问题是：
你是不是还在用旧时代的工作方式，去面对一个已经换代了的生产系统。
Steve Yegge 这次真正说中的地方，就在这里。
他说的重点，不是 AI 比人聪明多少。
而是整套软件生产的节奏，已经开始改写。
以前，一个工程师的产出上限，主要取决于他自己处理信息、写代码、验证结果的速度。
现在，越来越多的高产出，已经不是来自“一个人更努力”。
而是来自：
一个人能不能组织好多股 AI 产能。
这也是为什么，我觉得这篇访谈最刺痛人的地方，不是技术细节，而是它逼你承认一件事：
很多人的问题，不是不会写代码，而是还在用一张旧地图找新大陆。
我最认同的 3 个判断
1. AI 放大的不是补全能力，而是工作流能力
很多人现在谈 AI Coding，讨论的还是：
- 它写代码准不准
- 它补全快不快
- 它能不能一次修好 Bug
这些当然重要。
但已经不是最关键的问题了。
真正拉开差距的，是你有没有把问题拆分、并行、验证、回收的整套流程建立起来。
旧方式更像这样：
- 你自己想清楚大部分东西
- AI 帮你补几段代码
- 你再自己改、自己测、自己兜底
新方式越来越像这样：
- 你定义目标和边界
- Agent 去拆任务、查上下文、生成修改
- 另一个 Agent 或另一个会话去 review 和验证
- 你负责判断、取舍和最终合并
差别不在“代码是谁敲出来的”。
差别在于，整个产线开始重组了。
这也是我最认同 Steve Yegge 的地方。
AI 时代真正值钱的，不只是写代码本身，而是组织 AI 产能的能力。
以后最稀缺的，不只是程序员，而是能把 AI 变成工作流的人。
2. 小团队第一次拥有了“打穿大公司”的杠杆
访谈里有个判断很猛：
AI 会让小团队拥有过去只有大团队才有的产能。
这一点，我也认同。
过去很多事不是不能做，而是组织成本太高。
一个想法从提出到落地，要排队、过会、拆需求、等资源、等上下游。
真正拖慢速度的，往往不是技术，而是组织。
但 AI 把其中一部分生产能力压缩了。
原来需要多人配合才能完成的调研、原型、改写、验证、文档整理，现在一个人带着几套工具就能推很远。
不是因为一个人突然变成了天才。
而是因为他第一次拥有了很多“次级劳动力”。
所以接下来更危险的，不一定是“AI 抢工作”。
而是很多原本属于大团队的机会，会被更小、更快、更轻的团队吃掉。
这也是为什么 Steve Yegge 会把很多大公司的问题，归结为创新停滞。
不是它们没有资源。
而是它们的组织结构，已经不适合这个新节奏了。
AI 时代，小团队第一次真正拥有了组织杠杆。
3. 继续把 AI 当 IDE 插件的人，会越来越被动
这是我觉得最值得警惕的一点。
很多工程师现在已经用了 AI。
但大家其实不在同一个阶段。
有的人还停留在 IDE + 补全 这一层。
AI 对他们来说，主要是写注释、补函数、解释报错、偶尔生成测试。
严格说，这当然也能提效。
但这种提效，更像是在老流程上贴创可贴。
也有一批人，已经开始切到 CLI / Agent 工作流 这一层。
对他们来说，AI 不再只是编辑器侧边栏里的一个助手，而是在承担任务拆解、上下文查找、代码生成、校验验证这些原本需要人单线程推进的工作。
这两类人看起来都在“用 AI”。
但本质上，已经不在同一个生产阶段了。
问题是，行业正在往更激进的方向走。
越来越多的人，已经把 AI 放进完整工作流里，而不是局限在编辑器的一个侧边栏里。
谁先完成这个切换，谁就会先出现明显的产能跃迁。
它的现实含义非常具体：
- 你提交代码的速度会落后
- 你验证方案的速度会落后
- 你试错和回滚的速度会落后
- 你能承接的问题复杂度也会落后
最后，差距不会表现为“你不会写代码”。
而是表现为：
你在新节奏下，太慢了。
很多岗位不是因为代码写得不够好而失去竞争力，而是因为工作方式已经过时。
如果你认同这个判断，现在先做什么
我觉得不需要一上来就 All in。
也不需要先把自己吓坏。
更实际的做法，是先完成 3 个切换。
切换 1：从“让 AI 帮我写点东西”，切到“让 AI 帮我推进一个完整任务”
不要只让 AI 做局部补丁。
开始让它参与问题拆解、方案生成、验证准备、文档整理。
切换 2：从“一个会话从头跑到尾”，切到“多个会话分别负责生成、校对、验证”
同一个上下文跑太久，往往只会越来越自洽。
多会话分工，才更容易把错误抓出来。
切换 3：从“自己兜底 90%，AI 补最后 10%”，切到“我先定义目标、约束和验收标准”
AI 最怕的不是任务难。
AI 最怕的是目标含糊。
你越早把边界和标准定义清楚，AI 越能真正成为产能，而不是噪音。
你会发现，真正开始变化的不是代码速度。
而是你处理问题的姿势。
先别急着追更强的模型。先把你的工作流换掉。
[配图位置：body-04-action-checklist.png]
最后
这篇先只写一个最核心的判断。
不是为了制造焦虑。
而是因为很多讨论到今天，还停留在一个过于温和的版本里：
AI 会辅助程序员。
AI 会提高效率。
AI 是一个新工具。
我越来越觉得，这种表述已经太轻了。
它更像是在重新定义软件生产。
所以，与其问“AI 会不会替代程序员”，不如更早一点问自己：
如果开发方式已经换代了，我是不是还站在上一代工具链里？
更多深度内容与完整文章，欢迎关注我的微信公众号：
主要分享：
AI 编程与开发效率
技术趋势与工程思考
实用工具与工作流
扫码或搜索公众号 SamLai 效率研习社 即可关注。
