2026年科技行业现状

务实工程师，The Pragmatic Engineer，Gergely Orosz 的工程通讯，从内部观察大厂与创业公司，面向软件工程师与技术管理者。关注

我最近在LDX3工程领导力会议在纽约，参加了2000+工程领导者、CTO、Director+和Staff+工程人员，我试图描绘科技行业目前的现状。

那是在我有机会参观了OpenAI和Anthropic的AI实验室，见到了像Ramp、Uber等创新初创企业，还从GitHub、Factory AI和Linear获取了新的未发布数据之后。

感谢这些团队的友好访问！

会议前，我花了数周时间识别并记录一年前不存在的趋势——或者当时还处于萌芽阶段——以及目前存在缺陷和未改变的趋势。今天，我们将涵盖：

变化的速度。在科技行业，变革从未如此大规模、如此迅速。行业传奇人物马丁·福勒证实了这一点。
变化：几乎没人再用手写代码了，只能用5到10个常见代理，IDE逐渐衰落，去年又做了13个改动。
坏了什么：关于代码输出的假设被打破，代码审查变得戏剧化，质量和可靠性下降，等等。
还是一样的：团队依然重要，规划同样重要;非工程师仍然不负责发布代码，等等。
接下来会发生什么？云编码代理和工具、工程师停止阅读代码、构建新型AI基础设施的公司等已经开始，且应加速发展。

你可以观看完整演讲，时长29分钟：

观看完整讲座

本文底部可能会被某些电子邮件客户端截断。

1. 变化速度

科技行业的人早已习惯于变化;看到互联网从零到无处不在，移动通信和智能手机的爆发式流行，云计算从小众兴趣兴起，以及像Go和Rust这样的编程语言，以及React（网页版）和Jetpack Compose（Android版）等框架的发展。

尽管如此，目前AI所带来的影响规模和速度仍是前所未有的。这就是业界资深人士马丁·福勒的描述在《务实峰会》:

“没有什么能像人工智能那样震撼人心。这与我们以往遇到的任何问题都大不相同。在较小的范围内，我们积极参与了面向对象语言的发展。面向对象语言让很多人害怕，但我们并不害怕，因为我们是其中的一部分。互联网对我们所有人产生了巨大影响。当然，我们也在传播敏捷软件开发的挑战。敏捷对许多组织产生了巨大影响，因为你可以从他们多么坚决抵制它看出来。但对于其他所有变化，我们不断强调它们的重要性和价值，试图说服人们它们的重要性。这听起来可能令人惊讶，但即使是互联网，也有人认为这不重要！对于人工智能来说，它的重要性毋庸置疑。你不能戴上眼镜去否认这件事的重要性。”

我自己的看法也类似;毫无疑问，我们正处于一场大规模技术转型的起点，之后软件的构建将与几十年来的不同，尽管开发的某些部分将保持不变。

至少，工具和最佳实践会有所不同，变化速度也比以往任何时候都快。

2. 发生了什么变化？

#1 现在没人手写代码了

随着日历进入今年第四季度，我们看到自2025年底以来，模型在编码方面大幅提升，这一趋势已形成一个巨大趋势。与此相关的是，在今年的第一篇文章中，我们提出了这个问题：

如今，有许多迹象表明大多数工程师已经停止手写代码，这也反映了最近Ruby on Rails的创始人引发了“手写代码的死亡”争论。就我个人而言，我对AI带来的新机遇感到兴奋，亲身体验这场革命令人兴奋。

正如前面提到的，我确信2026年我的编码方式会发生巨大变化，并且会带来许多连锁反应。

想了解更多相关内容，请查看最新一期的。

#2 与多个并行代理合作越来越普遍

我喜欢和AI实验室的工程师交流，因为他们的工作方式往往比行业其他部门领先几个月。Claude Code的创始人Boris Cherny揭示了他完成任务的新方法

