当 AI 写了几乎所有代码，软件工程会怎样？

作者：Gergely Orosz
日期：2026年1月7日
来源：The Pragmatic Engineer

这已经不是假设性问题了——这是一个即将冲击整个科技行业的大趋势。

2025 年的冬季假期，很多开发者有机会从日常工作中抽身，用 AI agent 来推进那些搁置已久的 side project。我自己就用 Opus 4.5 和 GPT 5.2 完成了几个中等规模的任务：通过 prompt LLM、review 输出、确保测试通过，最后再微调一下，就把几百行代码推到了生产环境。

更神奇的是，我甚至在手机上构建了生产软件：通过 Claude Code for Web 连接 GitHub，用 Claude 移动端 app 指挥它修改代码、添加和运行测试，然后直接在手机上 review 和 merge PR。虽然都是低风险的工作，业务逻辑也有自动化测试覆盖，但这种"在手机上创造代码并推到生产"的体验确实前所未有。

这篇文章将探讨：当 AI 能写出绝大部分代码时，软件工程这个职业会发生什么变化。

1. 最新模型带来的"顿悟时刻"

过去几周，一些资深软件工程师分享了他们的"顿悟时刻"——AI 工具已经足够好，可以生成他们写的大部分代码了。

来自业内人士的观察

Jaana Dogan，Google 首席工程师：
"我不是在开玩笑。我们在 Google 从去年开始就在尝试构建分布式 agent 编排器，各种方案，大家意见不统一。我给 Claude Code 描述了这个问题，它在一小时内生成了我们去年花了很长时间才构建出来的东西。"
Thorsten Ball，Amp 软件工程师：
"15 年来，我一直以为自己喜欢手写代码，喜欢那种'打字的节奏'。现在，我不确定了。2025 年是我深刻反思自己与编程关系的一年。我学到的是：手写代码现在让我感到沮丧。"
Malte Ubl，Vercel CTO：
"这个假期太疯狂了：我构建了 2 个主要的开源项目。现在是 Opus 4.5 的世界，没有它这些绝对不可能完成。Opus + Claude Code 现在表现得像一个高级软件工程师，你只需要告诉它要做什么。我不想太戏剧化，但你们必须抛弃旧有的认知。软件生产的成本正在趋近于零。"

独立开发者的声音

David Heinemeier Hansson（DHH），Ruby on Rails 创始人：
"你不能让那些糟糕的输出否定 AI 的奇妙之处。这是自从我们把计算机连接到互联网以来，让计算机做的最令人兴奋的事情。去年夏天我还抵制让 AI 直接写代码，但事实证明，部分原因只是当时的模型还不够好！我花在重写它输出内容上的时间比从头写还多。现在情况反过来了。"
Adam Wathan，Tailwind CSS 创始人：
"现在每次必须手写精确语法时，都感觉像是繁琐的苦差事。令人惊讶的是，编程仍然很有趣，可能比以前更有趣了。我现在最大的问题是想出足够多有价值的点子来充分利用这种生产力提升。"

从"AI 垃圾"到震撼行业

Andrej Karpathy，OpenAI 联合创始人，去年 10 月还在说：

"总体来说，模型还没到位。我觉得整个行业在假装这很神奇，但其实不是。这是垃圾。"

两个月后，他的观点彻底改变了：

"作为程序员，我从未感到如此落后。这个职业正在被剧烈重构，程序员贡献的代码比例越来越稀疏。我感觉如果能正确串联起过去一年出现的这些工具，我可以强大 10 倍，而没能获得这种提升明显是技能问题。显然，某种强大的外星工具被分发了出来，但它没有说明书，每个人都得在这场 9 级地震中自己摸索如何使用它。"
Boris Cherny，Claude Code 创建者：
"上个月是我作为工程师第一次完全没有打开 IDE。Opus 4.5 写了大约 200 个 PR，每一行代码都是它写的。软件工程正在发生根本性的变化。"

2. 为什么是现在？

2025 年 11 月和 12 月的模型发布似乎是转折点：

