AI 能写 90% 的代码了，但剩下的 10% 才是软件工程
Gergely Orosz 最近发了一篇长文，标题很直白：
“当 AI 写了几乎所有代码，软件工程会怎样？”
这篇文章在英文开发者社区引发了大量讨论。我看完之后最大的感受是：它把一个很多人隐约感觉到、但还没来得及说清楚的趋势，摊开来讲了。
今天这篇文章不是翻译。我想结合他提到的现象和我自己观察到的东西，聊一个我觉得更重要的问题：
AI 正在让”写代码”这件事贬值，但同时让”软件工程”这件事更值钱。
这两个变化同时发生，但很多人只看到了前半句。
1. 顿悟时刻：不只是宣传，是真事
先说几个案例，不是来自 AI 公司的营销材料，而是来自一线工程师的真实反馈。
Google 首席工程师 Jaana Dogan 说：
“我给 Claude Code 描述了一个分布式智能体编排的问题，它一小时内就生成了我们去年才做出来的东西。”
Vercel CTO Malte Ubl 说：
“有了 Opus 4.5 之后，世界完全不一样了。没有它，这些事情绝对不可能完成。软件生产的成本正在趋近于零。”
Claude Code 的创造者 Boris Cherny 说得更绝：
“上个月是我作为工程师第一次完全没有打开 IDE。Opus 4.5 写了大约 200 个 PR，每一行代码都是它写的。”
最有意思的是 Andrej Karpathy 的态度变化。去年十月他还在公开场合说 AI 编程”就是烂活”，两个月后他改口了：
“这个职业正在被大规模重构，程序员亲手贡献的代码比例越来越少。有一种强大的外星工具被分发到了众人手中，只不过没有附带使用手册。”
甚至一直对 AI 持怀疑态度的 Ruby on Rails 创始人 DHH 也翻转了立场：
“就在去年夏天，我还在播客上说不让 AI 直接写代码，但事后看来，那是因为当时的模型还不够好。现在彻底反过来了。”
这些人的共同点是：他们都是资深工程师，有大量实战经验，不是容易被忽悠的人。
当这批人同时说出”变化真的来了”，这件事本身就值得认真对待。
2. 拐点不是未来，是去年冬天
很多人讨论 AI 编程时，还停留在一种”等它再成熟一点”的心态里。
但 Orosz 在文章里提出了一个时间节点，我觉得很关键：
2025 年 11 月到 12 月，可能是 AI 编程能力的真正拐点。
原因很简单——三个模型几乎同时跨过了那条线：
Gemini 3（11 月 17 日）Opus 4.5（11 月 24 日）GPT-5.2（12 月 11 日）独立开发者 Simon Willison 的观察和很多人一致：
“在我的感受中，十一月发布的 GPT-5.2 和 Opus 4.5 确实代表了一个拐点——模型的增量进步突然越过了一条看不见的能力线。”
PSPDFKit 创始人 Peter Steinberger 的量化反馈更具体：
“从 GPT 5⁄5.1 到 5.2，跨度巨大。我丢给它的东西，它几乎都能一把搞定。”
这意味着什么？
意味着如果你去年试过 AI 编程觉得不行，现在值得再试一次。如果你一直在用，你大概已经感受到了质变。
3. 正在贬值的东西：不要在错误的方向上继续投入
文章里最引发思考的部分，是关于”哪些能力正在贬值”。
我结合自己的观察，总结了几条：
原型开发正在去技术化。
产品经理、设计师甚至业务人员，已经可以借助 Lovable、Replit 这类平台自己搭原型了。Replit 甚至请奥尼尔来拍广告，展示零开发经验的人怎么”凭感觉编程”做出一个 App。
这不意味着原型不重要了，而是意味着”能搭原型”不再是一个稀缺技能。
编程语言专精的红利在缩小。
过去，精通 Go 的团队倾向招 Go 高手，精通 TypeScript 的倾向招 TS 高手。
但当 AI 能处理大部分代码实现的时候，一个工程师是否精通某个特定语言就没那么关键了——因为你可以在任何代码库里让 AI 帮你实现功能，甚至让 AI 先帮你解释你不熟悉的语言和框架。
正如 Steinberger 所说：
“现在真正重要的决策是语言/生态和依赖选型。几个月前我对 Go 完全没兴趣，但后来试了一下发现，智能体写 Go 写得特别好。”
前后端分家的时代可能要结束了。
当后端工程师可以通过 AI 生成还不错的前端代码时，初创公司真的还需要分别招前端和后端吗？Orosz 的判断是：他们只需要招一个靠谱的工程师，让这个人用 AI 在整个技术栈里自己解决问题。
执行定义清晰的工单正在被 AI 接管。
Cursor 团队已经有一套自动化流程：所有 Linear 工单直接传给 Cursor 实现，开发者只需要决定合并还是继续迭代。
这意味着什么？意味着那种”产品经理写详细工单，开发者照做”的工作流，正在被重塑。
4. 正在升值的东西：这才是值得认真投入的方向
如果说”写代码”在贬值，那什么在升值？
这篇文章给出的答案和我自己的判断高度一致。
技术负责人的能力正在变成基本盘。
当 AI 能实现任何定义清晰的工单时，问题就变成了：谁来写出那个”能让 AI 正确生成代码的工单”？
这要求你同时理解用户需求和技术约束，能把复杂问题拆解成定义清晰的小任务。
这件事，本质上就是优秀 Tech Lead 已经在做的事。
测试和验证能力只会越来越重要。
Orosz 说了一句很实在的话：
“没有单元测试、集成测试和端到端测试，我无法想象自己会信任 AI 生成的代码。”
代码生成得越快，你就越需要快速验证它对不对。能搭建测试基础设施、优化测试速度、判断哪些测试是多余的——这些能力过去只有高级工程师才需要，现在正在变成基本功。
产品思维正在从加分项变成必需品。
WorkOS 大约 80 个工程师只配一个产品经理，每个人都是”产品工程师”。Linear 成立头几年完全没有产品经理。
当 AI 生成越来越多代码的时候，”做什么”比”怎么做”更重要。
架构决策的影响被放大了。
代码生成得越快越多，就越需要有人明确软件的结构。单体还是微服务？接口边界在哪？怎么保证可测试性？怎么管理技术债？
这些都是你需要明确告诉 AI 的决策，不能让它自由发挥。
一句话总结：构建可靠、高性能、可扩展系统的能力，比以往任何时候都更值钱。
当任何人都能用 AI 生成一个”差不多能用但随时可能崩”的软件时，能产出稳定可靠系统的人就会成为稀缺资源。
5. 残酷的那一面：没人愿意细想的部分
文章里提到的一些趋势，读起来不太舒服，但我觉得有必要讲。
代码量暴增，但质量不一定跟上。
Meta 前最高产开发者 Michael Novati 的数据很直观：用 AI 后他的 PR 数量翻倍，每月 400-600 次提交，一年贡献了 1500+ 个新功能和 800+ 个 Bug 修复。
代码越多，Bug、安全漏洞和资源消耗就越多。Cortex 2026 基准报告发现：变更失败率上升了 30%。
薄弱的工程实践会更快暴露问题。
缺乏测试文化、不遵循编码规范、可观测性基础设施薄弱的团队，在 AI 加速交付后，会更快撞上生产环境的墙。
交付节奏加快了，但”坏东西”撞上生产环境的频率和速度也在提高。
工作生活边界可能进一步被侵蚀。
这是一个很少有人提到但很现实的问题。
前 Datadog 工程师 Donovan Dicks 说得很直接：
“让工程师在离开键盘的时候也能干更多的活，只会让他们面临更多被雇主压榨的风险。’不在电脑前’是我仅存的几道防线之一。”
当你可以用手机审查和合并 PR、在浏览器里指挥 AI 改代码、在沙箱里远程调试——工作和生活的边界就被进一步模糊了。
初级工程师的成长路径正在被压缩。
以前入门级工程师要花好几年写大量代码，在跟资深同事合作中逐渐*得架构、测试、技术债管理这些能力。
现在 AI 已经能写大部分代码，对入门级工程师的预期直接跳到了”高级工程师的基本标准”：拆解任务、跨栈工作、产品思维、架构决策、验证 AI 输出……
这意味着什么？可能是应届生需要更系统的计算机科学教育才能入行，也可能是那些只”会写代码”的人会越来越难找工作。
6. 最后说一个容易被忽略的感受
这篇文章最打动我的部分，不是技术分析，而是 Orosz 最后那段”失落感”的自白。
他说：
“我不禁想：从编写复杂代码的艰难中获得的那种成就感，未来还会有吗？”
这段话之所以真实，是因为它戳中了很多开发者的一个共同感受：
我们花了很多年才学会的技能，正在被快速替代。
从大学里对着 C 语言望而生畏，到工作中对着复杂代码库迷茫无措，再到通过大量实践、读书、向他人学*慢慢精进——这个过程本身就是一段有价值的经历。
而现在，AI 写代码已经比我们快了，效果跟我们差不多，甚至在我们不熟悉的领域比我们做得更好。
有某种珍贵的东西正在被夺走，而且来得很突然。
但 Orosz 也说了一句让我觉得更清醒的话：
“一个团队越是依赖 AI 生成代码，软件工程的基本功就越重要。”
也就是说，变化的方向不是”不需要工程师了”，而是”需要不同能力的工程师”。
写代码正在从目的变成手段。而真正决定一个工程师价值的，是他能不能定义正确的问题、做出正确的决策、构建可靠的系统、验证正确的结果。
这些事，AI 帮不了你。
至少现在不能。
版权声明：本文转载于今日头条，版权归作者所有，如果侵权，请联系本站编辑删除