“我有5个终端标签页。每个版本都有自己的仓库借出。我会轮流运行，每个代码库都启动Claude代码。我还会在Claude Web上运行5到10个Claude，和本地的Claudes并行。”

几个月后，Cockroach Labs联合创始人Peter Mattis——一位极其高效的开发者，在AI出现前每年写了大约10万行代码——表示他正在做类似的事情：

“很多时候，我是在并行做事情。我发现我的认知开销大约是同时进行5到10次代理会话。但有时这些会面会有很多次级代理人在做事情。”

我还问了一位在优步工作的前同事，他也是一名极具生产力的软件工程师，他现在的工作方式。Dima Zaytsev（现为Linear软件工程师）告诉我：

“曾经的世界很简单：一只鼠标，一把键盘，一块屏幕。你实际上无法同时处理多件事。现在，你没有这个限制了。我本地总共有5到10个工作树，轮流使用。提示一个代理，在它正常工作时，切换到另一个代理测试输出或审查代码。”

我遇到的几乎所有最高效的软件工程师——一年前还手写代码——现在不再手写代码，而是运行多个并行代理。真是个大变化！

#3 代理生成PR的快速崛起

GitHub 与我分享的新数据：

我曾经在GitHub上找过麻烦，但看到代理生成的PR增长速度如此之快，让我对平台所承受的负担更加有同情心。

值得深思的是：2026年8月，GitHub上由代理作者创建的PR数量超过了人类作者的！合理推测，未来平台上由代理生成的PR数量将永久超过人工生成的。

为了展示AI生成的PR数量：截至今天（2025年10月），2023年底，完全AI生成的PR数量（大约7500万+）可能是人类生成PR的3倍（2023年12月为2500万）。

而且AI生成PR的速度似乎没有放缓，至少目前没有。

#4 特工引发的问题也迅速上升

经纪人不仅在创造公关，他们还在开设工单。更多独家数据，这次来自我的Linear朋友们，补充道一流MCP支持项目对于能动性产生的问题：

#5 特工技能使用已成主流

工程师和非工程师都使用代理技能，许多公司正在为所有员工建立自己的代理技能库，供创建、共享和评估。一个关于技能使用趋势大幅增长的有趣数据来自自主软件工厂供应商工厂 AI，并与我分享了：

#6 逐渐消逝的IDE

我非常尊敬软件工程师Steve Yegge，他擅长识别新兴趋势并学习它们。在一篇中，他说IDE实际上已经结束了：

Gergely：“谈到开发者的工作，你说过一句话可能会触发很多人的情绪。你在AI工程师峰会上说过，如果你现在还在用IDE，那你就是个糟糕的工程师。”Steve：“是的，不过你得稍微挑逗一点。我这么说吧。好吧，我不会说你是个糟糕的工程师，因为我认识一些非常非常优秀的工程师，比我更厉害，他们在我的AI使用率排行榜上还处于一二级水平。但我对他们感到深深的同情。我对他们感到前所未有的同情。对这些成年人，他们是好工程师，或者曾经是。他们会说，'是的，你知道，我用光标，有时会问它问题。我对你的回答印象很深。然后我会仔细审查它的代码。'然后我签到它，我心想：'伙计，你要被解雇了。你是我认识的最棒的工程师之一！！'“

史蒂夫这样描述他的人工智能使用水平：

不使用 AI
集成开发环境（IDE）中的AI代理，权限严格
集成开发环境中的AI代理，带“YOLO”模式（权限关闭）
集成开发环境中的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概念。
法典该项目于2026年2月以非IDE形式推出，尽管他们在2025年底放弃了IDE概念，但他们很庆幸自己这么做了。
光标从IDE移开了。2026年4月，Cursor重新推出并且取消了IDE界面。现在它看起来和Codex和Claude桌面应用很相似。夏天我和他们团队聊过，他们告诉我他们维护“遗留”的VS Code分支版本给现有企业，但未来对他们来说是代理化的。
JetBrains似乎急于从IDE转型。JetBrains已经打造了一些开发者最喜爱的IDE，但公司现在也在转型为喷气脑空军以及代理开发环境。

