AI 正在刷新整个科技圈，而软件工程可能是变化最明显的地方之一。
Gergely Orosz 是一名软件工程师和工程管理者，曾在 Uber、Microsoft、Skype、Skyscanner 等公司工作，也一直在关注 AI 到底正在怎样改变软件开发。
最近，他在纽约参加 LDX3 工程领导力大会，并花了几周时间准备了一场演讲。期间，他走访了 OpenAI、Anthropic 等 AI 实验室，与 Ramp、Uber 等公司交流，也拿到了一些来自 GitHub、Factory AI、Linear 等公司未公开的数据。
他想搞清楚的其实很简单：AI 已经把软件工程推到了哪一步？
整理过去一年的变化后，Gergely 发现，有些事情一年前还不存在，现在已经变成了日常；有些变化正在悄悄改变开发者的工作方式；但也有一些当初大家以为会被 AI 改变的事情，到现在其实没怎么变。
这场演讲没有围绕某一个模型展开，而是从五个问题出发：
- 变化速度。 科技行业从未经历过如此大规模、如此迅速的变化。
- 发生了什么变化。 如今，几乎已经没人再手写代码了；同时使用 5～10 个 AI Agent 正变得越来越普遍；IDE 的存在感正在减弱；除此之外，过去一年里还有另外 13 个明显的变化。
- 哪些东西出了问题。 人们过去对代码产出的很多假设已经不再成立；代码审查逐渐变成了一场“表演”；代码质量和可靠性正在下降；还有更多类似的问题。
- 哪些东西仍然没变。 团队依然重要，规划也依然重要；非工程人员依然不会直接把代码部署上线；还有一些事情并没有改变。
- 接下来会发生什么？ 云端编码 Agent 和各种 Harness 已经开始出现，工程师可能会逐渐不再阅读代码，一些公司也正在建设一种全新的 AI 基础设施。这些变化才刚刚开始，而且很可能会进一步加速。
下面这篇文章，就是 Gergely Orosz 对这场变化的一次集中记录。
变化的速度
科技行业的人其实早就习惯了变化。互联网从无到有、从少数人的新鲜事物变成如今无处不在；移动通信出现，智能手机迅速普及；云计算从一个相对小众的技术领域逐渐发展起来；还有 Go、Rust 等编程语言，以及 React（Web）和 Jetpack Compose（Android）这样的框架不断出现。
但即便经历过这么多变化，今天 AI 带来的影响，无论规模还是速度，都仍然是前所未有的。业内资深人士 Martin Fowler 在 The Pragmatic Summit 上就是这样形容的：
“没有任何一项技术像 AI 这样，以如此大的规模冲击整个行业。这和我们过去面对的任何变化都完全不是一个量级。
从更小的范围来看，我们曾深度参与过面向对象语言的发展。当时，面向对象语言让很多人感到害怕，但我们并没有那么担心，因为我们本身就是这场变化的一部分。
互联网也给我们所有人带来了巨大的影响。当然，我们当时也一直在推动敏捷软件开发。敏捷对很多组织产生了非常大的影响，这一点从他们当初有多么强烈地抵制它，就能看出来。
但对于那些其他变化，我们一直需要不断告诉人们它们有多重要、有多大价值，并试图说服大家接受它们。听起来可能有些不可思议，但即使是互联网，当时也有人认为它并没有那么重要！
可对于 AI，已经没有什么可争论的了。你不可能对它视而不见，否认它的重要性。”
我的看法也差不多。毫无疑问，我们正处在一场大规模技术变革的开端。等这场变化真正展开之后，软件开发的方式将与过去几十年的做法明显不同，但开发过程中也会有一些东西继续保留下来。
至少可以确定的是，开发工具和最佳实践都会发生变化，而且现在的变化速度比以往任何时候都更快。
发生了什么变化？
1、几乎已经没人手写代码了
随着今年进入第四季度，我们可以看到，这件事已经从一个趋势变成了一个巨大的行业趋势。早在 2025 年底，随着 AI 模型的编程能力大幅提升，这一变化就已经开始显现。
如今已经有大量迹象表明，大多数工程师已经不再手写代码。最近，Ruby on Rails 的创造者也因为一番言论引发了关于“手写代码是否正在消亡”的讨论，这本身也很能说明这个时代正在发生什么。
就我个人而言，我对 AI 带来的新机会感到兴奋，能够亲身经历这场变革也让人非常激动。我确信自己的编程方式将在 2026 年发生巨大变化，而且这种变化还会带来大量连锁影响。
2、同时使用多个 Agent 正变得越来越普遍
我很喜欢和 AI 实验室的工程师交流，因为他们的工作方式往往会比整个行业提前几个月。
Claude Code 的创造者 Boris Cherny 最近在一档播客中分享了他现在是怎么工作的：
“我有 5 个终端标签页。每个标签页里都有一份代码仓库的 checkout。我会轮流切换，在每个标签页里启动 Claude Code。我还会同时在 Claude Web 上运行 5～10 个 Claude，和本地运行的 Claude 并行工作。”
几个月后，在上周一期与 Cockroach Labs 联合创始人 Peter Mattis 的播客中，他也分享了类似的工作方式。
在进入 AI 时代之前，Peter Mattis 是一名效率极高的开发者，每年大约能写 10 万行代码。他说，现在自己也开始采用类似的方式：
“很多时候，我会并行处理多个事情。我发现自己同时处理大约 5～10 个 Agent 会话时，认知负担是比较合适的。但有时候，这些会话中的每一个还会继续启动多个子 Agent 来完成不同的事情。”
我还问了一位以前在 Uber 共事的同事，他现在是怎么工作的。这位工程师同样非常高产，目前在 Linear 担任软件工程师的 Dima Zaytsev 告诉我：
“过去的世界很简单：一只鼠标、一块键盘、一块屏幕。你在物理上不可能同时处理多个事情。但现在，你已经不再受到这个限制。
我现在会在本地同时保留 5～10 个 worktree（工作树），然后在它们之间不断切换。给一个 Agent 提示词，让它开始工作；趁它运行的时候，我再切到另一个 Agent，测试它的输出或者检查代码。”
我认识的大多数高产软件工程师，一年前还在手写代码，而现在，他们几乎都已经不再手写代码，同时还会并行运行多个 Agent。
变化真的太大了。
3、Agent 生成的 PR 正在快速增长
GitHub 最近与我分享了一组最新数据：
Agent 创建的 PR：8 个月内增长了 9 倍。来源：GitHub
过去，我也没少批评 GitHub 持续出现的可靠性问题。但看到 Agent 生成的 PR 增长得如此之快之后，我对这个平台目前所承受的压力也多了不少理解。
这里有一个很值得注意的数据：2026 年 8 月，GitHub 上由 Agent 创建的 PR 数量已经超过了由人类创建的 PR。
合理推测一下，接下来，Agent 生成的 PR 数量可能会长期超过人类生成的 PR，成为这个平台上的常态。
为了更直观地感受 AI 生成 PR 的规模：截至今天（2025 年 10 月），GitHub 每个月完全由 AI 生成的 PR 数量，很可能已经达到人类在 2023 年底生成 PR 数量的约 3 倍。
2023 年 12 月，人类生成的 PR 数量约为 2500 万个；而如今，每个月完全由 AI 生成的 PR 数量可能已经超过 7500 万个。而且至少目前来看，AI 生成 PR 的增长速度并没有放缓。
4、Agent 生成的 Issue 也在快速增长
Agent 不只是生成 PR，它们也开始主动创建 Issue。下面这组数据同样比较少见，来自我的朋友们所在的 Linear。Linear 已经为 Agent 创建 Issue 提供了原生的 MCP 支持：
自 7 月以来，由 Agent 创建的 Issue 数量已经超过人类创建的 Issue。来源：Linear
5、Agent Skills 的使用已经成为主流
无论是工程师还是非工程师，都已经开始使用 Agent Skills。很多公司也在为全体员工建立自己的 Agent Skills 仓库，用来创建、共享和评估各种 Skills。
自主软件工厂厂商 Factory AI 分享给我的一组数据，很能说明 Skills 的使用正在快速增长：
83% 的 Factory AI 用户正在使用 Skills，相比 2 月增长了 2.5 倍。来源：Factory AI
6.IDE 正在逐渐淡出
我非常尊重软件工程师 Steve Yegge。他很擅长发现正在出现的新趋势，并进一步研究这些变化。在一次播客中，他直接表示，IDE 基本上已经走到尽头了。
Gergely：“说到开发者这份工作，你曾经说过一句可能会让很多人感到不舒服的话。你在 AI Engineer Summit 上说过，如果现在还在使用 IDE，那就是一个糟糕的工程师。”
Steve：“是的，你得稍微说得刺激一点。换个说法吧。我不会说还在使用 IDE 的人就是糟糕的工程师，因为我知道一些非常非常优秀的工程师，他们甚至比我还厉害，但在我那张 AI 使用程度图表里，他们仍然处于第一级或第二级。但我真的非常同情他们。
我从来没有像现在这样对一些人感到如此惋惜。他们已经是成年人了，而且本来就是很优秀的工程师，或者曾经是。他们会说：‘对，我用 Cursor，有时候会问它一些问题。我真的很惊讶它给出的答案。然后我会非常仔细地检查它写的代码。’
然后他们把代码提交进去，我就会说：‘兄弟，你要被开除了。而且你还是我认识的最优秀的工程师之一！’”
Steve 对自己所划分的 AI 使用阶段是这样描述的：
1. 完全不使用 AI
2. 在 IDE 中使用 AI Agent，并严格限制权限
3. 在 IDE 中使用 AI Agent，开启“YOLO”模式，也就是关闭权限限制
4. 在 IDE 中使用 AI Agent，但已经不再查看代码，而是直接与 Agent 交互
5. CLI 优先：彻底放弃 IDE
6. 同时运行多个 Agent
7. 同时运行 10 个以上 Agent
8. 自己构建 Agent 编排器，同时运行 30 个甚至 100 个以上的 Agent
Steve 认为，那些已经“AI 上头”的工程师最终会放弃 IDE。而我从市场上看到的一些数据，也正在支持他的判断。
Antigravity 1.0 是最后一个基于 VS Code Fork 发布的 IDE，于 2025 年 11 月推出。此后，再也没有主流的 VS Code Fork IDE 发布。到了 2026 年 5 月，Antigravity 2.0 发布时，产品已经开始摆脱传统 IDE 的概念。
Codex 在 2026 年 2 月以非 IDE 产品的形式推出。尽管团队在 2025 年底还曾纠结是否应该放弃 IDE 这一概念，但最终他们对没有继续走 IDE 路线感到庆幸。
Cursor 也开始摆脱 IDE。2026 年 4 月，Cursor 重新发布，去掉了传统的 IDE 界面。现在它的形态已经与 Codex 和 Claude 桌面应用非常接近。今年夏天我与 Cursor 团队交流时，他们告诉我，目前仍然为现有企业客户维护那个“传统”的 VS Code Fork 版本，但对他们来说，未来已经属于 Agent。
JetBrains 似乎也在急着从 IDE 转型。JetBrains 曾经打造了不少深受开发者喜爱的 IDE，但如今这家公司也开始转向 JetBrains Air，以及更加 Agent 化的开发环境。
现在的各种编程工具看起来都越来越像这样，IDE 去哪儿了？来源：Cursor
JetBrains 也加入了这一趋势，推出 JetBrains Air。
在我们讨论 IDE 为什么正在慢慢消失时，业内传奇工程师 Kent Beck 告诉了我一件很有意思的事情：
“并不是说我们不再需要更多视角和上下文来帮助人类做决定，而是我们所面对的上下文已经发生了变化。”
我不禁在想，真正发生的事情是不是 IDE 正在演变成一种完全不同的东西，以便更好地与编码 Agent 配合。
Steve Yegge 也谈到过类似的观点：既然我们已经不再负责亲手编写代码，那么 IDE 就需要从代码编辑器转变成一种用于对话和监控的界面。
我还想补充一点：IDE 也需要变成一个验证和检查的界面。我们怎么知道 Agent 生成的结果确实符合预期？怎么验证它通过了哪些测试？怎么查看最终效果？又怎么直接尝试 Agent 构建出来的东西？能够解决这些问题的工具肯定会出现，而且最终也会被广泛采用。
7.每家公司都在构建自己的 Harness / Agent 平台
今年 8 月，我曾经在社交媒体上提出过一个问题：如果一家严肃的科技公司还没有构建自己的 AI Harness，它还能不能算是一家真正有竞争力的科技公司？
我之所以提出这个问题，是因为到了现在，大多数中型及以上规模的公司都已经开始构建自己的 Agent Harness。这里举几个例子：
Ramp 正在构建 Inspect，我们之前已经对这个项目做过深入报道。
Stripe（Minions）、Uber（Minion）、Block（Goose）、Shopify（River）。
Google（Agent Smith）、Meta（Devmate）、Amazon（Kiro + Crew）、Dropbox（Nova）、Spotify（Honk）。
DoorDash（Flux）、Grab（LLM-Kit）、WorkOS（Horizon）、Hubspot（Crucible）。
Monzo（Agent Chip）、Sierra（Pinecone）、Harvey（Spectre）、Browserbase（bb）。
……还有很多很多。
8.很多开发工作从 Slack 开始
我在拜访这些初创公司的过程中发现，越来越多的开发工作会直接从 Slack 里启动。
在 OpenAI，是“@Codex，帮我实现这个”；在 Anthropic，则是“@Claude，把这个做出来”；而在 Linear，则是“@Linear，处理一下这个”。
越来越多的初创公司都有自己的 Slack 编码 Agent 集成，而且很多都是自己定制的。
当编码 Agent 深度集成到公司的技术栈中时，它们的效果非常好。比如，在 Slack 里让 Agent 接到任务，然后启动一个运行在云端的编码 Agent，整个过程可以直接串起来。
9.Agentic 软件工厂正在各处出现
此前我们已经深入报道过 OpenAI 如何构建自己的 Agentic 软件工厂。而那篇文章发布之后，很多读者给我们的反馈都是类似这样的：“我们也在这么做！”
很多读者表示，他们所在的公司也正在构建类似的“Agentic 软件工厂”。
来自此前的深度报道《Inside OpenAI’s agentic software factory》。
所谓“Agentic 软件工厂”，就是在大量现有系统中加入 AI 能力，比如 CI/CD 系统。举个例子，Agent 可以通过 Slack 与 CI/CD 系统进行交互；同时，公司也可以直接构建全新的 Agent 系统，例如 Agent 化的代码审查工具、OpenAI 的 Agentic 部署系统，或者 Perf Factory。
10.迁移不再需要花上几年时间
我们现在看到，很多过去可能需要几年才能完成的迁移，如今只需要几周或几个月：
Anthropic：将包管理器 Bun 从 Zig 迁移到 Rust，只用了 11 天，而原本预计需要 1.5 个工程师年。
OpenAI：正在将 API 层从 Python 迁移到 Rust。目前迁移大约花了 5 个月，如果没有 AI，这项工作原本可能需要几年。
Airbnb：将 3500 个端到端测试文件从 Enzyme 迁移到 React Testing Library，只用了 6 周，而不是几年。
Asana：将 4000 个端到端测试文件从 Enzyme 迁移到 React Testing Library，只用了 2 周，而原本预计需要分摊到 5 年完成。
Uber：将分布在 1500 万行代码中的 60 万个 JUnit 4 测试迁移到 JUnit 5，只用了 4 个月，而原本预计需要几年。
11.AI 成本已经成为工程团队重点关注的问题
今年 5 月，我们报道过一个趋势：一些公司开始希望削减工程部门的 AI 开支。上个月，我又报道了科技公司正在转向开源 AI 模型，以降低 50% 甚至更多的 Token 成本。
Uber 就是一个很好的例子。虽然它的 Token 使用量一直在增长，但由于采用了开源模型，并通过智能模型路由来控制成本，自 5 月以来，整体成本基本保持不变：
Uber 的单 Token 成本下降了 50% 以上。来源：The Pulse
我的文章发布三周后，彭博社也确认了完全相同的趋势。正如我在之前的深度报道中提到的，对大多数公司来说，成本下降主要来自两个方面：更低成本的模型，以及智能路由。
如果你只能做两件事，那么可以优先考虑这两种方法。
降低 Token 成本最高效的方式。图片来源：Databricks
12.项目只需要一两名工程师就能完成
Claude Platform 工程负责人 Katelyn Lesse 曾告诉我，他们的团队在 Anthropic 内部是如何工作的。以下内容来自我们之前的深度报道：
“对于一个单独的项目来说，你通常不能让超过两个人同时参与。原因是每名工程师本身就已经在运行多个 Agent。
所以作为工程师，你实际上已经在和自己的 Agent 对抗了，因为它们在实现过程中会互相踩脚。在这样的工作方式下，你不可能再加入那么多真人工程师，因为每个人还会带着一堆自己的 Agent！”
现在，我在大大小小的公司里都开始看到类似的情况。
其他变化
13. 工程领域的专业化正在消失。具体来说，市场对 iOS、Android 和前端等专业方向的需求似乎正在下降，而对“通用型”软件工程师的需求正在增加。我们在《2026 年软件工程就业市场现状》的报告中通过数据讨论过这一趋势：移动端和前端岗位需求正在下降，而 AI 和 FDE（前线部署工程师）相关岗位的需求正在快速增长。
14. 团队正在变得更小。项目正在由更少的工程师完成。在初创公司内部，团队规模似乎也正在不断缩小。
15. 初级工程师招聘减少。在《2026 年软件工程就业市场现状》的深度报道中，我们讨论过为什么现在毕业生和实习生越来越难找到工作。
16. Agent 基础设施正在成为一个独立的领域。大多数中型及以上规模的公司都在构建自己的 Agent 平台，而基础设施团队也正在越来越多地转变成 Agent 基础设施团队。
哪些地方出了问题？
关于代码数量和产出频率的假设正在失效
过去，一个普遍存在的观点是，代码量大致会以线性的方式增长。但有了 Agent 之后，代码行数和提交次数都在呈指数级增长，GitHub 的数据就展示了这一点：
（人类）代码审查已经失效
一家中型初创公司的软件工程师告诉我一件事，这几乎已经成为整个行业公开的秘密，包括那些仍然保留代码审查流程的公司。
“所有人都在演一场代码审查的戏，但考虑到每天丢到你面前的变更量，我发现大家最终都会选择阻力最小的方式：放弃真正的审查，然后给所有东西都盖上 LGTM 的章。
我们自己也正在逐步取消这个流程，允许大家采用一些快捷方式，而这已经极大地提高了生产力。”
在 LDX3 大会上，当现场观众听到上面加粗的那句话时，反应非常强烈。
如今，在大多数公司里，确实存在一种“代码审查表演”。事实是，没有任何工程师能够跟上 5～10 倍于过去的代码审查量，所以大多数人实际上并不会认真检查这些代码。
只由 Agent 进行代码审查正在成为趋势
Linear 的最新数据显示，完全由 AI Agent 审查 PR 的情况正在增加。我预计这一趋势还会继续：
AI 独立完成的 PR 审查正在增加。来源：Linear
代码质量和可靠性正在下降
我们在很多日常使用的数字产品中都能看到这一点。正如 Pi 的创造者 Mario Zechner 在播客中所说：
“一切都坏掉了。现在的软件给人的感觉就像变成了一团脆弱的混乱，98% 的可用率正在成为常态，而不是例外，就连一些大型服务也是如此。
用户界面里也出现了各种奇奇怪怪的 Bug，你会觉得 QA 团队本来应该发现这些问题。
我承认，这种情况其实在 Agent 出现之前就已经存在了很长时间。但现在，我们似乎正在加速这一过程。”
今年 3 月，我们曾在《AI Agent 真的在拖慢我们吗？》一文中讨论过类似现象：AI 使用越多，软件质量反而可能越差。
基础设施容量短缺
现在 GPU 短缺和内存短缺已经是市场上的公开事实。除此之外，CPU 短缺也正在成为一个越来越明显的问题。正如我上个月报道的：
“显然，现在如果没有和云服务商建立长期合作关系，几乎不可能在 Spot 实例上拿到 CPU。
此外，如果想预订特定的 CPU，现在也需要提前几个月进行。一些云服务商甚至会拒绝某些预订，因为他们没有足够的 CPU，或者没有客户需要的那种 CPU。”
如果你的公司 CPU 使用量不小，那么现在就值得开始考虑锁定算力容量。正如我最近写到的：
“现在无疑是锁定更多 CPU 容量的最佳时机。我听到一些传闻，一些云区域已经不再接受新租户，因为所有 CPU 容量都已经被租出去；在其他地方，谈判也变得非常困难。
我还听说，一些客户现在就已经开始付费预订未来的容量，而这些容量要等到 12 月才会在数据中心上线。从云服务商的角度来看，这似乎有些趁火打劫，但需求实在太高了，所以他们很可能就是通过这种方式来决定新容量的分配，同时还能获得远高于平常的利润。如果你的公司工作负载是动态的，而且过去一直使用 Spot 实例，那么现在可能是分配固定容量的好时机，即使这样做的成本更高。
如果你预计业务还会有明显增长，那么现在提前锁定容量，可能意味着未来在某些云服务商或某些区域仍然拥有可选择的空间。”
个人专注力和生产效率受到冲击
软件工程师 Dima Zaytsev（目前在 Linear，过去曾是我在 Uber 的同事）告诉我一件关于 AI 和生产力的事情，我觉得非常有共鸣：
“上下文切换变得非常多：总有另一个 Agent 在等着你的回复。而且，这本身就是更多的工作。
AI 刚开始快速发展的时候，我感觉自己的生产力比同事高得多：别人需要一天完成的事情，我一个小时就能做完。但现在，大家的工作预期已经变成了同时处理多个事情。所以，与 AI 出现之前相比，我反而感觉自己现在的工作更多了。”
工程负责人开始选择职业休整
最近出现了一个有意思、也有些出人意料的趋势：一些 CTO、工程负责人和工程副总裁正在辞职，而且很多人在离职时并没有安排好下一份具体工作。
一位要求匿名的现任 CTO 告诉我：
“AI 带来的这种变化，会让做东西的人重新想要做东西。我们想再次开始构建，因为我们可以做得更多、做得更快，而且使用更好的工具。这样一来，我们可以用更少的优秀人才完成更多事情，从而提高团队的‘人才密度’，等等。
现在真的是一个非常适合做东西的时代。而且只会越来越好。人们只是想离它近一点。他们想亲自构建东西，看看借助这些新工具，自己究竟能走多远。
我身边有很多朋友，就是你所说的那些‘离开 CTO 岗位的人’。还有更多人正在从大公司的管理岗位转回 IC（个人贡献者）岗位。
他们的故事基本都和我上面说的一样。他们只是觉得，现在真的是一个令人兴奋的构建时代。归根结底，构建东西本来就是他们当初进入这个行业的原因。”
哪些事情仍然没有改变？
在 LDX3 的主题演讲中，我还讨论了一些在 AI 出现之后基本没有发生变化的事情。
团队仍然很重要
今年 7 月，Claude Platform 工程负责人 Katelyn Lesse 告诉我：
“我听一些人说过，‘我们现在就是两个真人加上一堆 Agent。’我会告诉他们，我们现在并不是这种状态。我仍然有一些团队，他们的职责就是负责一部分软件，持续迭代，负责 on-call 等等。
虽然这些人每个人都因为 AI 而获得了巨大的能力提升，但团队的规模和形态仍然差不多。我们仍然是两块披萨团队。”
Katelyn 所在的公司是全球最“AI 化”的公司之一。如果在这样的公司里，团队的重要性依然和 AI 出现之前一样，那么说团队结构在整个行业依然重要，也并不过分。
规划仍然存在，至少复杂项目是这样
复杂项目仍然需要一个漫长的规划阶段。Katelyn 还谈到了 Claude Managed Agents 的规划过程：
“我们的规划过程看起来更像传统的、AI 出现之前的项目规划。你知道每个团队都会有这样的项目：大家不断提出某种版本的相同想法，不停地讨论、反复思考，直到最后终于决定去做。
Managed Agents 对我们团队来说就是这样。项目刚开始的时候，我们手里就已经有一些最早可以追溯到两年前的文档，里面记录着各种想法和建议。”
测试和验证仍然非常重要
Bun 的创造者、目前在 Anthropic 工作的 Jarred Sumner 说：
“AI 基本上写了所有代码，但我们也让 AI 基本上写了所有测试。
在 AI 出现之前，对于可以真正用于生产环境的软件，我们花在写测试上的时间和写代码的时间大致相同。现在有了 AI，情况依然如此。
你需要一种方法来确保自己的代码值得信任，而测试可能就是最好的方法。”
在 LDX3 主题演讲之前，我与多家公司进行了交流。在每家公司，我都观察到一个共同点：大家正在投入大量精力去验证 AI Agent 的输出。
这其实很好理解：代码审查已经不像过去那样有效了，我们产生了更多代码，因此必须确保这些代码不会把生产环境搞崩。
非工程人员仍然不会直接把生产代码发布上线
最近几周，社交媒体上出现了不少讨论，认为 AI 已经让产品经理、设计师以及其他非技术人员能够直接把生产代码发布上线。
所以，我专门向 AI 实验室、初创公司以及其他公司询问了这个问题。我的结论是：我没有找到任何一家公司的 PM、设计师或其他非技术人员会直接把代码发布到生产环境。
但我确实了解到一些情况：这些人会使用 Agent 创建 Bug 修复，有时候甚至自己都不知道已经这么做了；或者让 Agent 开发一些新功能，最后再交给开发人员进行审查。
此外，原型开发的情况则非常多。但最终，仍然是工程师负责决定哪些东西可以发布到生产环境，哪些不能。
我们正在重新发现一些与 AI 配合得很好的老方法
我越来越发现，那些“老”的最佳实践，在使用 AI 构建更好的软件时依然非常有用。其中包括编写单元测试、优先构建一条“黄金路径”、提前设计应用架构，甚至使用设计模式。
接下来会发生什么？
我们可以通过观察那些已经开始出现、而且很可能会持续下去的趋势，来判断科技行业接下来会走向哪里。
云端 Coding Agent + Harness 将成为主流
大多数公司的开发者最终都会在云端运行 AI Agent，而不是在本地运行。在创新型科技公司内部，“自己构建云端 Agent Harness”似乎正在成为一种趋势。
我还预计，Anthropic、OpenAI、SpaceX 等公司，以及其他厂商，会开始大力推动自己的云端 Coding Agent 产品，同时会有更多初创公司开始构建自己的云端 Harness。
工程师将不再阅读代码
我们最终会停止阅读代码。目前还很难判断这会在什么时候发生：今年、明年，还是更远的未来。但可以预见的是，未来我们当中真正会认真阅读 AI Agent 生成代码的人可能会越来越少。
我通常会非常关注 Honeycomb 联合创始人兼 CTO Charity Majors 的观点，因为她面对新技术时通常是一个“默认持怀疑态度”的人，同时也是一名非常出色的工程师，而且敢于表达自己的看法。
今年 8 月，在我们的播客中，她问了一个问题：
“什么情况下，你才会愿意在自己没有阅读代码、也没有理解代码的情况下，把它发布出去？因为这就是工程。”
Charity 指出，运维和测试人员已经有几十年的时间来解决这样一个问题：如何把自己没有编写、也不理解的代码发布到生产环境，同时还要确保它能够正常运行。
软件工程师最终加入这个群体似乎也是不可避免的。这其实非常讽刺，因为很长一段时间以来，软件工程的核心就是工程师自己编写代码，并且理解自己编写的代码。
企业会构建全新类型的内部基础设施
我们将看到这些系统被重新设计，以便更好地与 Agent 配合。例如：
CI/CD：Agent 化的评估能力将成为流水线的一部分。
Agentic 软件工厂：企业需要弄清楚哪些事情适合交给 Agent，哪些事情不适合。
Agent 进入部署、可观测性和故障管理流程：Agent 将逐渐成为这些系统的一部分。
Agentic 可观测性肯定也会成为一个独立的问题领域和专业方向。
我们需要解决的问题包括：如何确保已经部署、直接面向客户的 Agent 按预期工作？如何确保那些由 Agent 构建和修改的系统也确实能够按预期运行？
重构、迁移和彻底重写将迎来一个“黄金时代”
过去因为需要花费同样长的时间，所以被拖延了好几年的迁移和重写，现在应该不需要超过几周。这意味着，我们已经没有什么理由继续拖延了。
如今，工程师已经越来越清楚 AI Agent 在重写、重构和迁移方面到底有多强。与此同时，我们也可以更快地清理技术债务，而没有必要继续容忍一个自己并不满意的系统状态。
在初创公司招聘中，AI“熟练度”和“积极性”会越来越重要
有一个趋势我还没有写太多，但它已经正在发生：初创公司开始倾向于招聘那些对 AI 持积极态度的工程师。
一家 D 轮初创公司的工程负责人告诉我：“AI 积极性是我们开始在招聘流程中重点考察的一项能力。我们希望加入团队的人愿意和我们一起探索，看看借助 AI，我们到底可以把事情做到什么程度。”
现实是，AI Coding Agent 已经无处不在，而 Agent 化系统很快也会大量出现。
这将带来对新一代系统建设者的大量需求：他们需要愿意并且能够构建下一代系统，同时，对这个问题领域感到兴奋也会成为一种基本要求。
这其实与初创公司招聘工程师时，希望他们认同“快速增长”的理念并没有太大区别。
或者说，这也类似于一家公司更愿意招聘那些能够直接接受现有技术栈的工程师，而不是坚持要求使用自己个人习惯的技术栈。
拥有深厚领域知识的工程师会越来越抢手
在纽约，我和《Software Engineering at Google》的主要作者 Titus Winters 进行了一次交流。他告诉我：
“无论在哪里取得成功，你需要的都是三样东西：智慧、经验和魅力。智慧意味着：怎么做。经验意味着：应该做什么。魅力意味着：如何说服别人去做。当智慧变得普遍之后，经验和魅力就会变得更加重要。”
放到软件工程领域，“经验”最容易通过成为某个领域的专家来获得。
所以，如果你在一家金融科技公司工作，就去学习金融行业以及它的客户，从而成为一名更有价值、也更受市场需要的工程师。
如果你在农业科技公司工作，或者从事其他任何领域，这个道理同样适用。
最后：提醒自己当初为什么进入科技行业
在我与 Peter Mattis 的播客中，他是 Cockroach Labs 的联合创始人兼 CTO，我们最后聊到了一个问题：现在变化的速度实在太快了，要一直跟上这种变化，会让人感觉非常疲惫。
他说：“提醒自己，你当初为什么进入这个行业。我之所以成为一名软件工程师，是因为我喜欢构建东西。现在，我可以更快地构建东西，而且还不用像以前那样做出一些妥协！”
本文来自微信公众号“CSDN”，编译：苏宓 ，36氪经授权发布。