跳到主内容
今年会网址

几乎没人手写代码了、IDE正在消失,2026年科技圈正在发生什么?

2026-10-10 · 今年会网址

人工智能正全面重塑科技产业格局,其中软件工程领域的变革尤为显著。

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 个终端标签页。每个标签页里都有一份代码仓库的检出副本。我会轮流切换,在每个标签页中启动 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 的数据就展示了这一点:

来源:GitHub 的负载增长正在加速

(人类)代码审查已经失效

一家中型初创公司的软件工程师告诉我一件事,这几乎已经成为整个行业公开的秘密,包括那些仍然保留代码审查流程的公司。

“所有人都在演一场代码审查的戏,但考虑到每天丢到你面前的变更量,我发现大家最终都会选择阻力最小的方式:放弃真正的审查,然后给所有东西都盖上 LGTM 的章。

我们自己也正在逐步取消这个流程,允许大家采用一些快捷方式,而这已经极大地提高了生产力。”

在 LDX3 大会上,当现场观众听到上面加粗的那句话时,反应非常强烈。

如今,在大多数公司里,确实存在一种“代码审查表演”。事实是,**没有任何工程师能够跟上 5 到 10 倍于过去的代码审查

更多文章