AI编码工具三波浪潮正使IDE中心地位衰落。从IDE内AI功能到CLI代理再到桌面控制平面，AI代理接管了大量开发任务。IDE正转变为验证与调试工具，主要界面将是任务仪表盘。这重塑了软件开发的竞争格局。
译自：IDEcline: How the world’s most powerful coding tools became second-class citizens overnight
作者：Janakiram MSV
在我职业生涯的早期阶段，我每天都会在 Visual Studio IDE 中花费八小时。快进到今天，开发者们花在委派工作上的时间比在 IDE 中编写代码的时间更多。
这种转变预示着一个截然不同的未来——从编写和编辑代码转向编排代码代理。这不仅仅是现有工作流程上附加的自动补全功能，而是软件构建方式的根本性转变。IDE 仍然重要，但它不再是核心舞台。
旧有的开发范式
在过去的三十年里，IDE 一直是软件开发的核心。从编辑到导航、重构、调试和构建，集成开发工具是编码员和开发者的驾驶舱。Turbo C、Borland Delphi、PowerBuilder、Visual Studio、IntelliJ、Eclipse 以及最近的 VS Code 主导了 IDE 市场。它们一直是专业软件开发的引力中心。
IDEs 基于“人类编写代码，工具辅助”的方法论完美地发挥作用。从语法高亮到调试再到集成终端的每一个功能，都旨在让开发者在不离开编辑器的情况下保持高效。IDE 的作用是减少摩擦并优化意图与实现的循环。这也意味着开发者是瓶颈，并且是每一次按键的决策者。
AI 编程工具的三波浪潮
针对开发者工作流程的 AI 模型的到来并非一蹴而就。它经历了三波不同的浪潮，每一波都将重心进一步从 IDE 移开。
第一波浪潮将 AI 作为 IDE 内部的功能引入。自动补全、行内编辑和聊天侧边栏以扩展形式出现。GitHub Copilot 是一个突出的例子。IDE 仍然是宿主，AI 则是客人。开发者们留在原位。他们只是多了一个更快的结对程序员坐在他们旁边。
第二波浪潮将 AI 移入终端作为执行层。像 Gemini CLI 和 Claude Code 这样的 CLI 代理带来了不同的模型。这些工具不再是建议下一行代码，而是接受更高级别的指令。“修复此模块中失败的测试。”“重构此服务以使用新 API。”终端成为了代理工作的地方，而不仅仅是开发者输入命令的地方。IDE 仍然存在，但它不再是唯一能取得有意义进展的地方。这标志着代理开始接管 IDE 的传统工作。
第三波浪潮是我们目前正在目睹的。桌面控制平面围绕多代理、长时间运行、并行任务管理而设计。这些控制平面编排代理来处理典型开发者在 IDE 中执行的各种开发任务。
在几周内，Anthropic 和 OpenAI 都发布了暗示这一趋势的工具。Anthropic 新的 Claude Cowork 模式允许其 AI 助手直接访问本地文件夹，从而可以在您机器上的沙盒中读取、修改和创建文件。大约在同一时间，OpenAI 推出了 Codex macOS 桌面应用，这是一个用于并行运行多个 AI 编码代理的命令中心，具有内置的差异审查和无缝切换到您的 IDE 的功能。
OpenAI 的 Codex macOS 应用支持管理同时处理不同任务的多个代理。Anthropic 的 Cowork 和 Code 引入了桌面体验，将代理功能扩展到仅限于开发者的工作流程之外，允许代理读取文件、运行命令并在明确的沙盒中操作。
这是我们需要关注的主要思想。一旦用户界面围绕由控制平面驱动的编排构建，IDE 就不再是“家”，而变成了另一个界面。
什么是代理控制平面？
鉴于这听起来可能有些抽象，让我来具体说明一下。一个代理控制平面是一个桌面应用程序，它协调以下五件事：
- 任务，即需要完成的事情
- 工具，代理可以用来完成任务的工具
- 权限，明确允许代理访问本地资源，例如文件或数据库
- 上下文，这是代理的关键组成部分，提供有关代码库和项目的知识
- 审查，让开发者参与批准或拒绝输出的环节
这些功能超出了以 IDE 为中心的工作流程所能做到的。并行性，多个代理在单个聊天窗口中同时工作，试图一次处理一个线程。这意味着开发者可以启动多个代理，同时处理后端代码和前端 UI。长时间运行的作业，后台任务如测试套件、大型重构或数据库迁移异步运行，您稍后检查结果。以及系统级操作，代理在定义的范围内读取和修改文件、运行命令并与外部工具集成。
OpenAI 的 Codex macOS 应用支持启动长时间运行的任务，这些任务可以在开发者处理本地代码时卸载到云端。
在这个模型中，主要的开发者界面变成了任务仪表盘。而不是文本编辑器。
IDE 沦为“二等公民”
我希望澄清这个论断，因为简化版可能听起来不准确。IDE 并非可有可无。它们不会消失。但它们正在从编排层降级。
在代理优先的工作流程中，IDE 成为差异审查和审核界面，您可以在其中验证代理的输出。当代理卡住或产生细微错误时，它们会成为调试环境。它们仍然是处理棘手边缘情况的正确工具，在这些情况下，人类在字符层面的判断仍然至关重要。
日益增长的紧张关系是 IDEs 也是吸收代理。真正的战争不是 IDE 与代理的对决。它关乎编排的所在地。Apple 刚刚宣布将 OpenAI Codex 和 Anthropic 的代理直接集成到 Xcode 中，这表明 IDE 现有厂商将努力使 IDE 保持在开发者世界的中心。
IDEs 并未消亡。它们正在被重新定位为高信任度的验证工具。
竞争格局
如果编排超越 IDE，竞争格局将以令一些公司担忧、另一些公司振奋的方式转变。
以 IDE 为主的公司面临着真正的压力。如果控制平面位于 IDE 之外，编辑器就有商品化的风险。例如，JetBrains 面临着一个战略选择：是在代理优先的世界中成为最佳的审查和调试界面，还是构建并控制编排层本身。两者都是可行的途径，但“IDE 加 AI 功能”的舒适中间地带可能无法长期维持。
Microsoft 处于一个特别复杂的位置。它拥有 Visual Studio、VS Code 和 GitHub Copilot。推广独立的桌面控制平面将直接与其自身的以 IDE 为中心的栈竞争。我的假设是，Microsoft 将更倾向于将其编排嵌入到其现有界面中，而不是构建一些会削弱它们的东西。这种策略是否有效取决于嵌入式编排能否与专门构建的替代方案相媲美。
Google 有不同的机会。它已经在通过 Gemini CLI 推行 CLI 优先的代理路径，这意味着它可以在不蚕食其没有的 IDE 业务的情况下，跨界面推广编排。需要注意的是，这里的成功取决于分发和开发者信任，而不仅仅是模型质量。
什么会改变我的看法
三个反驳意见值得认真考虑。首先，IDE 可能深度集成代理，从而重新夺回编排层。Xcode 的举动表明这是一种真实的可能性。其次，桌面控制平面可能会分散注意力。开发者已经在使用太多工具，增加另一个界面可能会面临采用阻力。第三，安全和合规性要求可能会严重限制自主代理的行为，导致编排整合到企业工具链内部，而不是独立的应用程序中。
如果 IDEs 成为真正出色的编排层，拥有权限管理、后台代理执行、任务队列和插件生态系统，使得独立的控制平面变得不必要，我将修改我的立场。
岗位职责变了
过去，IDE 是软件诞生的场所。在代理优先的工作流程中，软件被验证和审查。
从编辑到编排的转变并非猜测。它正在 OpenAI、Anthropic、Google 和 Apple 发布工具中上演。下一个战场将不是哪个界面更漂亮或哪个模型更智能。它将关乎信任。审计、来源以及回答一个每月变得越来越重要的问题的能力。在这个代码库中谁做了什么，我能验证它吗？
