Gergely Orosz 梳理 2026 年科技行业现状：AI 重塑软件工程
The state of the tech industry in 2026
Gergely Orosz 在 LDX3 大会主题演讲中给出 2026 年科技行业快照：多数工程师已不再手写代码，并行运行 5-10 个 agent 成为常态，GitHub 上 agent 生成的 PR 八个月增长九倍，2026 年 8 月已超过人类 PR 数量。
作者走访 OpenAI、Anthropic 等团队并拿到 GitHub、Linear、Factory AI 的未公开数据，梳理出 AI 时代工程实践的变化、失灵与不变之处。
我最近在纽约的 LDX3 工程领导力大会上做了主题演讲，与会者有 2,000 多位工程领导者、CTO、总监级及以上和资深工程人员，我试图在演讲中描绘出科技行业此时此刻所处的位置。
此前，我有机会造访了 AI 实验室 OpenAI 和 Anthropic，见到了 Ramp、Uber 等创新初创公司，并从 GitHub、Factory AI 和 Linear 获取了新的、未公开发布的数据。这场演讲的重点是 AI 实验室、风投支持的初创公司以及大型科技公司内部的趋势。感谢这些团队的慷慨接待！
大会之前，我花了数周时间梳理并记录一年前还不存在——或者当时还远未成气候——的趋势，以及当前已经失灵的东西，还有一些保持不变的事物。今天，我们涵盖：
变化的速度。在科技行业，变化从未如此大规模、如此之快。行业传奇 Martin Fowler 也证实了这一点。
变了什么：几乎没有人再手写代码，同时协作 5-10 个智能体更为常见，IDE 逐渐式微，以及过去一年中的另外 13 项变化。
什么失灵了：关于代码产出的假设崩塌了，代码评审变成了走过场，质量和可靠性下降，等等。
什么依然如故：团队依然重要，规划依然重要；非工程人员依然不交付代码，等等。
接下来是什么？云端编码智能体和 harness、工程师不再阅读代码、公司构建新型 AI 基础设施，等等，这些都已经开始，并且应该会加速。
你可以观看完整的演讲，时长 29 分钟：
本文底部在某些邮件客户端中可能被截断。在线阅读完整文章，不受干扰。
1. 变化的速度
科技行业的人早已对变化习以为常：见证互联网从零到无处不在、移动通信的到来和智能手机的爆红、云计算从小众关切中崛起，以及 Go 和 Rust 等编程语言、React（Web）和 Jetpack Compose（Android）等框架的发展。
尽管如此，AI 当下所产生影响的范围和速度依然史无前例。行业资深人士 Martin Fowler 在 The Pragmatic Summit 上这样描述：
“没有什么能像 AI 那样带来如此巨大的冲击。这和我们此前面对过的任何东西都不在一个量级上。
在较小的范围内，我们深度参与了面向对象语言的成长。[面向对象语言]吓到了很多人，但没有那么吓到我们，因为我们是其中的一部分。
互联网对我们所有人都产生了巨大影响。当然，我们当时也在传播敏捷软件开发的挑战。[敏捷]对很多组织产生了非常大的影响，因为他们抵制的力度有多大，你就能看出来。
但[对于所有其他那些变化]我们一直在谈论它们有多重要、有多大价值，并试图说服人们认识到它们的重要性。这听起来可能令人惊讶，但即便是互联网，也有人不觉得它重要！
而对于 AI，它的重要性毫无争议。你无法戴上眼罩去否认这件事的重要性。”
我自己的看法与之类似；我们无疑正处于一场大规模技术变革的开端，变革之后，软件的构建方式将与过去几十年的做法截然不同，尽管开发的某些环节仍将保持不变。至少，工具和最佳实践会有所不同，而且一切变化得比以往任何时候都快。
2. 发生了什么变化？
#1 再也没有人手写代码了
随着今年进入第四季度，我们看到自 2025 年底模型在编程能力上大幅提升以来，这已经固化为一个大趋势。与此相关，在今年第一篇文章中我们提出了一个问题：当 AI 编写几乎所有代码时，软件工程会怎样？
如今，有大量迹象表明大多数工程师已经不再手写代码，最近 Ruby on Rails 的创造者引发了一场关于“手写代码之死”的辩论，这也是时代的一个标志。就我个人而言，我对 AI 创造的新机遇感到兴奋，能亲身体验这场革命令人激动。正如那篇深度探讨中提到的，我确信我的编程方式在 2026 年将发生巨变，并会带来大量连锁反应。
想了解更多关于这个话题的内容，请查看最近一期的The Pulse。
#2 同时使用多个并行 agent 越来越普遍
我喜欢和 AI 实验室的工程师交流，因为他们的工作实践往往领先业界其他人数个月。Claude Code 的创造者 Boris Cherny在播客中透露了他完成任务的新方式：
“我有 5 个终端标签页。每个标签页都有一份他们仓库的检出。我会轮流在每个标签页中启动 Claude Code。我还会在 Claude Web 上运行 5-10 个 Claude，与本地 Claude 并行。”
这些言论发表几个月后，在上周的播客中，Cockroach Labs 联合创始人 Peter Mattis——一位极其高产的开发者，在 AI 出现之前每年编写约 10 万行代码——表示他也在做类似的事情：
“我经常并行做事。我发现我的认知负荷大约是同时进行 5-10 个 agent 会话。但有时这些会话会有许多子 agent 在做事情。”
我还问了 Uber 的一位前同事，他也是一位极其高产的软件工程师，如今是如何工作的。Dima Zaytsev（现在是 Linear 的软件工程师）告诉我：
“过去的世界很简单：一个鼠标、一个键盘、一个屏幕。你物理上无法同时做一件以上的事情。现在，你不再有这个限制。
我最终会在本地有 5-10 个（字面意义上的）工作树，在它们之间轮换。给一个 agent 提示，在它工作时，转到另一个去测试输出或审查代码。”
我遇到过的几乎所有最高产的软件工程师——一年前还在手写代码——如今都不再手写代码，而且还会并行运行多个 agent。变化真大！
#3 agent 生成的 PR 迅速增长
GitHub 与我分享的最新数据：
我曾批评过 GitHub 持续存在的可靠性问题，但看到 agent 生成的 PR 增长如此之快，我对这个平台所承受的负载多了很多体谅。
值得思考：2026 年 8 月，GitHub 上 agent 撰写的 PR 数量超过了人类撰写的数量！可以合理推测，未来该平台上 agent 生成的 PR 数量将永久超过人类生成的 PR 数量。
为了让大家对 AI 生成的 PR 数量有个概念：截至今天（2025 年 10 月），每月完全由 AI 生成的 PR 数量可能是 2023 年底人类生成 PR 数量（2023 年 12 月为 2500 万）的 3 倍（很可能超过 7500 万）。而且 AI 生成 PR 的速度似乎并未放缓，至少目前还没有。
#4 Agent 生成的问题也在快速增加
Agent 不仅在生成 PR，它们还在提工单。又有一些独家数据，这次来自我在 Linear 的朋友，他们为 agent 创建问题增加了一流的 MCP 支持：
#5 Agent 技能的使用已成主流
工程师和非工程师都在使用 agent 技能，许多公司正在构建自己的 agent 技能仓库，供全体员工创建、分享和评估。关于技能使用量大幅上升的一个有趣数据点来自自主软件工厂供应商 Factory AI，他们与我分享：
#6 正在消亡的 IDE
我非常尊重软件工程师 Steve Yegge，他擅长识别新兴趋势并加以了解。在一期播客节目中，他说 IDE 实际上已经终结了：
Gergely：“说到开发者这个职业，你说过一些可能会让很多人不快的话。你在 AI Engineer Summit 上说过，如果你现在还在用 IDE，那你就是个糟糕的工程师。”
Steve：“是啊，你得有点挑衅性。让我这样说吧。好吧，我不会说你是个糟糕的工程师，因为我认识一些非常非常优秀的工程师，比我强，他们在我的[AI 使用]图表中还处于第一或第二级？但我为他们深感惋惜。
我对他们怀有我这辈子从未有过的怜悯。为这些成年人，这些优秀的、或者曾经优秀的工程师。他们会说，‘是啊，你知道，我用 Cursor，有时候会问它问题。我对它的回答印象深刻。然后我会非常仔细地审查它的代码。’
然后我把它提交上去，我心里想：‘老兄，你会被炒鱿鱼的。而你是我认识的最优秀的工程师之一！！’“
Steve 这样描述他的 AI 使用层级：
不使用 AI
IDE 中的 AI agent，权限严格
IDE 中的 AI agent，开启“YOLO”模式（关闭权限）
IDE 中的 AI agent，不再看代码，而是与 agent 交互
CLI 优先：放弃了 IDE
并行运行多个 agent
运行 10 个以上 agent
构建自定义 agent 编排器来运行 30 个以上（或 100 个以上）agent
Steve 认为“AI 上头”的工程师会放弃 IDE，而我看到的市场数据也支持这一预测：
Antigravity 1.0 是最后一个发布的 IDE，基于 VS Code 的分支。它于 2025 年 11 月发布。此后，再没有基于 VS Code 分支的重大 IDE 推出。2026 年 5 月，当 Antigravity 2.0 发布时，该产品已脱离 IDE 概念。
Codex 于 2026 年 2 月作为非 IDE 产品发布，他们对此感到庆幸，尽管在 2025 年底曾对脱离 IDE 概念感到纠结。
Cursor 已脱离 IDE。2026 年 4 月，Cursor 重新发布并取消了 IDE 界面。它现在看起来与 Codex 和 Claude 桌面应用非常相似。夏天我与他们的团队交谈时，他们告诉我，他们为现有企业客户保留了“旧版” VS Code 分支版本，但对他们而言，未来是智能体化的。
JetBrains 似乎急于从 IDE 转型。JetBrains 为开发者打造了一些最受喜爱的 IDE，但该公司现在也正在转向 JetBrains Air，以及智能体开发环境。
在我们讨论 IDE 为何正在慢慢消失时，行业传奇人物 Kent Beck 告诉了我一些有趣的话：
“并非我们基于人类做决策时不再需要更多的视角和上下文；而是上下文已经变了。”
我想，真正发生的事情可能是 IDE 正在演变成一种不同的形态，以便更好地与编程智能体协作。Steve Yegge 也谈到，IDE 需要进化为对话与监控界面，而非编辑器，因为我们已经不再亲手编写代码。
我还要补充一点，IDE 需要演变为验证与核验界面：我们如何知道智能体的输出符合预期，如何验证它通过了哪些测试、它看起来怎么样，以及你能否试用智能体构建出的任何东西。这类工具必然会出现，并将被广泛采用。
#7 人人都在构建自己的 harness/智能体平台
八月份，我在社交媒体上提出了一个问题：一家严肃的科技企业是否有可能在没有构建 AI harness 的情况下存在：
我这么问是因为，大多数中型及以上公司如今都已构建了自己的智能体 harness！举几个例子：
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 集成——通常是定制的那种。
当编程智能体深度集成到公司的技术栈中，当 Slack 智能体启动一个在云端运行的编程智能体时，效果非常好。
#9 智能体软件工厂正在各处涌现
我们曾深入报道过OpenAI 如何构建智能体软件工厂，而那篇文章的许多读者反馈都是“我们也是！”这类回应。不少读者表示，他们公司也在构建类似的“智能体软件工厂”。
“智能体软件工厂”为 CI/CD 系统等一批现有系统添加 AI 功能；例如，能够通过 Slack 与 CI/CD 交互，或创建内置智能体的全新系统，如智能体代码审查工具、OpenAI 的智能体部署系统，或 Perf Factory。
#10 迁移不再需要数年
我们看到许多原本需要数年才能完成的迁移，现在只需数周或数月：
Anthropic：将包管理器 Bun 从 Zig 迁移到 Rust，仅用 11 天（而此前估计需要 1.5 个工程年）
OpenAI：API 层正从 Python 迁移到 Rust。此次迁移耗时约 5 个月，而如果没有 AI，将需要数年
Airbnb：将 3,500 个端到端测试文件从 Enzyme 迁移到 React Testing Library：耗时 6 周（而非数年）
Asana：将 4,000 个端到端测试文件从 Enzyme 迁移到 React Testing Library：2 周，而非估计分散在五年内完成
Uber：将 1,500 万行代码中的 600,000 个 JUnit 4 测试（！！）迁移到 JUnit 5：耗时4 个月（而非估计的数年）
#11 AI 成本成为工程领域的主要关切
今年 5 月，我们报道了企业希望在工程部门削减 AI 支出的趋势，上个月，我又报道了科技公司正转向开放 AI 模型，以节省 50% 或更多的 token 成本。Uber 就是一个很好的例子：尽管 token 使用量呈上升趋势，但由于他们运行开放模型并进行智能模型路由，自 5 月以来成本一直保持平稳：
我的文章发布三周后，彭博社证实了完全相同的趋势。正如我在最初的深度报道中所说，低成本模型和智能路由是大多数公司节省成本的主要来源。如果你只做两件事，不妨考虑这些方法。
#12 项目仅靠一两名工程师即可完成
Claude 平台工程负责人 Katelyn Lesse 向我讲述了她的团队在 Anthropic 内部的工作方式。摘自我们的深度报道：
“在单个项目上，你往往不能让超过两个人参与。这是因为每个工程师已经在运行多个智能体。因此，作为工程师，你已经在与自己的智能体较劲，它们在实现上互相踩脚。在这种设置下，你根本无法容纳那么多人，而每个人还带着他们所有的智能体！”
如今，我看到无论小公司还是大公司都在发生同样的情况。
其他变化
13. 工程专业方向正在消失。具体来说，对 iOS、Android 和前端专业方向的需求似乎在减少，而对“通用型”软件工程师的需求在增加。我们在《2026 年软件工程就业市场状况》中用数据探讨了这一趋势，观察到移动端和前端需求正在下降（而 AI 与 FDE 需求激增）。
14. 团队正在变小。项目由更少的工程师完成。在初创公司内部，团队规模似乎在缩小。
15. 初级招聘减少。我们在《2026 年软件工程就业市场状况》深度分析中探讨了毕业生和实习生越来越难找到工作。
16. 智能体基础设施正在成为一门独立学科。大多数中型及以上公司都在构建智能体平台，基础设施团队正越来越多地转变为智能体基础设施团队。
3. 哪里出了问题？
关于代码数量和频率的假设
人们普遍认为代码数量大致呈线性增长。但有了智能体之后，代码行数和提交次数都在呈指数级增长，正如 GitHub 的数据所示：
（人工）代码审查已死
一位中型初创公司的软件工程师告诉了我一件几乎是业界公开的秘密，包括那些设有代码审查流程的地方也是如此。
“每个人都在上演审查的戏码，但面对涌向你的变更量，我观察到人们只是寻找阻力最小的路径：放弃审查，直接给所有东西盖上 LGTM 的章。
我们自己也在逐步淘汰这一流程，采用一些允许使用的捷径，这带来了巨大的生产力提升。”
在 LDX3 大会上，当观众听到上面加粗的那句话时，反应非常强烈。如今在大多数公司，确实存在一场“代码审查的戏码”。事实是，没有哪个工程师能跟得上多出 5 到 10 倍的待审查代码，所以大多数人并不会彻底审查代码。
仅由智能体进行的代码审查呈上升趋势
来自 Linear 的最新数据显示，仅由 AI 智能体审查的 PR 呈上升趋势，我预计这一趋势将持续：
质量和可靠性下降
我们在使用的许多数字产品中都看到了这一点。正如 Pi 的创造者 Mario Zechner 在播客中所说：
“一切都在出故障。感觉软件已经变成了一团脆弱的乱麻，98% 的正常运行时间成了常态而非例外，大型服务也不例外。用户界面出现了各种奇怪的 bug，你会以为 QA 团队本该能发现它们。我承认，这种情况在智能体出现之前就存在了。但我们似乎在加速。”
我们在三月的《AI 智能体实际上在拖慢我们吗？》一文中探讨了 AI 使用越多、质量越差的现象。
基础设施产能短缺
众所周知，市场上存在 GPU 短缺和内存短缺。此外，CPU 短缺的趋势也在加剧。正如我上个月所报道的：
“显然，现在如果没有与云提供商建立长期连接，几乎不可能在竞价实例上获得 CPU。而且，现在预留特定 CPU 需要提前几个月进行，云提供商甚至会拒绝某些预留请求，因为他们没有足够的 CPU 或所需类型的 CPU。”
如果你所在的公司 CPU 使用量相当可观，那么现在确保容量是值得做的事情，正如我最近所写：
“确保更多 CPU 容量的最佳时机无疑是现在。我听到传言说，某些云区域不再接受新租户，因为所有 CPU 容量都已租赁出去，或者在其他地方谈判困难。我还听说，客户现在就已经在付费预留容量，而这些容量要到 12 月才会在数据中心上线。这看起来像是提供商的掠夺性行为，但需求如此之高，这很可能就是他们优先分配新增容量的方式——同时赚取比平时高得多的利润。
如果你的公司有动态工作负载，并且过去使用过竞价实例，那么现在可能是分配固定容量的好时机——即使这样更贵。如果你预期会有显著增长，现在这样做可能意味着在某些云提供商或某些区域还有选择余地。”
对个人专注度和生产力的打击
软件工程师 Dima Zaytsev（目前在 Linear，之前是我在 Uber 的同事）跟我谈了一些关于 AI 和生产力的事情，让人很有共鸣：
“有大量的上下文切换：总会有另一个智能体在等待你的响应。
而且，这只是更多的工作。当 AI 刚兴起时，我觉得自己比同行更有生产力：我用一小时完成了别人需要一天才能完成的事情。现在，预期已经变成每个人都要并行处理多项事务。所以，与 AI 之前相比，我最终感觉自己有更多工作要做。”
工程领导者选择职业间歇
一个有趣且出乎意料的趋势已经出现：CTO、工程负责人和工程副总裁纷纷辞职，往往没有安排好具体去向。一位要求匿名的现任 CTO 表示：
“这种[伴随 AI 的]变化让构建者想要去构建。我们想再次构建，这样我们就能构建更多，并用更好的工具更快地构建，从而通过用更少优秀的人做更多事情来提高团队的‘人才密度’，等等。
这是一个构建事物的绝佳时代。而且只会变得更好。人们只是想靠近它。他们想构建，并看看用这些新工具能走多远。
我的社交圈里有一堆你所说的‘CTO 退学者’朋友。还有更多人正在大公司里从管理岗位转向 IC 岗位。他们的故事大体上就是我上面描述的。他们只是把这看作一个真正激动人心的构建时代。
归根结底，构建正是他们最初进入这个领域的原因。”
我们在深度报道‘走向出口：工程领导者的职业间歇潮’中涵盖了这一点。
4. 什么仍然没变？
在 LDX3 主题演讲中，我也谈到了 AI 之前基本没有变化的领域：
团队仍然重要。正如 Claude Platform 工程负责人 Katelyn Lesse 在 7 月告诉我的那样：
“我从一些人那里听到的一种说法是‘我们有两个人类和一堆智能体’。我的回答是，我们还没到那一步。我仍然有团队，他们的职责是负责某一块软件、对它迭代、负责 oncall 等等。虽然这些人类每个人都被 AI 大幅增强，但团队的规模和形态仍然类似。我们仍然有‘两个披萨团队’。”
Katelyn 在全球最“AI 化”的公司之一工作，所以如果在那里团队仍然和 AI 出现之前一样重要，那么可以说团队结构在整个行业的公司中仍然适用。
规划仍然存在——至少对于复杂工作是如此。复杂项目仍然有漫长的规划阶段。同样来自 Katelyn，关于 Claude Managed Agents 的规划阶段：
“我们的规划流程看起来更像是典型的 AI 之前的规划流程。你知道每个团队都有那样的项目：每个人都提出同一个想法的某个版本，人们不断提出、围绕它打转，直到最后终于去做？Managed Agents 对我们团队来说就是这样。当我们启动这个项目时，我们有可追溯到两年前的文件，里面都是想法和建议。”
测试与验证仍然非常重要。来自 Bun 的创造者、现就职于 Anthropic 的 Jarred Sumner：
“AI 写了几乎所有的代码，但我们也让 AI 写了几乎所有的测试。在 AI 之前，对于生产级软件，我们花在写测试上的时间和写代码差不多。有了 AI 之后仍然如此。你需要有一种方式来信任你的代码，而测试大概是最好的方式。”
在 LDX3 主题演讲之前，我与每家公司交谈时都观察到，大量精力正投入到验证 AI 智能体输出上。这很合理：代码审查不再像以前那样运作，我们的代码更多了，而我们需要确保它不会搞坏生产环境！
非工程师仍然不会发布生产代码。在过去几周里，社交媒体上有些说法，称 AI 让产品经理/设计师/非技术人员能够发布生产代码。所以，我问了各家 AI 实验室、创业公司和其他公司。
我可以报告的是，我没有发现任何一家公司让 PM/设计师/非技术人员发布到生产环境！
我确实了解到的是，这些人用他们的智能体创建 bug 修复——往往是在不知情的情况下！——或新功能，最终交给开发人员审查。还有大量的原型开发。但决定什么可以、什么不可以发布到生产环境，仍然由工程师负责。
我们正在重新发现那些与 AI 配合极佳的老模式。这一点在我们与 Matt Pocock 的播客中提到了。Matt 注意到智能体会尝试逐层构建软件，这会在层与层之间造成 bug。在阅读《程序员修炼之道》时，他发现了“曳光弹”的概念。当他指示智能体使用“曳光弹”来构建应用（也就是实现一条“黄金路径”）时，智能体开始产出更好的代码。
正如播客中提到的，Matt 现在正在阅读经典的软件工程书籍，寻找其他能有效引导智能体的“引导词”。
总的来说，我注意到，在使用 AI 工作时，那些「老」的最佳实践对于构建更好的软件很有帮助。这包括编写单元测试、先构建一条「黄金路径」（也就是「曳光弹」）、提前对应用进行架构设计，甚至使用设计模式。有趣的是，我们在这里谈论的可是几十年前的最佳实践。
5. 接下来会发生什么？
通过识别正在发生的、并且看起来必然会持续下去的趋势，我们有可能前瞻科技行业的走向：
云端编码代理 + harness 将占据主导。 公司里的大多数开发者将在云端运行 AI 代理，而不是在本地。Ramp 在我们对其名为 Inspect 的云端代理的深度剖析中提供了一个蓝图。在创新型科技公司内部，「构建你自己的云端代理 harness」这一原则似乎正在成为趋势。
我还预计，Anthropic、OpenAI、SpaceX 等供应商将开始大力推广他们的云端编码代理产品，并且会有更多初创公司构建自己的云端 harness。
作为工程师，我们将不再阅读代码。 现在判断这何时会发生还为时过早；可能是今年、明年，或者更远的未来，但未来我们中很少有人会真正地阅读 AI 代理产出的代码。
通常，我会非常关注 Honeycomb 联合创始人兼 CTO Charity Majors，因为她是新技术的「默认怀疑论者」，同时也是一位杰出的工程师，并且敢于直言。在八月的播客中，她问道：
「要让你在不阅读、不理解代码的情况下就安心发布代码，需要什么条件？因为那才是工程。」
Charity 指出，运维和 QA 已经有几十年时间来弄清楚如何将他们没有编写、也不理解的代码发布到生产环境——同时还要确保它能正常工作！大多数软件工程师似乎也不可避免地会加入这一行列。这颇具讽刺意味，因为很长一段时间以来，软件工程一直都是关于工程师编写并理解代码的！
公司将构建全新类型的内部基础设施。 我们将看到这些系统为了与代理良好协作而经历一场「重塑」：
CI/CD，将代理评估作为流水线的一部分
代理式软件工厂，并弄清楚哪些做法可行、哪些不可行
代理成为部署、可观测性、事件管理的一部分
代理式可观测性必将成为一个独立的问题领域和专业方向：我们如何确保部署的面向客户的代理按预期工作，以及如何确保代理构建和修改的系统确实按预期工作？
重构/迁移/全面重写的「黄金时代」。 那些因为完成所需时间差不多少而被拖延多年的迁移和重写，现在应该不会超过几周。这意味着再也没有什么借口继续拖延了！
工程师们如今更了解 AI 代理在重写/重构/迁移方面的能力，我们也将更快地清理技术债务，同时再也没有理由让系统处于令我们不满意状态！
AI「流畅度」和「积极性」在初创公司招聘中很重要。 一个我写得不多——但已经在发生——的趋势是：初创公司在招聘工程师时，会选择那些对 AI 表现出积极态度的人。正如一家 D 轮初创公司的工程总监告诉我的：
“AI 积极性是我们在招聘过程中开始筛选的一项特质。我们希望加入的人愿意帮助我们在 AI 能构建的边界上不断推进。”
现实是，AI 编码代理已经无处不在，而代理式系统看起来很快就会大量涌现。这将带来对愿意且有能力构建下一代系统的软件工程师的巨大需求，而对这个领域充满热情将成为一项基本标准。
这与初创公司招聘认同快速成长理念的工程师，或公司偏好那些愿意学习现有技术栈、而不是坚持使用自己惯用技术的工程师，并没有太大不同。
拥有深厚领域知识的工程师将更加抢手。在纽约，我与《Google 软件工程》的主要作者 Titus Winters 有过一次交谈。他告诉我这样一个观察：
“在任何地方取得成功，你都需要三样东西：智力、智慧和魅力。智力意味着：如何去做。智慧意味着：该做什么。魅力意味着：说服别人去做。
当智力变得普遍时，智慧和魅力就变得更加重要。”
在软件工程的语境下，“智慧”最容易通过成为领域专家来获得。所以，如果你在一家金融科技公司工作，就去了解金融行业及其客户，从而成为一名更有价值、更抢手的工程师！如果你在一家农业科技公司，或在任何其他领域工作，也同样适用。
最后：提醒自己当初为什么进入科技行业。在我与 Cockroach Labs 联合创始人兼 CTO Peter Mattis 的播客结尾，我们谈到了如今跟上变化步伐有多么令人疲惫。他说：
“提醒自己当初为什么进入这个行业。我进入软件工程，是因为我喜欢构建东西。现在我可以构建得更快，而且没有以前那些妥协了！”
来源：Pragmatic Engineer · newsletter.pragmaticengineer.com