业界传奇Kent Beck在我们讨论IDE为何逐渐消失时告诉我一件有趣的话：

“并不是我们不需要更多视角和背景来做基于人类的决策;而是背景已经改变了。”

我在想，实际上是不是IDE正在演变成一个更适合编码代理的平台。Steve Yegge也谈到了IDE需要进化变成了一个对话和监控界面，但不是编辑器，因为我们不再编写代码。

我还想补充一点，IDE需要发展成一个验证和核实的接口：我们如何确定代理的输出是否如预期运行，如何验证它通过了哪些测试，外观如何，以及你是否能尝试代理构建的任何东西。

这类工具肯定会到来，并且会被广泛采用。

#7 每个人都在构建自己的束缚/代理平台

今年八月，我在社交媒体上提出了一个问题，问是否可以在没有构建AI框架的情况下成为一家严肃的科技企业：

我之所以问，是因为大多数中型及以上公司现在都已经自己制造了代理束带！举几个例子：

斜坡建设——案例研究
Stripe（小黄人）、Uber（小黄人）、Block（鹅）、Shopify（河流）
谷歌（Agent Smith）、Meta（Devmate）、亚马逊（Kiro + Crew）、Dropbox（Nova）、Spotify（Honk）
DoorDash（Flux）、Grab（LLM套件）、WorkOS（Horizon）、Hubspot（Crucible）
Monzo（特工Chip）、Sierra（松果）、Harvey（幽灵党）、Browserbase（bb）
…还有更多更多！

#8 开发工作通常从Slack开始

我通过拜访初创公司了解到，越来越多的开发是在Slack内部启动的。在OpenAI，是“@Codex实现这个”;在Anthropic中，是“@Claude构建这个”，而在Linear内部，则是“@Linear做这个”。

越来越多的初创公司拥有自己的Slack代码代理集成——通常是定制的。

当Slack代理启动运行在云端的编码代理时，它们表现得非常好。

#9 Agentic软件工厂无处不在建设

我们已经深入探讨了如何实现，读者对那篇文章的反馈多半是“我们也是！”的回应。许多读者表示，他们的公司正在建设类似的“代理软件工厂”。

“代理软件工厂”为许多现有系统（如CI/CD系统）添加了人工智能功能;例如，可以通过Slack与CI/CD交互，或创建包含代理的新系统，如代理代码审查工具、OpenAI的代理部署系统或Perf Factory。

#10 迁徙不再需要几年

我们看到许多迁移，原本需要数年才能完成，现在只需几周或几个月：

人为：将包管理器 Bun 从 Zig 迁移到 Rust11天后（相比估计的1.5个工程年）
OpenAI：API 层正在从 Python 迁移到 Rust。迁移过程是，而没有 AI 的话，迁移可能需要几年时间
Airbnb：将3,500个端到端测试文件从酶迁移到React测试库：花了6周（而不是年份）
体式：将4,000个端到端测试文件从酶测试库迁移到React测试库：两周，而不是以五年为单位的估计分布
优步：迁移了60万次JUnit 4测试，跨越1500万行代码（！！）到JUnit 5：take4个月（而非估计的几年）

#11 人工智能成本一个重大工程问题

五月份，我们报道了，上个月我报道了科技公司的情况。Uber就是一个很好的例子，尽管代币使用呈上升趋势，但由于他们运行开放模型和智能模型路由，成本自五月以来保持稳定：

在我文章发表三周后，彭博社确认完全相同的趋势。正如我在最初深度分析中提到的，大多数公司节省成本的主要原因是低成本模型和智能路由账户。

如果你只做两件事，

#12 项目通常只用一两个工程师完成

Claude Platform 工程主管 Katelyn Lesse 向我介绍了她团队在 Anthropic 内部的工作方式。摘自我们的：