Peter Steinberger，拥有约 20 年经验的软件工程师：
"从 GPT 5/5.1 到 5.2 的跨越是巨大的。它几乎能一次搞定我扔给它的任何东西。"
Simon Willison，独立 LLM 专家：
"对我来说，GPT-5.2 和 Opus 4.5 确实代表了一个拐点——模型渐进式地变好，突然跨过了一条隐形的能力线。一大堆更难的编码问题突然变得可解了。"

疯狂预测成真？

Anthropic CEO Dario Amodei 去年 3 月说：

"我认为三到六个月内，AI 将写 90% 的代码。然后，12 个月内，我们可能进入 AI 写几乎所有代码的世界。"

这在 12 月成为现实——Boris Cherny 贡献给 Claude Code 的代码 100% 由 AI 编写。

对于我自己的使用场景（TypeScript、Node/Express、React、Postgres），AI 生成 90% 代码的说法感觉确实成立。Go、Rust 等流行语言也是如此。

本文接下来假设 AI 编码工具今年将足够好，能为许多开发者和团队生成 90% 以上的代码。最可能的场景是寻找 product-market fit 的初创公司，以及不需要理解现有代码库的全新项目。

3. 坏消息：专业技能价值下降

一些曾经很有价值的东西将被委托给 AI：

原型开发

Lovable 和 Replit 等平台明确宣传自己是让非技术人员构建软件的方式。产品人员、设计师和业务人员可以自己构建原型，不再需要开发者来实现想法。同时，快速生成概念应用将成为每个开发者的基本期望。

语言多面手价值下降

精通多种语言的工程师传统上很受欢迎，因为团队通常喜欢雇用自己技术栈的专家。但当 AI 写大部分代码时，任何工程师都可以跳进任何代码库，让 AI 实现功能。你还可以让 AI 解释代码库的各个部分，比没有 AI 工具时更快地学习一门语言。

语言专业化和前后端专业化的终结？

2000 年代初，大多数招聘广告都要求特定语言的候选人：ASP.NET 开发者、Java 开发者、PHP 开发者等。从 2010 年代中期开始，更多公司开始按技术栈专业化招聘：后端开发者、前端开发者、原生 iOS/Android 开发者。

但现在有了 AI，后端工程师可以 prompt 出不错的前端代码、跨平台代码，甚至尝试原生移动代码。我很难想象初创公司还会分别招聘前端和后端开发者：他们只会招聘一个他们信任的专家，相信他会用 AI 在整个技术栈中解决问题。

实现定义明确的 ticket

AI 将越来越多地完成这类工作，比如接收一个定义明确的 JIRA 或 Linear ticket——如 bug 报告或小功能请求——并实现它。Cursor 团队现在有一个自动化流程，所有 Linear ticket 都自动传递给 Cursor，它会一次性完成实现。开发者可以选择合并或迭代。

重构

AI 已经相当擅长重构，工具可能只会越来越好。手动重构会比告诉 AI 你想要什么类型的重构慢得多。当然，AI 搞砸的风险始终存在，尤其是大型重构。这就是为什么验证代码的方法今年肯定会更加重要。

对生成代码的关注——某些情况下？

从 AI prompt 生成的代码可能很冗长，或者重复现有代码而不是使用抽象。但在构建概念验证或程序效率不重要时，这完全可以接受。

Peter Steinberger，在构建全新软件时说：
"这些天，我不怎么读代码了。我看着输出流，有时看看关键部分，但说实话，大部分代码我不读。我确实知道组件在哪里、事物如何结构化、整体系统如何设计；这通常就够了。现在重要的决策是语言/生态系统和依赖项。"

即便如此，在扩展现有成熟软件或需要避免安全问题时，阅读代码仍然很重要。

4. 好消息：软件工程师比以前更有价值

（原文此部分内容待补充）

这篇文章是 2026 年的第一篇，探讨了 AI 编码工具的现状以及它对软件工程职业可能意味着什么。模型能力的跃升已经让许多资深工程师改变了看法，而这仅仅是开始。

原文

The Pragmatic Engineer