我刚刚取消了 JetBrains 的年度订阅。
几年前，这对我来说几乎不可想象。IntelliJ 和 JetBrains 套件里的其他产品，正是我乐意付费购买的软件：功能强大、打磨精良的开发工具，拥有大量功能，让大型代码库的编写、浏览、重构和调试变得轻松得多。很长一段时间里，对我而言，软件开发就是在 IDE 里进行的。
问题是，我现在几乎不再打开 IDE 了。
并不是因为我不再开发软件了。恰恰相反，我现在开发的软件可能比以往任何时候都多。区别在于，我越来越少通过 IDE 与代码库交互。我使用 Orgabot 和其他智能体运行环境，描述自己的需求，然后让智能体检查仓库、追踪相关代码、修改文件、运行测试、修复失败、审查实现、创建拉取请求、解决冲突，并继续推进工作。
我的主要编程界面，已经逐渐从一个装满源代码的文本编辑器，变成一场围绕意图展开的对话。自然语言成了我的编程语言。
IDE 曾是应对复杂性的界面
几十年来，IDE 一直是软件开发的驾驶舱。随着代码库越来越大、编程语言越来越复杂，简单的文本编辑器已经不够用了。开发者需要符号导航、智能补全、静态分析、重构工具、调试器、测试运行器、数据库浏览器、版本控制集成、依赖管理，以及几十种其他便利功能。
IntelliJ 这样的产品在解决这个问题上做得极其出色。当我每天都在亲自操作代码库时，这些功能物有所值。但从更高的层面看，IDE 本质上是一种帮助人类理解和修改大量源代码文件的工具。
智能体开发改变了执行这些操作的主体。
代码库还在，编译器也还在。Git、测试、代码检查器、类型系统、调试器、包管理器和构建系统都没有消失。变化在于，我越来越少亲自操作这些工具了。操作它们的是智能体。
你还需要去读代码吗？
我很少需要查看代码。正是这个发现最终让我取消了 JetBrains 订阅。我几乎不再为了“写代码”而打开 IDE。有时我会因为好奇某个实现而查看文件。偶尔会手动做一个很小的修改。我也可能看看差异，或追查特别奇怪的问题。
但这些情况现在都是例外，而不是主要工作流程。如果我只是需要查看一些文本，一个基础编辑器就完全够用了。为了偶尔手动打开源文件，我不需要一个占用好几个 GB 的 IDE，更不需要为此支付年度订阅费。
我过去在 IntelliJ 中依赖的绝大多数功能仍然重要。我仍然需要智能代码导航、重构、测试、静态分析和代码审查。只是我越来越希望由智能体来完成这些事情，而不是自己逐个操作工具。
工具没有消失。它们只是移到了我日常工作所在的抽象层之下。
顺带一提，我在这里描述的那种界面是有文档的：Claude Code 就是围绕终端里的智能体编程构建的，而不是围绕一个编辑器窗口。
自然语言正在成为编程界面
编程语言一直在不同程度上尝试让机器更容易被人理解。随着我们远离机器码和汇编，语言逐渐变得更有语义。我们有了名称有意义的变量、读起来像动作的函数、模拟现实概念的面向对象结构，以及声明式语言，让我们越来越多地描述想要什么，而不是实现目标所需的每一条指令。
但它们依然是编程语言。
如果有人在 30 年前告诉我，有一天我会把每天大部分编程时间用来对着计算机说或输入普通英语，我会认为那是在胡扯科幻故事。然而，这基本上就是我现在的工作方式。
当然，英语并没有真的替代 TypeScript、Python、Go、Java 或最终实现系统的其他语言。我的 CPU 不会执行我写给智能体的某一段话。但从技术栈中人类这一侧看，这种区别正在变得不那么重要。
编程一直是在把人的意图转化为机器可以执行的东西。随着时间推移，我们不断把这项转化中人类所处的一侧提升到更高的抽象层。人类曾直接操作机器指令。汇编为这些指令赋予了名称。高级语言让我们不必关心寄存器也能描述算法。框架让我们不必实现每个基础构件也能描述应用。基础设施即代码让我们可以描述整个环境，而不必手动配置服务器。
智能体又增加了一层。我们不必亲自表达每一个实现细节，而是越来越能够表达期望的结果：
- 为这个服务商添加 OAuth 支持。
- 查明这个 API 端点为何偶尔返回过期数据，并修复它。
- 重构这些服务，让它们共用同一个授权层。
- 实现这个 GitHub Epic 及其所有子问题。
- 检查产生的拉取请求是否存在安全问题，准备好后将其合并。
这些就是编程指令。最终产物可能是几千行传统源代码，但其中大部分并不是我亲手写的。我描述了想要的系统，设定约束，评估结果，然后让机器把我的意图转化为它们需要的语言。
三十年前，让普通英语处于软件开发技术栈顶端的想法听起来像科幻。现在，这就是我的日常工作流程。自然语言并没有取代系统下层的编程语言；它正在成为我使用的编程语言。
真正有价值的能力从来不只是语言
拥有多种编程语言的经验仍然极其有价值。了解不同语言如何建模类型、并发、内存、状态、接口、错误和抽象，能让你形成更好的心智模型，用来评估智能体的产出。这些经验能帮助你识别糟糕的架构、不必要的复杂性、脆弱的接口，以及日后可能引发问题的实现选择。
但我认为，更重要的能力是构建复杂系统的经验。语言归根结底只是实现目标的手段。
软件开发的难点从来不只是记住语法，或者知道应该调用哪个库函数。真正困难的是决定边界应该划在哪里，理解组件应该如何交互，预判故障模式，管理状态，为变化而设计，做出权衡，调试涌现行为，以及判断一个看似合理的实现何时会在现实世界的复杂性面前崩溃。
这些能力不会因转向智能体开发而消失，甚至可能变得更重要。如果智能体能按需生成合格的 TypeScript、Python、Go、Rust 或 Java 代码，那么熟练掌握某种语法就不再那么稀缺。更有价值的是知道该构建什么，各部分该如何组合，哪些约束重要，以及结果是否真的足够好。
这也是为什么我不认为未来只属于擅长写提示词的人。一个聪明的提示词不能代替工程判断力。拥有几十年系统构建经验的人，可以看着智能体的计划，发现边界划错了、数据模型无法扩展、安全假设薄弱，或者提出的架构根本解决错了问题。
智能体能够越来越多地承担从意图到实现的转化。但人仍然需要理解系统。
对我来说，这才是真正的转变：编程语言向技术栈下层移动，而架构、判断力、编排和系统思维向上层移动。
Cursor 和 Windsurf 能解决这个问题吗？
Cursor 和 Windsurf 也解决不了这个问题。显而易见的回应是：传统 IDE 也许在式微，但 Cursor 和 Windsurf 这样的 AI 原生 IDE 才是未来。我不这么认为。
Cursor 和 Windsurf 本质上仍然是 IDE。它们假设软件开发的中心是一个正在查看源文件、浏览仓库、选择代码、审查差异，并在编辑器内与 AI 交互的人。这在我看来已经像是一个过渡阶段。
此后两者都加入了终端智能体和自动化接口，这确实是朝这个方向迈出的一步。但编辑器仍然是产品本身：新功能落在那里，注意力也在那里，你掏钱买的还是它。
如果我通过 Orgabot 或其他智能体运行环境工作，我对 AI 增强编辑器的需求并不比对传统编辑器更多。我不会坐在那里等自动补全，不会选中一个函数让 AI 重写，也不会在助手看着我操作时手动切换文件。
我把任务交给智能体。
智能体可以打开文件、搜索代码库、检查依赖、运行命令、读取测试失败信息、修改二十个文件、启动子智能体、审查变更，然后持续迭代直到任务完成。到了这一步，把 AI 放进 IDE 里几乎像是把方向搞反了。
目标不是让人类编辑代码的速度大幅提高。目标是让人类需要编辑的代码大幅减少。
这个区别很重要。Cursor 和 Windsurf 可能是更适合 AI 辅助编程的驾驶舱，但我正在走向的方向越来越不需要驾驶舱了。主要界面变成了任务、问题、规格说明或对话。源代码仍然至关重要，但它成了在这一界面之下生成和操作的产物，而不是我整天停留的地方。
所以，取消 JetBrains 后，我没有改用 Cursor 或 Windsurf。我用智能体替代了 IDE。
我不想再做那个程序员了
Orgabot 让我又向前迈了一步。当我用 Orgabot 创建应用或组织时，我不是以一个拥有更好编码工具的软件工程师的身份来开展工作，而是站在 CEO 的角度。
CEO 不会打开源文件去修复函数。CEO 定义目标、分配责任，确保合适的人或智能体参与工作，检查结果是否符合目标，并在流程出问题时调整组织。
编排工作本身也可以委派。CEO 可以让 CTO 交付一个产品，CTO 再根据这一授权协调工程、安全、基础设施、设计和审查工作。CEO 不需要知道哪个文件包含身份验证中间件。
这越来越接近我构建软件的方式。我可能会说：
- 做出这个产品。
- 解决这个 Epic 及其所有子问题。
- 调查这个系统为何发生故障，并解决根本原因。
- 发布前让安全团队审查实现。
- 在不降低质量的前提下降低这个工作流程的成本。
这些指令会产生最终形成代码的工作，但代码位于我操作的界面之下好几层。
由此可以得出一条实用原则：如果 CEO 正在审查或编辑源代码，那么其下方的某个工作流程可能已经出了问题。
也许工程智能体失败了，也许审查流程薄弱，也许组织缺少合适的角色或技能，也许问题上报的边界设错了。无论原因是什么，答案都不应该是无限期地把 CEO 拉回实现层，而应该是修复系统，让组织下次能够妥善完成这项工作。
这也是我对用 Cursor、Windsurf 或其他 AI IDE 替代 IntelliJ 兴趣不大的原因。这些工具让程序员在编码层内更有效率。Orgabot 则试图让编码层成为我很少需要进入的地方。
IDE 可能正在变成一个实现细节
这就是为什么我认为我们正在进入后 IDE 时代。
这不意味着 IDE 明天就会消失，甚至不意味着图形化代码编辑器会消失。有些时候，直接查看源代码永远是理解问题的最佳方式。但我认为，IDE 正在失去它作为程序员与软件之间主要界面的地位。
智能体运行环境正在成为这一界面，这让传统 IDE 公司和 AI IDE 公司都面临一个棘手的战略问题。显而易见的应对方式一直是把 AI 放进 IDE：添加聊天面板、自动补全、智能体模式，让 AI 一次修改多个文件。
这些改进很有用，但我怀疑，它们是否把架构反过来了。
未来也许不是一个内置智能体的 IDE，而是一个内置编辑器的智能体。
智能体成为环境本身。仓库、终端、浏览器、调试器、编辑器、测试、持续集成系统、问题跟踪器和部署基础设施，都是这一环境在需要时可以使用的工具。大多数时候，人类停留在比它们高一层的位置。
我取消 JetBrains，不是因为 JetBrains 变差了
这个区别很重要。JetBrains 失去我，并不是因为 IntelliJ 变成了糟糕的软件。恰恰相反，IntelliJ 仍然是一项能力惊人的工程成果。
我取消订阅，是因为工作方式发生了巨大变化，我已经不再需要它 99% 的功能，而这是一种更大的威胁。最难应对的竞争问题，不是有人做出了你产品的更好版本，而是用户行为变化如此之大，以至于整个产品类别本身都变得不那么重要。
多年来，我一直想要最好的源代码编辑环境。后来，我想要最好的环境来指挥编辑源代码的智能体。现在，即使这样描述，也越来越不足以概括未来的方向。
我想要最好的环境，用来创建智能体组织：它们能够承担责任、委派工作、相互审查、在必要时上报问题，并产出软件，而不要求我下沉到实现层。
IDE 不是那个世界的中心。它只是某个智能体可能会使用的一件工具。
在 IDE 里生活了这么多年之后，我想，我也许终于离开它们了。