“在单个项目中，通常不能有超过两个人参与。这是因为每个工程师已经在运行多个代理。作为工程师，你已经在和代理们竞争，而代理人在实施上互相踩踏。而在这种体制下，你不能有那么多人类，而他们还带着所有代理！”

如今，无论大大小小的公司，我都看到类似的情况。

其他变化

13. 工程专业化正在消失.具体来说，iOS、Android和前端专业化的需求似乎减少，而“通用”软件工程师的需求更多。我们在中用数据报道了这一趋势，观察了这一趋势（而人工智能和FDE需求激增）
14. 团队规模正在缩小。项目由工程师完成的人数减少了。在初创公司内部，团队规模似乎在缩小。
15. 减少初级招募。我们会在深度分析中介绍它。
16. 能动基础设施正成为一个独立的学科。大多数中型及以上公司都在建设代理型平台，基础设施团队也越来越多地转变为代理型基础设施团队。

3. 哪里坏了？

关于码数量和频率的假设

人们普遍认为代码数量大致是线性增长的。但对于代理来说，代码行数和提交次数都在呈指数增长，GitHub 的数据显示了这一点：

（人类）代码审查已经死了

一位中型初创公司的软件工程师告诉我一件几乎是业界公开的秘密，甚至在有代码审查的地方也是如此。

“每个人都在演评审的舞台剧但面对大量变更，我观察到人们总是找到阻力最小的路径：放弃评测，直接在所有内容上盖上LGTM印章。我们正在逐步淘汰这一流程，采用一些你可以走的捷径，这极大地提升了生产力。”

在LDX3大会上，当听到上面加粗的句子时，观众反应强烈。如今，大多数公司确实存在“代码审查剧场”。事实是，没有工程师能跟上5到10倍的代码审查，因此大多数人不会彻底审查代码。

仅代理代码审查的趋势正在增加

来自Linear的最新数据显示，仅由AI代理审核的PR正在上升，我预计这一趋势将持续下去：

质量和可靠性下降

我们在许多数字产品中都能看到这一点。正如Pi的创作者Mario Zechner所说：

“一切都坏了。感觉软件已经变得一团脆弱，98%的正常运行率从例外变成常态，包括大型服务。用户界面出现了你以为QA团队会发现的最奇怪的bug。我承认这种情况比坐席存在的时间还早。但我们似乎在加速。”

我们在三月份报道了随着AI使用增加，质量变差的现象，在“中

基础设施容量短缺

众所周知，市场上存在GPU短缺。此外，还有日益增长的趋势。正如我上个月报道的：

“显然，现在几乎不可能在没有与云服务提供商长时间连接的情况下，将CPU分配到点点实例上。此外，指定CPU的预留现在需要提前几个月完成，云服务提供商甚至会因为CPU数量不足或型号不合适而拒绝某些预约。”

如果你所在的公司CPU使用率不小，正如我所写，确保容量安全是值得现在做的事情

“确保更多CPU容量的最佳时机无疑就是现在。我听说某些云区域不再接受新租户，因为所有CPU容量都已租赁，或者其他地方的谈判困难。我还听说客户今天已经开始付费预订只有12月数据中心才会上线的容量。这对供应商来说似乎是掠夺性行为，但需求如此之高，他们很可能以此优先分配新容量——同时赚取远高于平时的利润。如果你的公司有动态工作负载，且过去使用过点子实例，现在可能是分配固定容量的好时机——即使成本更高。如果你期待有实质增长，现在这么做可能意味着在某些云服务提供商或某些地区有选择权。”

对个人专注力和生产力的打击

软件工程师Dima Zaytsev（目前在Linear工作，曾是我在Uber的同事）告诉我一件关于人工智能和生产力的话，让我非常感同身受：

“有很多上下文切换：总有另一个客服在等你的回复。而且，这只是更多的工作。当人工智能开始发展时，我觉得自己比同龄人更有生产力：我一小时内完成了别人一天需要完成的事。现在，大家都被期望在做平行的事情。因此，我最终觉得自己比没有AI之前的工作量更多。”

