6.0
关注
AI SCORE
观点评论2026-03-11 08:00
AI 核心编程后，软件工程的权重重新分配
宝玉 AI#AI编程#工程方法
Editor brief · 编辑速览
代码生成已成为 AI 强项，工程价值链从「实现」向「设计」、「评审」、「架构」倾斜，资深工程师需重新定位。
代码生成已成为 AI 强项，工程价值链从「实现」向「设计」、「评审」、「架构」倾斜，资深工程师需重新定位。
不只是 AI 公司的开发者注意到模型能力大幅提升，独立开发者同样感受到了。
十一月和十二月发布的几个模型似乎就是拐点（tipping point）：Opus 4.5、GPT-5.2 和 Gemini 3。
往前看，原型开发、精通多种编程语言、或者在某个技术栈上的专精，可能都会大幅贬值。
技术负责人（Tech Lead）的特质更受追捧，初创公司会要求工程师具备产品思维（product-minded），做一个扎实的软件工程师而不仅仅是"写代码的"会更吃香。
生成更多代码会带来更多问题，薄弱的工程实践会更快暴露，开发者的工作生活平衡可能更难维持。
产品经理现在可以更容易地生成软件——实现目标所需的工程师更少了——但软件工程师同样不那么需要产品经理了。两个职业的重叠将比以往更多。
过去几周，一些资深软件工程师分享了他们的亲身体验，讲述 AI 工具已经强大到可以生成他们日常大部分代码的程度。
Google 首席工程师 Jaana Dogan 对 Claude Code 的进步印象深刻：
我不是在开玩笑，这一点都不好笑。我们从去年开始就在 Google 尝试构建分布式智能体编排系统。各种方案并存，大家也没达成共识等等。我给 Claude Code 描述了一下这个问题，它一小时内就生成了我们去年才做出来的东西。
还不完美，我还在迭代，但这就是我们现在所处的阶段。如果你对编程智能体持怀疑态度，试试在你擅长的领域用一下。从零开始构建一个复杂的东西，你自己来当裁判。
Amp 的软件工程师 Thorsten Ball 在博客中反思（粗体为原文强调）：
十五年来，我一直以为自己热爱写代码，热爱一个字一个字地敲出代码，热爱 Gary Bernhardt 说的那种'打字的节奏感'——坐在编辑器前，手指在键盘上噼里啪啦。
2025 年是我深刻反思自己与编程关系的一年。以前我偶尔也会冒出'我要不要去当个 Lisp 信徒？'这样的想法；但从来没想过'我到底还喜不喜欢亲手敲代码？'
这一年下来我认识到，亲手敲代码这件事，现在让我感到烦躁。
Vercel 的 CTO Malte Ubl 说：
这个假期太疯狂了：我搞了两个大型开源项目（一个还没发布，另一个是用 TypeScript 给 AI 智能体做的完整 bash 环境实现）。
有了 Opus 4.5 之后，世界完全不一样了。没有它，这些事情绝对不可能完成。现在 Opus 加上 Claude Code 就像一个高级软件工程师，你告诉它做什么，它就去做。难的任务还是需要监督，但它对反馈的响应非常灵敏，基本上点一下就改对了。
我不想说得太夸张，但你们真的得抛弃过去的认知了。软件生产的成本正在趋近于零。
老读者可能还记得 Malte，他之前分享过软件工程 20 年生涯的反思，其中 11 年在 Google。
你可能会说，上面这些人所在的公司都在卖 AI 开发工具，他们当然要这么说。但跟任何厂商都没利益关系的工程师，也给出了类似的观察：
Ruby on Rails 的创始人 David Heinemeier Hansson（DHH）描述了他对 AI 的态度如何180 度翻转：
你不能因为那些粗制滥造和让人尴尬的 AI 输出就否定 AI 本身的了不起。这是自从我们把计算机联网以来，最让人兴奋的事。如果你 2025 年一直在对 AI 悲观或怀疑，为什么不在 2026 年带着乐观和好奇心重新开始呢？
就在去年夏天，我还在 Lex Fridman（知名科技播客主持人）的节目上说不让 AI 直接写代码，但事后看来，那部分抵触其实是因为当时的模型还不够好！我花在改写 AI 代码上的时间比自己从头写还多。现在彻底反过来了。
Tailwind CSS 的创始人 Adam Wathan 说：
现在每次不得不自己手敲精确的语法（而不是用 AI），都感觉像是一件苦差事。让我意外又欣慰的是，编程依然有趣，甚至比以前更有趣了。
我现在最大的问题是想不出足够多值得做的点子来充分利用这波生产力提升。
一个广为流传的"顿悟时刻"来自 OpenAI 联合创始人 Andrej Karpathy。Karpathy 已经多年不参与 OpenAI 的事务了，以直言不讳地评价和批评 AI 工具而著称。去年十月，他在 Dwarkesh（知名科技播客）节目上总结了他对 AI 编码工具的看法（粗体为原文强调）：
总的来说，模型还没到位。我觉得这个行业步子迈得太大了，试图假装一切都很棒，但并不是。
他们不愿意正视这一点，也许是在忙着融资什么的。我不知道怎么回事，但我们就是处在这么一个尴尬的中间阶段。模型确实很厉害，但还需要大量的打磨。
目前来说，自动补全对我最好使。但有些代码我还是会用 LLM 智能体来写。
两个月后，这个看法被彻底修正了。Karpathy 在 12 月 26 日写道（粗体为原文强调）：
我从来没有像现在这样觉得自己作为程序员落伍了。
这个职业正在被大规模"重构"（refactored，没错，他用了编程术语来形容职业本身的变革），程序员亲手贡献的代码比例越来越少。
我有一种感觉，如果我能把过去一年涌现出来的工具都串联起来，我的能力可以提升 10 倍。而没有抓住这波红利，纯粹就是自己菜。
在原有的那些抽象层之上，又多了一层全新的可编程抽象层需要掌握：智能体、子智能体、它们的提示词、上下文、记忆、模式、权限、工具、插件、技能、钩子、MCP、LSP、斜杠命令、工作流、IDE 集成……还需要建立一个完整的心智模型，来把握这些本质上随机的、会犯错的、不透明的、不断变化的实体的优势和陷阱，而它们突然就和过去那些好端端的传统工程搅在了一起。
显然，一件强大的外星工具被分发到了众人手中，只不过没有附带使用手册，每个人都得在九级地震中自己摸索怎么拿稳、怎么操作。
Claude Code 的创造者 Boris Cherny 回应说，他上个月提交的所有代码都是 AI 写的：
上个月是我作为工程师第一次完全没有打开 IDE。**Opus 4.5 写了大约 200 个 PR，每一行代码都是它写的。**软件工程正在发生根本性的变化，即使对于像我们这样的早期采用者和实践者来说，最难的部分也是不断重新调整自己的预期。而这仍然只是一个开始。
The Pragmatic Engineer 之前做过一期深度报道，和 Boris 以及团队的其他创始成员聊了 Claude Code 是怎么做出来的。
十一月和十二月的模型发布似乎就是 AI 编程能力真正变强的拐点：
Gemini 3（Google，11 月 17 日发布）：Google 迄今为止最强的编程模型
Opus 4.5（Anthropic，11 月 24 日发布）：该公司最强的编程模型，已成为 Claude Code 的默认模型
GPT-5.2（OpenAI，12 月 11 日发布）：驱动着 Codex，表现与搭载 Opus 的 Claude Code 不相上下
Opus 4.5 和 GPT-5.2 我都用过，两者在编程方面都非常能打，这也不是什么小众看法。Peter Steinberger 是有约 20 年经验的软件工程师，也是 PSPDFKit（知名 PDF 处理框架）的创始人，他在博客中分享了对 GPT-5.2 的印象：
从 GPT 5/5.1 到 5.2，跨度巨大。GPT 5.2 出来之后，我需要用到自己做的 CLI 工具 'oracle'（用来在智能体卡住时帮它脱困）的情况少了很多。我偶尔还是会用 GPT 5 Pro 做研究，但让模型去'问 oracle'的次数从每天好几次变成了每周几次。
我不觉得可惜；做 oracle 本身就很有意思，我学到了很多关于浏览器自动化和 Windows 的知识，也终于花时间研究了 skills 这个功能，之前一直没当回事。这件事说明的是 5.2 在很多实际编程任务上进步有多大：我丢给它的东西，它几乎都能一把搞定（one-shot）。
Simon Willison 是一位在大语言模型领域我一直关注的独立软件工程专家，他指出了同样的观察：
在我的感受中，十一月发布的 GPT-5.2 和 Opus 4.5 确实代表了一个拐点——就是模型的增量进步突然越过了一条看不见的能力线。一下子，一大批更难的编程问题变得可以解决了。
Gemini 3 Pro 也许应该被归入这个行列，但我还没有从那些见多识广的资深工程师那里看到和另外两个模型同等程度的惊叹。
The Pragmatic Engineer 播客的第一期嘉宾就是 Simon，标题恰如其分：给软件工程师的 AI 工具，不带炒作的那种——Simon 一直在践行这种态度。
一个当时很多人——包括我——都不以为然的预测，来自 Anthropic 的 CEO Dario Amodei。去年三月，他说：
我认为三到六个月内，AI 就会写 90% 的代码。再过 12 个月，我们可能就生活在一个 AI 写几乎所有代码的世界里了。
结果在十二月就应验了，Cherny 贡献给 Claude Code 的代码 100% 由 AI 生成。站在质疑的角度，你可以指出 Claude Code 并非开源项目，所以这个说法难以验证。而且，Claude Code 的创造者当然想展示它的强大能力。但我和 Boris 聊过，我信任他；同时，我自己使用 Claude Code 的体验也跟他说的一致：我提交的所有代码都是让 Claude Code 生成的。
当代码不符合我的预期时，我会继续提示让 LLM 改。和 Boris 一样，我已经不再手写代码了——不是因为不会，而是没必要了，模型足够胜任。我仍然可以手写，但交给模型显然更快。
即使是我很熟悉、可以在 IDE 里自如操作的代码，我也发现用智能体做编辑至少和我手动操作一样快，甚至更快。不过，我还是会时不时打开 IDE，因为我想确认自己有能力亲手完成这些工作。
就我个人的使用场景而言——技术栈是 TypeScript、Node/Express、React 和 Postgres——"AI 能生成 90% 的代码"这个说法基本属实。据我了解，Go、Rust 以及其他有大量训练数据的主流语言和框架，情况也越来越类似。有趣的是，LLM 写 C 代码似乎也相当不错，Redis 的作者 Salvatore Sanfilippo 就观察到了这一点。
本文后续内容基于一个假设：AI 编程工具将在今年达到能为很多开发者和团队生成约 90% 以上代码的水平。 最有可能率先实现这一点的是正在寻找产品 - 市场契合（product-market fit）的初创公司——对它们来说，试错性的工作本来就无所谓——以及全新项目开发（greenfield development），即不需要理解已有代码库就可以从零构建的项目。
当然，很多场景下完全依赖 AI 编程工具仍然不现实，可能是因为在某些代码库或上下文中它还不够好用，也可能是开发者主动选择不依赖它。
但值得思考的是：在一个几乎所有代码都通过提示词由 AI 生成、而非开发者手敲出来的环境里，软件工程这个职业会走向何方？这将是翻天覆地的变化，但具体会怎样呢？我们来逐一审视好的、坏的和残酷的可能性，先从潜在的负面影响说起。
过去被视为高价值的一些能力，将越来越多地被交给 AI：
原型开发。 Lovable 和 Replit 这类平台明确把自己定位为帮助非技术人员构建软件的工具。在最近的一则广告中，Replit 请来了 NBA 传奇球星奥尼尔（Shaquille O'Neal），让他用凭感觉编程（Vibe Coding）的方式做了一个"史上最佳 5000 条搭讪金句"的 App：
话说回来，有了 AI 工具，产品经理、设计师和业务人员可以自己搭原型了，不再需要找个开发者把想法变成现实。与此同时，每个开发者都会被期望能够快速生成概念验证应用，这将成为基本功。
编程语言多面手（language polyglot）可能不那么值钱了。 过去，精通多种编程语言的工程师很吃香，因为团队通常喜欢招对自家技术栈有经验的人。用 Go 的团队倾向于招 Go 高手，用 Rust 的、用 TypeScript 的也一样。不过要说明一点，一些比较前瞻的团队并不看重候选人是否精通他们用的特定语言，他们相信优秀的工程师可以随时上手新语言。
但当 AI 写绝大部分代码的时候，懂好几门语言的优势就没那么大了，因为任何工程师都可以跳进任何代码库，让 AI 去实现某个功能——而 AI 多半能给出像模像样的实现。更好的是，你可以让 AI 解释代码库的各个部分，比没有 AI 时更快地上手一门新语言。
语言专精和前后端专精要终结了？ 2000 年代初，我记得大部分招聘广告要的是特定语言的开发者：ASP.NET 开发者、Java 开发者、PHP 开发者等等。从 2010 年代中期开始，越来越多的公司按技术栈方向招人：后端开发、前端开发、iOS/Android 原生开发、跨平台移动开发。在后端领域，一个熟悉 Go 的开发者转去写 TypeScript、Scala 或 Rust 已经被普遍接受。仍然看重特定语言的岗位主要是原生移动开发，因为 iOS 和 Android 框架差异大到需要深入掌握其中之一。
但今天有了 AI，一个后端工程师可以通过提示词生成还不错的前端代码、跨平台代码，甚至尝试原生移动代码。有了这个工具，我很难想象初创公司还会分别招前端和后端开发者：他们只需要招一个靠谱的专家，相信这个人会用 AI 在整个技术栈中自行解决问题。
执行定义清晰的工单（ticket）将越来越多地由 AI 完成。 比如一个 JIRA 或 Linear 上描述清楚的工单——无论是 Bug 报告还是小功能需求——让 AI 来实现。现在，Cursor 团队已经有了一套自动化流程，所有 Linear 工单都会被自动传给 Cursor，让它一把搞定实现。开发者只需要决定是合并还是继续迭代。传入的上下文越多、模型越强，输出可以直接合并的概率就越大。
这将是一个重大转变，尤其是在那些层级分明的职场——项目经理或产品经理长期以来一直在写详细的工单让开发者照做。
重构可能会越来越多地交给 AI。 AI 目前已经相当擅长重构了，工具只会越来越好。手动重构会比告诉 AI 你想要什么样的重构慢得多。当然，在 AI 出现之前，现代 IDE 也提供了强大的重构能力——比如跨整个代码库重命名函数或类、提取函数之类的。
当然，AI 搞砸的风险始终存在，特别是大规模重构。所以今年，代码验证手段的重要性只增不减。
需要仔细审查生成的代码吗？看情况。 AI 生成的代码可能很啰嗦，或者重复造轮子而不是复用已有的抽象。但有些时候这完全可以接受，比如做概念验证，或者程序性能并不重要的场景。
软件工程师 Peter Steinberger 在做全新项目，他说自己已经不怎么看 AI 生成的代码了：
现在我已经不怎么读代码了。我会看着代码流过去，偶尔关注一下关键部分，但老实说，大部分代码我不看。我知道各个组件在哪儿、整体结构是什么样、系统是怎么设计的——通常这就够了。
现在真正重要的决策是语言/生态和依赖选型。我常用的语言是 TypeScript（做 Web）、Go（做命令行工具）和 Swift（需要用 macOS 特性或有 UI 的时候）。几个月前我对 Go 完全没兴趣，但后来试了一下发现，智能体写 Go 写得特别好，而且 Go 简单的类型系统让代码检查跑得很快。
尽管如此，在扩展已有的成熟软件或需要规避安全问题时，阅读代码仍然很重要。大致来说，如果上线的代码出了问题影响到业务，你肯定既想做测试又想做代码审查。
开发者不会把所有时间都花在写代码上——至少大多数职场是这样。 Atlassian 的 2025 年开发者体验报告（3,500 人参与调查）发现，开发者平均每周只有 16% 的时间在写代码，其余都花在了行政事务上。回想我在 Microsoft、Skyscanner 和 Uber 的日子，这个比例很真实：我要帮助同事、做代码审查、讨论设计和 Bug、参加规划会、团队会、全员会、做招聘、联系各方人员，等等。
所以即使 AI 在 2026 年写了所有代码，也只是解放了工作周中的一小部分时间。而且显然，要让 AI 写出对的代码，首先得给它正确的提示。
技术负责人的特质几乎肯定会更受追捧。 当 AI 能实现任何定义清晰的工单时，谁来写那个能让 AI 正确生成代码的工单？要写出"完美"的工单，你需要描述清楚两方面：
功能性工作的用户需求：功能应该怎么运作，各种边界情况下应该发生什么
非功能性需求（nonfunctional requirements）的技术细节：性能、无障碍访问、可靠性相关的工作
非技术人员可以写出面向用户的详细工单，但他们几乎不可能清晰地描述非功能性需求，而这正是软件工程知识越来越关键的地方。那些能站在用户角度思考、把工作拆解成定义清晰任务的实战型工程师，会更加抢手。这恰好是优秀的技术负责人已经具备的能力。唯一的变化是，即使是入门级工程师，如果想在编码这一块快速成长，也需要掌握这项能力。
测试和测试基础设施能力会更加重要。 要让智能体更高效、减少幻觉（Hallucination，即 AI 编造不存在的代码或 API），它需要反馈回路来验证自己的工作。能快速运行的验证手段包括：
就我个人而言，没有单元测试、集成测试，甚至端到端测试，我无法想象自己会信任 AI 生成的代码。坦白讲，我目前觉得如果不给针对性提示，AI 智能体写好测试的能力还不太行。我在提示它构建功能时，也会提示我希望看到的测试类型，并确认测试是否按预期编写。
测试还需要集成到 CI/CD 流程中运行。当然，随着代码库变大，测试可能会越跑越慢；这时候就需要工程师撸起袖子去优化测试速度，或者判断哪些测试是多余的。这种能力过去只要求高级软件工程师具备，但往后，对于所有大量用 AI 生成代码的工程师来说，它可能会成为基本功。
在更多初创公司，"有产品思维"可能也会成为基本要求。 当 AI 生成越来越多的代码，明确做什么就变得越来越重要。已经有一些敏捷的初创公司在招"产品工程师"（product engineer）——他们能自己发现要做的事情，同时兼具迷你产品经理和软件工程师的角色。
采用产品工程师模式的初创公司包括 WorkOS——那里大约 80 个工程师只配一个产品经理，每个人都是产品工程师——以及 Linear，它成立头几年完全没有产品经理。如今这家公司招的也是产品工程师。
做出好的架构决策变得更加重要。 代码生成得越快越多，就越需要明确软件的结构。你要把软件做成单体应用，还是独立的、可测试的服务？接口和边界是什么，怎样让各个部分可测试，有没有端到端测试、Mock、Fake？这个清单很长。
这些都是你需要明确指示 AI 去遵循的决策，而不能让它自由发挥。否则，你就会被难以维护的软件困住——即使有 AI 也救不了你。
追踪和处理技术债（tech debt）会受到更多重视。 代码越多，技术债就越多，需要追踪和处理的就越多。经验不足的工程师不会注意到所有问题，可靠性挑战、性能退化、更多 Bug 都会悄悄积累，修改代码而不破坏别的东西也会越来越难。我们之前的技术债偿还指南在 AI 大量生成代码的时代更加适用！
能够构建可靠、高性能、可扩展和安全的系统，将是一项极为珍贵的技能。 当谁都能生成一个"差不多能用但随时可能崩"的软件时，能产出始终稳定可靠的高质量代码的工程师将更加抢手。
你没法只靠一句提示词就让 AI 写出安全、高性能的代码：你需要知道自己想要什么、如何验证非功能性需求、如何设计架构，然后相应地提示 AI。有些时候，你可能还得抛开 AI，自己动手写代码或改配置才能把细节做对。归根结底，知道什么时候该用自己的专业知识，这本身就是一种能力。
做一个扎实的软件工程师，而不仅仅是"写代码的"，会比以前更受追捧。 把上面说的总结一下：构建软件中"工程"的部分变得更加重要。我们会生成更多的代码，要让这些代码可靠运行，工程方法必须靠谱，反馈回路必须紧密。
去年，凭感觉编程在非技术圈迅速流行，很多人很快就发现：就算用了超级 AI 来生成代码，要构建一个真正能用的软件其实很难。半年前，我在 LinkedIn 上做了一张关于这个话题的 meme：
更多代码和更多资源消耗 = 更多问题？ 使用 AI 的工程师会提交更多 PR、产出更多代码，已经有证据了。下面是 Michael Novati 在 2024 年（几乎不用 AI）和 2025 年（大量使用 AI）的 GitHub 活跃度对比：
Michael 在 Meta 工作时是那里最高产的开发者，Meta 的"Coding Machine"（编码机器）标签就是因他而设。我们做过一期播客节目邀请了 Michael。
而他之后也丝毫没有放慢脚步：去年，他以每月 400-600 次提交（每天 15-25 次！）的节奏，在他全职开发的创业平台上贡献了超过 1,500 个新功能和 800 多个 Bug 修复。他分享了一份更详细的总结。
显而易见，代码越多，Bug、安全漏洞和其他问题的滋生空间也越大。这也可能带来更多的资源消耗——开发者和团队在不断构建更复杂的服务、存储更多数据、消耗更多算力，等等。
代码质量更粗糙。 可以预见，大多数使用 AI 生成更多代码的团队，质量标准并不会随之提升——至少在初期不会。工程师以前审查的是少量小型 PR，现在要用同样的标准审越来越多、越来越大的 PR，根本不现实。
早期数据表明，推向生产环境的代码质量正在下降：Cortex 2026 基准报告调研了 50 多位工程负责人，发现变更失败率（change failure rate，即导致故障或回滚的部署比例）上升了 30%。
薄弱的软件工程实践会更快暴露问题。 那些缺乏自动化测试文化、不遵循编码规范、或可观测性（observability）基础设施薄弱的团队，将会有更多回归缺陷被推上生产环境，甚至可能遭遇更多线上故障。原因很简单：交付节奏加快了，那些"坏东西"撞上生产环境的频率和速度都在提高。
只会"写代码"而不具备软件工程能力的开发者，需求可能会下降。 如果一个开发者拿不出软件工程方面的技能——比如拆解复杂项目的能力、面向可测试性和可观测性的架构设计能力、以及构建可扩展和高可靠系统的能力——那找工作可能会更难。当一个非技术人员都能用 AI 来生成代码时，开发者需要的技能就必须超越"写代码"本身，因为很显然，AI 已经能做到这一点了。
工作与生活的边界更难守住？ 我有种预感，2026 年将是 AI 智能体在远程虚拟沙箱中运行成为主流的一年。这意味着作为开发者，你可以通过浏览器甚至手机来下达指令、验证结果、部署代码——完全不需要工作电脑。这种变化就像当年 Slack 等通讯工具上了手机端一样：开发者随时随地都能被找到，在任何有网络的地方都能修 Bug。
这可能会成为一个问题。前 Datadog 工程师 Donovan Dicks 指出：
我担心的是，移动端体验的提升可能会进一步侵蚀员工个人生活与职业责任之间的边界。很多人已经在为手机上装 Slack、Teams 等软件、随时被雇主联系到而承受压力了，而且在正常工作时间之外做的事情根本没有额外报酬。让工程师在离开键盘（AFK）的时候也能干更多的活，只会让他们面临更多被雇主压榨的风险。
作为美国的受薪员工，我从来没有因为深夜处理故障、通勤路上回消息、或者其他工作时间之外完成的任务而得到过额外报酬。'不在电脑前'是我仅存的几道防线之一，防止更多的职业责任蚕食我的个人时间，尤其是假期。如果移动端编码工作流变得可行并成为常态，这道防线可能就不复存在了。
工具的发展确实令人兴奋，我也喜欢在个人项目里把玩这些工具，但把它们引入职业工作流时我会更加审慎。我很好奇这会对整个行业产生什么样的影响。
初级工程师被逼着快速成长为高级工程师？ 在 AI 生成大部分代码的新时代，对软件工程师的预期似乎变成了：
具备产品思维（product-minded）：主动与客户交流，不用别人催就去修 Bug，主动提出产品改进建议
尽早思考架构决策，在软件结构设计上做出务实的选择
这些要求在以前是头部公司对高级或 Staff 级别工程师的基本标准，而现在正在变成对入门级工程师的基本期望。然而在 AI 时代之前，入门级工程师要花好几年时间写大量代码，在与资深同事的合作中逐渐习得这些技能。
这种变化会推动应届毕业生更快地"成熟"吗——跳过 AI 已经擅长的"写代码"阶段，直接进入软件中的工程部分？如果是的话，这一定是坏事吗？以我的经验来看，应届毕业生能力很强、学得很快，我相信很多人会在承担那些以前只有资深开发者才能胜任的角色时，表现得相当出色。
计算机科学教育会成为新人入行的刚需？ 如果我是一个招聘经理，要招一个应届生，我需要的是一个理解"高级"概念的人。他们需要在零年行业经验的情况下，就懂软件架构模式、自动化测试、以及技术债的概念和重要性。哦，他们大概还得有在团队里用 AI 工具做过项目的经验。这要求看起来确实很高。
但事实上，一些大学的课程体系已经能提供这些了。在 3-5 年的学制中，它们兼顾理论和实践，并组织团队项目。与此同时，像哈佛这样的顶尖学府已经在开设大语言模型相关的课程。其他大学肯定也会迅速跟上。
在一个写代码不再那么值钱、但软件工程的其他部分更加值钱的世界里，以软件工程和计算机科学为核心的学术教育可能会成为进入这个行业不可逾越的门槛。大学还充当着"垃圾过滤器"的角色：当 AI 生成的申请塞满了招聘通道时，与本地高校直接合作能让雇主更有把握确认候选人是真人。
代码和软件的大爆发，总得有人为此负责。 如前所述，我们几乎可以肯定会看到更多代码被生成、更多软件被交付、更多的维护工作需要完成！这对基础设施提供商来说无疑是利好——云服务商、基础设施工具商、以及软件正确性验证工具都将从中受益。
而对于任何上线运行的生产软件，当出了问题时，总得有人为此负责。我不认为这个人会是非技术人员，而是那些理解 AI 工具生成的代码、能够维护这些代码的专业软件工程师——他们有能力、有知识，对基于自己的提示词部署到生产环境的代码承担责任。
我见过好几位产品经理对这场变革兴奋不已，因为 AI 能按规格生成代码，这或许意味着产品经理可以不需要软件工程师就能构建软件。但我认为事情不会这样发展：相反，软件工程和产品管理之间的边界可能会比以前更加模糊：
软件工程师变得更有产品思维，与客户走得更近。比如，他们可以迅速修复客户反馈的 Bug，而不需要产品经理的分诊或介入
产品经理变得更加亲力亲为，自己构建原型给客户演示——有时甚至不需要工程师参与，偶尔还能自己提交 Bug 修复让工程师合并
我还预期工程团队会变得更小更高效，告别过去那种更为正式的交接模式——比如产品经理写一份产品需求文档（PRD）扔给工程团队去实现新功能。
Linear 联合创始人 Karri Saarinen 这样描述这种转变——"中间层软件工作"正在消失，也就是那个曾经占据大量时间的"写代码"环节：
纯编码智能体工作流现在能够根据目标、上下文和任务直接产出可用代码。它们运行得更加独立，你需要碰代码的时候越来越少，对 IDE 的依赖也越来越小。IDE 正在从一个编写工具变成一个代码浏览器。
随着这些系统不断进化，这个中间层会越来越薄。花在手动将意图翻译成实现上的时间越来越少。
到底该构建什么，仍然是最重要的问题。（……）
[软件]设计，从这个意义上说，不是关于工件或工具的。 它是关于通过创意、探索、调研和讨论来形成并打磨意图的清晰度。它是关于决定什么重要、什么约束适用、什么取舍可以接受。好的产品工作，是去追求一种清晰——什么能让这次执行真正有意义。
在这个时代，指导和管理智能体的工作本身就成了一门手艺。
写代码不再像是在构造一个解决方案，而更像是在为好的解决方案创造涌现的条件。
有一点看起来是确定的：随着更强大的 AI 编码工具推动软件工程的演进，产品管理也会随之进化。
如果有人要反驳本文开头的那个论断——AI 将在许多团队中写出 90% 以上的代码——这完全合理。我确实在大型科技公司待过，那里的开发者本来就不怎么写代码，复杂性全在代码之外的方方面面！在这类环境中，AI 不太可能带来太大的帮助或冲击。
就连我自己的"顿悟时刻"（a-ha moment），也是在一个相对简单的代码库上发生的——那个项目有良好的工程实践（所有东西都有测试），产品本身风险也不高，容易做各种尝试。
但话说回来，最新的 AI 工具确实达到了我心目中的质量标准——"写出来的代码跟我自己写的一样好"，这意义重大！
可以预见，早期创业公司会把缰绳交给 AI，让它通过提示词来编写所有代码——至少在找到产品 - 市场契合（product-market fit）之前会这样做。本文探讨的是：当这种模式扩散开来，在 IDE 里手动敲代码变得又费时又费力时会发生什么——就像今天已经没人会用一个没有自动补全的文本编辑器来写代码一样。
好消息是：一个团队越是依赖 AI 生成代码，软件工程的基本功就越重要。 更多代码意味着更多问题，这些问题需要被更早发现、被系统性地解决。这就是好的软件工程一直在做的事情，过去如此，现在更是如此。
我认为这是一件好事：AI 会推动大家去认真思考验证（毕竟你不能完全信任 AI）、可观测性（确认东西在生产环境里真的能跑）、架构（我们会生成更多代码、更快地生成，这些代码需要被合理组织）以及约束（当交付速度更快时，你会更快地撞上资源使用、性能、可靠性等方面的天花板）。
坏消息是：变化可能会非常迅猛。 Claude Code 从 Boris Cherny 脑海中的一个想法诞生到现在，才刚刚一年多，类似的工具——OpenCode、Codex、Factory、Amp、Cursor，以及更多强大的智能体——就已经在改变软件的编写方式了。变化一直是科技行业的常态，但我不记得它曾经这么快过，也不记得它曾同时席卷整个行业！
还有一种失落感。 我正在慢慢接受这样一个大概率的现实：从今往后，我推上生产环境的代码，大部分都将由 AI 来编写。它已经写得比我快了，而且效果跟我自己敲出来的差不多。对于我不太熟悉的语言和框架，它甚至比我做得更好。
感觉有某种珍贵的东西正在被夺走，而且来得很突然。要把代码写好，需要花大量的功夫——学会编写能运行的代码、学会阅读和理解复杂代码、学会在代码出问题时调试和修复。我至今记得大学里第一堂"真正的"编程课（学 C 语言）让我多么望而生畏，记得第一份工作面对复杂代码库时那种迷茫无措，记得花了好几年通过实践、向其他开发者学习、读书、看博客才慢慢精进这门手艺。一旦你达到了相当高的水平，你就拥有了一种有价值且容易验证的能力——写出能跑的代码就是证明！
我关于构建软件的一些最美好的记忆，就是关于写代码的。进入心流状态，脑海里同时平衡着好几个想法，手指飞速地把它们敲出来，然后编译代码、运行代码，看到——"太好了"，一切按预期工作！
说实话，这种关系一直爱恨交织——写复杂代码需要的那种高度专注，本身就让人又爱又恨。然后还有时间估算引发的各种冲突：当你沉浸在一个难题中进入心流状态时，时间的流速是不一样的。
我不禁想：从编写复杂代码的艰难中获得的那种成就感，未来还会有吗？是的，AI 很方便，但也有一种失去。
又或许，当 AI 智能体介入后，"进入心流"会转变为思考更高层次的问题，同时指挥 AI 去编写更复杂的代码？
不管怎样，地震级的巨变也意味着令人兴奋的新机遇。 我还从未在一场重大变革发生的当下就清醒地意识到它正在发生。这一次，我确信自己的编码方式将在 2026 年发生翻天覆地的变化，而由此产生的连锁反应将数不胜数。
变化能创造更好的职业机遇、开辟新的成功路径，同时也带来大量的兴奋与忐忑。我估计五年后，市场对软件专业人才的需求会比今天更高，部分原因正是 AI 创造的软件数量大爆发。有了这些更强大的新工具，我们正在摸索——在这个未来，世界级的软件工程到底意味着什么。
你怎么看更强大的 AI 工具可能给我们这个职业带来的变化？欢迎在下方留言。