Gergely Orosz 在 LDX3 演讲总结 2026 年科技行业状态
The state of the tech industry in 2026
Gergely Orosz 在 LDX3 大会发表 29 分钟主题演讲，结合走访 OpenAI、Anthropic 及 GitHub、Factory AI、Linear 的独家数据，绘制 2026 年科技行业快照。
作者基于走访 OpenAI、Anthropic 等公司和 GitHub 独家数据，梳理去年出现的十余项工程实践变化、失效假设与不变原则，可作行业快照参考。
我最近在纽约的LDX3 工程领导力大会上做了主题演讲，与会者有 2,000 多位工程领导者、CTO、总监级及资深级工程人员，我在演讲中试图勾勒出科技行业此时此刻所处位置的快照。
在此之前，我有机会拜访了 AI 实验室 OpenAI 和 Anthropic，会见了 Ramp、Uber 等创新初创公司，并从 GitHub、Factory AI 和 Linear 获得了新的、未公开的数据。演讲的重点是 AI 实验室、风投支持的初创公司以及大型科技公司内部的趋势。感谢这些团队的慷慨开放！
在大会之前，我花了几周时间梳理并记录一年前还不存在——或者当时还处于萌芽阶段——的趋势，以及目前已经失灵的问题，还有一些保持不变的东西。今天，我们涵盖：
变化的速度。在科技行业，变化从未如此大规模、如此迅速。行业传奇人物 Martin Fowler 也证实了这一点。
已经改变的部分：几乎没有人再手写代码，同时与 5-10 个智能体协作更为常见，IDE 日渐式微，以及过去一年里的另外 13 项变化。
已经失灵的部分：关于代码产出的假设失效了，代码评审变成了走过场，质量和可靠性下降，等等。
依然不变的部分：团队依然重要，规划依然重要；非工程师依然没有在交付代码，等等。
接下来会怎样？云端编码智能体和执行框架、工程师不再阅读代码、公司构建新型 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 数量有个概念：截至今天（2026 年 10 月），每月完全由 AI 生成的 PR 数量很可能是 2023 年底人类生成 PR 数量（2023 年 12 月为 2500 万）的 3 倍（很可能超过 7500 万）。而且 AI 生成 PR 的速度似乎并未放缓，至少目前没有。
#4 智能体生成的 issue 也在快速上升
智能体不仅在生成 PR，它们还在开 issue。这里有一些更独家的数据，来自我在 Linear 的朋友，他们为智能体创建 issue 添加了一流的 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 是基于 VS Code 分支发布的最后一个 IDE。它于 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：将横跨 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. Agentic 基础设施正成为一门独立学科。大多数中型及以上公司都在构建 agentic 平台，基础设施团队正日益转变为 agentic 基础设施团队。
3. 哪里出了问题？
关于代码数量和频率的假设
人们普遍认为代码数量大致呈线性增长。但有了 agent 之后，代码行数和提交次数都在呈指数级增长，正如 GitHub 的数据所示：
（人工）代码审查已死
一家中型初创公司的一位软件工程师告诉了我一件在整个行业几乎是公开秘密的事，包括那些设有代码审查流程的地方也是如此。
“每个人都在上演做审查的戏码，但面对涌向你的变更量，我观察到人们只是找一条阻力最小的路：放弃审查，直接给所有东西盖上 LGTM 的章。
我们自己正通过允许采取的一些捷径逐步淘汰这一流程，而这带来了显著的生产力提升。”
在 LDX3 大会上，当观众听到上面加粗的那句话时，反应强烈。如今在大多数公司，确实存在“代码审查的戏码”。事实是，没有哪个工程师能跟得上多出 5 到 10 倍的待审查代码，所以大多数人并不会彻底审查代码。
仅由 agent 进行的代码审查呈上升趋势
Linear 的最新数据显示，仅由 AI agent 审查的 PR 呈上升趋势，我预计这将继续下去：
质量和可靠性下降
我们在使用的许多数字产品中都看到了这一点。正如 Pi 的创造者 Mario Zechner 在播客中所说：
“一切都坏了。感觉软件确实变成了一团脆弱的乱麻，98% 的正常运行时间成了常态而非例外，包括大型服务也是如此。而且用户界面有着最奇怪的 bug，你会以为 QA 团队本应能发现它们。我承认这种情况在 agent 出现之前就已存在更久了。但我们似乎正在加速。”
我们在 3 月的《AI agent 真的在拖慢我们吗？》一文中探讨了 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 的强力加持，但团队的规模和形态仍然差不多。我们仍然采用 two-pizza team（两个披萨团队）模式。”
Katelyn 在全球最“AI 化”的公司之一工作，所以如果在那里团队仍然和 AI 出现之前一样重要，那么可以说，团队结构在整个行业的公司中仍然具有相关性。
规划仍然存在——至少对于复杂工作是如此。复杂项目仍然有漫长的规划阶段。同样来自 Katelyn，关于 Claude Managed Agents 的规划阶段：
“我们的规划过程看起来更像典型的 AI 之前的规划过程。你知道每个团队都有项目，每个人都会提出同一个想法的某个版本，大家不断提出、反复讨论，直到最终真正去做？Managed Agents 对我们团队来说就是这样。当我们启动这个项目时，我们有一些可以追溯到两年前的文档，里面都是想法和建议。”
测试和验证仍然非常重要。来自 Bun 的创造者、目前就职于 Anthropic 的 Jarred Sumner：
“AI 几乎写了所有的代码，但我们也让 AI 几乎写了所有的测试。在 AI 之前，对于生产级软件，我们花在写测试上的时间和写代码差不多。在 AI 时代仍然如此。你需要有一种方式来信任你的代码，而测试可能是最好的方式。”
在 LDX3 主题演讲之前，我与每家公司交流时都注意到，大量精力正投入到验证 AI 智能体的输出上。这很合理：代码审查不再像以前那样运作，我们的代码更多了，我们需要确保它不会搞坏生产环境！
非工程师仍然不会发布生产代码。过去几周，社交媒体上有一些关于 AI 让产品经理/设计师/非技术人员能够发布生产代码的说法。于是，我询问了 AI 实验室、初创公司和其他公司。
我可以报告的是，我没有发现任何一家公司存在产品经理/设计师/非技术人员向生产环境发布代码的情况！
我了解到的是，这些人用他们的智能体创建 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 编码代理已经无处不在，而代理式系统看起来很快就会大量涌现。这将带来对愿意且有能力构建下一代系统的软件工程师的巨大需求，而对这一问题领域充满热情将成为一项基本标准。
这与初创公司招聘认同快速成长理念的工程师，或公司青睐愿意采用现有技术栈、而非坚持使用自己惯用技术栈的工程师，并无太大不同。
拥有深厚领域知识的工程师将更受欢迎。在纽约，我与《Software Engineering at Google》的第一作者 Titus Winters 有过一次交谈。他向我表达了这样的观察：
“在任何地方取得成功，你都需要三样东西：智力、智慧和魅力。智力意味着：如何去做。智慧意味着：做什么。魅力意味着：说服别人去做。
当智力变得普遍，智慧和魅力就变得重要得多。”
在软件工程的语境下，“智慧”最容易通过成为领域专家来获得。所以，如果你在一家金融科技公司工作，就去了解金融行业及其客户，从而成为一名更有价值、更抢手的工程师！如果你在一家农业科技公司工作，或在任何其他领域工作，这同样适用。
最后：提醒自己当初为什么进入科技行业。在我与 Cockroach Labs 联合创始人兼 CTO Peter Mattis 的播客结尾，我们谈到了如今要跟上变化的速度让人感到相当疲惫。他说：
“提醒自己当初为什么进入这一行。我进入软件工程是因为我喜欢构建东西。现在我可以构建得更快，而且不用再受以前那些妥协的束缚！”
来源：Pragmatic Engineer · newsletter.pragmaticengineer.com