工程领导者休整职业生涯

一个有趣且意想不到的趋势是，CTO、工程主管和工程副总裁纷纷辞职，往往没有具体的安排。一位现任CTO要求匿名的话说：

“这种（AI）的变化让开发者想要去建造。我们想再次建设，这样我们就能用更好的工具建造更多、更快的建设，从而通过更少优秀的人才做更多事情来提高团队的'人才密度'，等等on.It现在是打造事物的绝佳时代。而且情况只会越来越好。人们只是想靠近它。他们想建立，看看用这些新工具能走多远。我社交圈里有很多朋友就是你说的“CTO退出者”。更多人是从管理转到大型公司的IC岗位的。他们的故事大多和我上面描述的一样。他们只是把现在看作是一个真正令人兴奋的时代build.In结尾，建造正是他们进入这个领域的原因。”

我们在深入探讨中将对此进行了探讨。

4. 什么还没变？

在LDX3主题演讲中，我还涵盖了与AI之前基本保持不变的领域：

团队依然重要。正如Claude平台工程主管Katelyn Lesse于7月表示：

“我听一些人说，'我们有两个人和一堆客服人员。'”我回答说，这还不是我们现在的状态。我仍然有团队，他们的工作是拥有一件软件，进行迭代，接到待命，等等。虽然这些人类都被人工智能强化了，但团队的规模和结构仍然相似。我们仍然有两个披萨团队。”

Katelyn 在全球最“人工智能”驱动的公司之一工作，所以如果团队依然和 AI 出现前一样重要，那么可以说团队结构在整个行业依然适用。

规划依然存在——至少对于复杂的工作来说是这样。复杂项目仍有漫长的规划阶段。另外，关于Claude Managed Agents的规划阶段：

“我们的规划过程更像是典型的人工智能出现前的规划过程。你知道每个团队都有项目，大家都会提出同一个想法的某个版本，然后大家不断反复讨论，直到最终完成它？《管理特工》就是我们团队的例子。项目开始时，我们有长达两年的文件，里面有关于想法和建议的文件。”

测试和验证依然非常重要。来自Bun创作者、目前在Anthropic工作的Jarred Sumner：

“AI几乎写了所有代码，但我们也让AI写了几乎所有的测试。在AI出现之前，对于生产准备软件，我们写测试的时间和写代码的时间差不多。AI依然如此。你需要有一种信任代码的方式，而测试可能是最好的方式。”

在LDX3主题演讲前我与每家公司交谈时，我都发现大量关注点都放在验证AI代理的输出上。这很合理：代码审查不再像以前那样运作，我们有更多代码，必须确保不会破坏生产！

非工程师仍然不会发布生产代码。过去几周，社交媒体上有关于AI让产品经理、设计师或非技术人员能够发布生产代码的消息。于是，我问了AI实验室、初创公司和其他公司。

我可以报告我没有找到任何单曲公司里PM/设计师/非技术人员都被派往生产部门！

我了解到的是这些人会创建漏洞修复——往往是无意中！或者用他们的代理开发新功能，最终由开发者审核。还有大量的原型制作。但决定哪些内容可以发布到生产环境，还是工程师负责。

我们正在重新发现那些与AI合作效果良好的旧模式。这在我们与Matt Pocock的讨论中被提及。Matt注意到代理试图逐层构建软件，这会导致层间出现错误。

在阅读《实用程序员》时，他发现了“追踪子弹”的概念。当他指示代理使用“追踪子弹”来构建应用（即实现“黄金路径”）时，代理开始生成更好的代码。

正如播客中提到的，Matt现在正在阅读经典的软件工程书籍，寻找其他能高效指导代理的“引导词汇”。

总体来说，我注意到“旧”的最佳实践在构建更好的AI软件时很有帮助。这包括编写单元测试、先构建“黄金路径”（也就是“追踪子弹”）、提前设计应用，甚至使用设计模式。

有趣的是，我们谈论的是几十年前的最佳实践。

