2026 年科技行业现状：手写代码消失、并行智能体与 IDE 的退场
The state of the tech industry in 2026
Gergely Orosz 在 LDX3 工程领导力大会的主题演讲中，基于走访 OpenAI、Anthropic 及 GitHub、Factory AI、Linear 提供的数据，梳理了 2026 年科技行业的 16 项变化、若干失效假设与 5 项未变之处。
我最近在纽约的LDX3 工程领导力大会上做了主题演讲，与会者有 2000 多位工程领导者、CTO、总监级及以上的工程人员，我试图借此勾勒出科技行业此时此刻所处的位置。
此前，我有机会拜访了 OpenAI 和 Anthropic 这两家 AI 实验室，结识了 Ramp、Uber 等创新初创公司，并从 GitHub、Factory AI 和 Linear 获得了新的、未公开的数据。演讲的重点是 AI 实验室、风投支持的初创公司以及大型科技公司内部的趋势。感谢这些团队给予的宝贵访问机会！
大会之前，我花了数周时间梳理并记录一年前尚不存在的趋势——或者当时还远未成形的趋势——以及当前已经失灵的问题，还有一些始终未变的东西。今天，我们涵盖：
变化的速度。在科技行业，变化从未如此大规模、如此迅速。行业传奇人物 Martin Fowler 也证实了这一点。
已经改变的事：几乎没有人再手写代码，同时使用 5-10 个 agent 更为常见，IDE 的式微，以及过去一年中的另外 13 项变化。
已经失灵的事：关于代码产出的假设崩塌了，代码审查变成了走过场，质量和可靠性下降，等等。
依然不变的事：团队仍然重要，规划同样重要；非工程人员仍然不交付代码，等等。
接下来会发生什么？云端编码 agent 与 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 与多个并行智能体协作越来越普遍
我喜欢与 AI 实验室的工程师交谈，因为他们的工作实践往往比行业其他部分领先几个月。Claude Code 的创造者 Boris Cherny 在播客中透露了他完成工作的新方式：
“我有 5 个终端标签页。每个标签页都有一个他们仓库的检出副本。我会轮流在每个标签页中启动 Claude Code。我还会在 Claude Web 上运行 5-10 个 Claude，与本地 Claude 并行工作。”
在这些言论发表几个月后，在上周的播客中，Cockroach Labs 联合创始人 Peter Mattis——他是一位极其高产的开发者，在 AI 出现之前每年编写约 10 万行代码——表示他也在做类似的事情：
“很多时候，我在并行处理事情。我发现我的认知负荷大约是同时进行 5-10 个智能体会话。但有时这些会话会有许多子智能体在做事情。”
我还问了一位在 Uber 的前同事，他也是一位极其高产的软件工程师，问他现在如何工作。Dima Zaytsev（现为 Linear 的软件工程师）告诉我：
“过去是一个简单的世界：一个鼠标、一个键盘、一个屏幕。你物理上无法同时处理多件事情。现在，你不再有这种限制。
我最终会在本地拥有 5-10 个（字面意义上的）工作树，并在它们之间轮换。给一个智能体提示，当它在工作时，转到另一个去测试输出或审查代码。”
我遇到过的几乎所有最高产的软件工程师——一年前还在手写代码——如今都不再手写代码，并且同时运行多个并行智能体。多么大的变化！
#3 智能体生成的 PR 迅速增长
GitHub 与我分享的最新数据：
我曾因 GitHub 持续存在的可靠性问题而对其颇有微词，但看到由智能体生成的 PR 增长得如此之快，我对该平台所承受的负载多了许多同理心。
值得深思：2026 年 8 月，GitHub 上由智能体撰写的 PR 数量超过了人类撰写的数量！可以合理推测，未来该平台上由智能体生成的 PR 数量将永久性地超过人类生成的 PR 数量。
为了让大家对 AI 生成的 PR 数量有个概念：截至今天（2025 年 10 月），每月完全由 AI 生成的 PR 数量很可能是 2023 年底人类生成 PR 数量（2023 年 12 月为 2500 万）的 3 倍（可能超过 7500 万）。而且 AI 生成 PR 的速度似乎并未放缓，至少目前没有。
#4 智能体生成的问题也在迅速增加
智能体不仅在生成 PR，它们还在开票。更多独家数据，这次来自我在 Linear 的朋友，他们为智能体创建问题添加了一流的 MCP 支持：
#5 智能体技能的使用已成主流
工程师和非工程师都在使用智能体技能，许多公司正在构建自己的智能体技能仓库，供全体员工创建、分享和评估。关于技能使用量大幅上升的一个有趣数据点来自自主软件工厂供应商 Factory AI，他们与我分享：
#6 日渐式微的 IDE
我非常尊重软件工程师 Steve Yegge，他擅长识别新兴趋势并加以了解。在一期播客节目中，他说 IDE 实际上已经终结：
Gergely：“谈到开发者这份工作，你说过一些可能会让很多人感到被冒犯的话。你在 AI Engineer Summit 上说过，如果你现在还在用 IDE，那你就是个糟糕的工程师。”
Steve：“是啊，好吧，你得有点挑衅性。让我这么说吧。好吧，我不会说你是个糟糕的工程师，因为我认识一些非常非常优秀的工程师，比我强，他们在我（AI 使用）图表上还处于第一或第二级？但我为他们感到深深的遗憾。
我对他们感到怜悯，这是我一生中从未有过的。为这些优秀的、或者曾经优秀的成年人。他们会说，‘是啊，你知道，我用 Cursor，有时会问它问题。我对它的回答印象深刻。然后我会非常仔细地审查它的代码。’
然后我把它提交上去，我就想：‘老兄，你会被解雇的。而你是我认识的最优秀的工程师之一！！’ ”
Steve 这样描述他的 AI 使用层级：
不使用 AI
IDE 中的 AI 智能体，权限严格
IDE 中的 AI 智能体，处于“YOLO”模式（关闭权限）
IDE 中的 AI 智能体，不再看代码，而是与智能体交互
CLI 优先：放弃了 IDE
并行运行多个智能体
运行 10 个以上智能体
构建自定义智能体编排器以运行 30 个以上（或 100 个以上）智能体
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/智能体平台
8 月，我在社交媒体上提出了一个问题：不构建 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 如何构建一个代理式软件工厂，而关于那篇文章，许多读者的反馈都是“我们也是！”这类回应。很多读者说，他们公司也在构建类似的“代理式软件工厂”。
“代理式软件工厂”为一系列现有系统添加了 AI 功能，例如 CI/CD 系统；比如，能够通过 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：将横跨 1500 万行代码（！！）的 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% 的正常运行时间成了常态而非例外，大型服务也是如此。而且用户界面出现了你会以为 QA 团队能抓到的奇怪 bug。我承认这种情况在智能体出现之前就存在了。但我们似乎在加速。”
我们在三月的‘AI 智能体实际上在拖慢我们吗？’一文中探讨了 AI 使用越多质量越差的现象。
基础设施容量短缺
众所周知，市场上存在 GPU 短缺和内存短缺。此外，CPU 短缺的趋势也在增长。正如我上个月所报道的：
“显然，现在如果没有与云提供商建立长期连接，几乎不可能在竞价实例上获得 CPU。此外，现在预留特定 CPU 需要提前数月进行，云提供商甚至会拒绝某些预留，因为他们没有足够的 CPU 或合适类型的 CPU。”
如果你所在的公司 CPU 使用量相当可观，那么现在确保容量是值得做的事情，正如我最近所写：
“确保更多 CPU 容量的最佳时机无疑是现在。我听到传言说，某些云区域不再接受新租户，因为所有 CPU 容量都已租出，或者在其他地方谈判很困难。我还听说，客户现在已经在付费预留容量，而这些容量要到 12 月才会在数据中心上线。这看起来是提供商的掠夺性行为，但需求如此之高，这很可能是他们优先分配新容量的方式——同时赚取比平时高得多的利润。
如果你的公司有动态工作负载，并且过去使用过竞价实例，那么现在可能是分配固定容量的好时机——即使它更贵。如果你预期会有显著增长，那么现在这样做可能意味着在某些云提供商或某些地区还有选择。”
对个人专注力和生产力的打击
软件工程师 Dima Zaytsev（目前在 Linear，之前是我在 Uber 的同事）告诉我一些关于 AI 和生产力的事情，感觉非常能引起共鸣：
“有很多上下文切换：总有一个代理在等待你的回应。
而且，这只是更多的工作。当 AI 刚开始兴起时，我感觉比同龄人更有生产力：我用一小时完成了别人需要一天才能完成的事情。现在，期望已经变成每个人都同时处理并行的事情。所以，与 AI 出现之前相比，我最终感觉自己有更多的工作。”
工程领导者休假
一个有趣且出乎意料的趋势是，CTO、工程主管和工程副总裁纷纷辞职，通常没有具体的下一步安排。一位要求匿名的现任 CTO 表示：
“这种[与 AI 相关的]变化让构建者想要构建。我们想再次构建，这样我们就能构建更多，用更好的工具更快地构建，从而通过用更少优秀的人做更多事情来提高团队的‘人才密度’，等等。
现在是构建事物的绝佳时机。而且只会变得更好。人们只是想接近它。他们想构建，看看用这些新工具能走多远。
我的社交圈里有很多你所说的‘CTO 退学者’朋友。还有更多人正在从大公司的管理岗位转向个人贡献者角色。他们的故事大体上就是我上面描述的。他们只是认为这是一个真正令人兴奋的构建时机。
归根结底，构建正是他们最初进入这个领域的原因。”
我们在深度文章‘走向出口：工程领导者的伟大职业休假’中涵盖了这一点。
4. 什么仍然不变？
在 LDX3 主题演讲中，我还涵盖了与 AI 之前相比基本未变的领域：
团队仍然重要。正如 Claude 平台工程主管 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. 接下来会发生什么？
通过识别正在发生、且看起来必定会持续下去的趋势，我们有可能前瞻科技行业的走向：
云端编码智能体 + 运行框架将占据主导。公司里的大多数开发者将在云端而非本地运行 AI 智能体。Ramp 在我们对其名为 Inspect 的云端智能体的深度剖析中提供了这方面的蓝图。在创新型科技公司内部，“构建你自己的云端智能体运行框架”这一原则似乎正在成为趋势。
我还预计 Anthropic、OpenAI、SpaceX 等厂商将开始大力推广其云端编码智能体产品，并且会有更多初创公司构建自己的云端运行框架。
作为工程师，我们将不再阅读代码。现在判断这何时会发生还为时过早；可能是今年、明年，或更远的将来，但往后我们中很少有人会真正去阅读 AI 智能体产出的代码。
一般来说，我非常关注 Honeycomb 联合创始人兼 CTO Charity Majors，因为她对新技术持“默认怀疑”态度，同时也是一位杰出的工程师，并且敢于直言。在我们八月的播客中，她问道：
“要怎样才能让你在发布代码时不去阅读和理解它也能感到安心？因为那才是工程。”
Charity 指出，运维和 QA 已经有几十年的时间来弄清楚如何将他们没有编写、也不理解的代码发布到生产环境——同时还要确保它能正常工作！看起来，大多数软件工程师也将不可避免地加入这一行列。这很讽刺，因为长期以来，软件工程一直关乎工程师编写并理解代码！
公司将构建全新类型的内部基础设施。我们将看到这些系统被“重新发明”，以便与智能体良好协作：
CI/CD，将智能体评估作为流水线的一部分
智能体软件工厂，并弄清楚什么可行、什么不可行
智能体成为部署、可观测性、事件管理的一部分
智能体可观测性必将成为其自身的问题领域和专业方向：我们如何确保部署的面向客户的智能体按预期工作，以及如何确保智能体构建和修改的系统确实按预期工作？
重构/迁移/彻底重写的“黄金时代”。那些因完成所需时间相近而被拖延多年的迁移和重写，现在应该只需几周时间。这意味着再没有借口继续拖延了！
工程师们如今更了解 AI 智能体在重写/重构/迁移方面的能力，我们也将更快地清理技术债务，同时再也没有理由让系统处于令我们不快的状态！
AI“流畅度”和“积极性”在初创公司招聘中很重要。有一个我写得不多——但已经在发生的趋势——是初创公司在招聘工程师时，会选择那些对 AI 表现出积极态度的候选人。正如一家 D 轮初创公司的工程总监告诉我的：
“AI 积极性是我们在招聘过程中开始筛选的一项特质。我们希望加入的人愿意帮助我们在 AI 能构建的领域突破极限。”
现实是，AI 编码代理已经无处不在，而代理系统看起来很快就会大量涌现。这将带来对愿意且有能力构建下一代系统的软件工程师的巨大需求，而对这一领域充满热情将成为一项基本标准。
这与初创公司招聘那些认同快速成长理念的工程师，或公司青睐那些能上手现有技术栈而非坚持使用自己惯用技术的工程师，并无太大不同。
拥有深厚领域知识的工程师将更受欢迎。在纽约，我与《Google 软件工程》的主要作者 Titus Winters 有过一次交谈。他告诉我这样一个观察：
“在任何地方取得成功，你都需要智慧、明智和魅力。智慧意味着：如何去做。明智意味着：做什么。魅力意味着：说服别人去做。
当智慧变得普遍时，明智和魅力就变得更加重要。”
在软件工程的语境下，“明智”最容易通过成为领域专家来获得。所以，如果你在一家金融科技公司工作，就去了解金融行业及其客户，从而成为一名更有价值、更抢手的工程师！如果你在农业科技公司或其他任何领域工作，也同样适用。
最后：提醒自己当初为什么进入科技行业。在我与 Cockroach Labs 联合创始人兼 CTO Peter Mattis 的播客结尾，我们谈到了如今跟上变化步伐让人感到相当疲惫。他说：
“提醒自己当初为什么进入这一行。我进入软件工程是因为我喜欢构建东西。现在我可以构建得更快，而且没有以前的一些妥协！”
来源：The Pragmatic Engineer · newsletter.pragmaticengineer.com