5. 接下来会发生什么？

通过识别正在发生且预计将持续发展的趋势，可以提前了解科技行业的发展方向：

云编码代理+线束将占主导地位。大多数公司的开发人员会在云端运行AI代理，而不是本地。Ramp为此提供了蓝图。似乎在创新科技公司内部，“自己构建云代理束”的原则正在流行。

我也预计像Anthropic、OpenAI、SpaceX等厂商会开始推广他们的云编码代理服务，更多初创企业也会开发自己的云机束。

作为工程师，我们会停止阅读代码。现在还为时过早;可能是今年、明年，还是更远的未来，但很可能很少有人会阅读AI代理生成的代码正确地，往前走。

通常，我非常关注Honeycomb的联合创始人兼CTO，Charity Majors，因为她对新技术持“默认怀疑态度”，同时也是一位杰出的工程师和直言不讳的人。

在我们的节目中，她提问道：

“你要怎样才能在不读代码、不理解的情况下就自在地发货？因为那是工程。”

Charity指出，运维和质量保证已经有几十年时间去研究如何将他们没写、不理解的代码上传到生产环境——同时确保它能正常运行！大多数软件工程师似乎也不可避免地加入了这个行列。

这很讽刺，因为软件工程长期以来就是工程师写作以及理解代码！

企业将建设全新的内部基础设施。我们将看到这些系统的“重塑”，以便更好地配合经纪人：

CI/CD，将代理评估纳入流程
代理软件工厂，以及如何弄清楚哪些是实用的，哪些不是
代理成为部署、可观察性、事件管理的一部分
代理可观察性必将成为独立的问题领域和专业化领域：我们如何确保面向客户的代理按预期工作，又如何确保代理构建和修改的系统真正按预期工作？

一个“黄金时代”，重构、迁移和全面重写。那些因为需要相似时间而拖延多年的迁移和重写，应该不会超过几周。这意味着几乎没有理由再拖延了！

工程师们现在更了解AI代理在重写、重构和迁移方面的能力，我们也会更快地清理技术债务，同时没有理由让系统处于我们不满意的状态！

人工智能的“流利度”和“积极性”在初创企业的招聘中非常重要。我很少写过的一个趋势——但已经在发生——是初创企业选择那些对人工智能持积极态度的工程师。

正如一家D轮初创公司的工程总监告诉我的：

“人工智能的积极态度是我们在招聘过程中开始筛选的。我们希望那些愿意帮助我们突破人工智能极限的人加入。”

现实是，人工智能编码代理已经无处不在，代理系统看起来很快将大量出现。这将带来对愿意且能够构建下一代系统的软件工程师的巨大需求，也将成为对问题领域充满热情的基础标准。

这与初创公司雇佣相信快速增长理念的工程师，或者公司偏好使用现有技术栈的工程师，而非坚持使用自己使用的技术栈的方式，并不太相似。

具备深厚领域知识的工程师将会越来越受欢迎。在纽约，我与谷歌《软件工程》一文主笔Titus Winters进行了交谈。他对我说了这样一个观察：

“你在任何地方取得成功所需的是智慧、智慧和魅力。智慧意味着：如何做到。智慧意味着：该做什么。魅力意味着：说服他人去做。当智慧变得普遍时，智慧和魅力就变得更加重要。”

在软件工程的语境下，“智慧”最容易通过成为领域专家获得。所以，如果你在金融科技公司工作，了解金融行业及其客户，才能成为更有价值、更受欢迎的工程师！

这同样适用于你在农业科技公司或其他领域工作。

最后：提醒自己为什么会进入科技行业。在，Cockroach Labs 的联合创始人兼首席技术官，我们谈到了现在跟上变化节奏感到相当疲惫。

他说：

“提醒自己当初为什么会进入这个行业。我选择软件工程是因为我喜欢做东西。现在我可以更快地做出来，而且没有以前那些妥协！”

添加评论

点踩

分享查看原文

参与讨论