IDE 基本上已经走到尽头了
“IDE 基本上已经走到尽头了。”读完这篇关于 Gergely Orosz 行业观察的文章，我更关注这句话背后的变化：当代码主要由 Agent 生成，软件开发的瓶颈、工作界面和组织方式都要重新安排。
但这篇文章的价值不止于判断工具兴衰。它把效率的提升、质量的隐患，以及那些依然有效的工程常识放在了一起。理解这三者的关系，比追逐某一种新工具更重要。
开发者开始管理多个并行任务
Orosz 访问 AI 实验室和科技公司后发现，一些高产工程师已经从亲手写代码，转向同时运行多个 Agent。文中几位工程师描述的常态，是并行处理 5～10 个会话，在布置任务、检查结果和测试之间切换。
这改变了个人产出的限制。过去，一个人的键盘基本只能推进一件事；现在，等待一个任务执行的时间，可以拿来推动另一个任务。
我不会据此把“几乎没人手写代码”当成整个行业的统计结论。这些观察更多来自走在前面的团队，但它们已经说明了一种工作方式的可行性：工程师正在把更多时间用于定义任务、协调执行和判断结果。
文中引用的 GitHub、Linear 数据，也指向 Agent 创建 PR、Issue 和参与审查的增长。代码生产提速后，压力会沿着审查、测试、构建和部署一路传下去。
IDE 的中心正在从编辑转向验证
传统 IDE 围绕人阅读和修改代码来组织界面。文件树、编辑器、跳转和调试，服务的是这套工作方式。
如果人主要负责与 Agent 对话，界面需要回答的问题就变了：哪些任务正在执行？哪里需要我决策？结果是否符合要求？测试覆盖了什么？最终产品能不能直接试用？
所以，我把“IDE 走到尽头”理解为以手工编辑代码为中心的产品形态正在受到挑战。开发者依然需要上下文，只是任务状态、运行效果和验证证据的重要性上升了。
原文提到的 CLI、多 Agent 工作台和工具转型，都可以放在这个变化里理解。判断一个工具有没有未来，要看它能否帮助人掌握交付过程。
企业能力取决于 Agent 如何接入工作流程
文章中另一个值得注意的现象，是企业开始建设自己的 Agent 平台。开发任务可以从 Slack 发起，再交给云端 Agent，连接代码仓库、测试和部署系统。
所谓 Harness，可以理解为围绕 Agent 搭建的运行与控制环境。模型负责完成任务，平台负责让它获得合适的上下文、使用工具，并接受检查。
Skills 的普及也属于这条线索。团队开始把可复用的工作方法整理出来，供员工和 Agent 共同使用，而不必每次重新描述。
我的判断是，企业之间的效率差距，会越来越多地体现在这些连接上。同一个模型，孤立使用与接入完整工程流程，能够承担的工作范围差别很大。
这也解释了为什么 Agent 基础设施可能成为独立方向。未来需要被观察和评估的，既有 Agent 修改的软件，也有 Agent 自身的行为。
写得更快，必须有接得住的质量体系
文章最尖锐的部分，是对代码审查的质疑。变更量快速增加，人类审查能力没有同步增长，流程就可能退化成习惯性的通过。
我认为这比“代码是谁写的”更值得管理者关注。一个审批动作还在，并不意味着它仍然提供原来的保障。
Agent 审查可以分担工作，但最终仍要回答：我们凭什么相信这次修改可以上线？测试、运行效果、可观测性和故障处理，都需要提供证据。
文中关于软件质量下降的说法，主要来自受访者观察，不能直接证明 AI 是唯一原因。不过，它提醒了一个明确的问题：如果生成速度超过验证能力，更多产出也可能意味着更多缺陷。
文章同时指出，即使在高度使用 AI 的团队里，测试仍然占据重要位置。单元测试、架构设计、先跑通关键流程这些老方法，依然有价值。工具越能快速执行，前面定义的要求和后面设置的验证就越重要。
小项目可以少用人，长期责任仍然需要团队
原文提到，一些项目只需要一两名工程师，因为每个人已经带着多个 Agent 工作。参与者继续增加，反而容易出现修改冲突和协调负担。
但同一篇文章也强调，长期负责软件的团队依然存在。他们要持续迭代、值班、处理故障。项目实施的人数减少，与团队承担长期责任，可以同时成立。
复杂项目也没有跳过规划阶段。AI 能缩短实现时间，却不会自动消除目标分歧和跨团队依赖。
非工程人员的边界同样值得区分。在 Orosz 走访的公司里，产品经理和设计师会用 Agent 做原型、提出修复或实现功能，但生产发布仍由工程师把关。这是他的访问范围内的发现，也说明“能够做出来”和“能够承担上线责任”之间还有距离。
对组织而言，应该重新安排的是任务和责任，不能只根据代码产量决定团队规模。
迁移成本下降，算力与注意力成为新约束
重构和迁移，是文章中最具体的机会。文中列举了测试框架迁移、语言迁移等案例，一些原本预计耗时很久的工作，被压缩到几周或几个月。
这意味着，过去因为实施成本过高而搁置的技术债，值得重新评估。但能更快完成，并不代表每次重写都值得做。收益、验证成本和切换风险仍然需要计算。
与此同时，AI 开支开始进入工程管理的日常。文章提到，企业通过更低成本的模型和模型路由控制支出；Agent 活动增加，也带来了计算资源需求和容量压力。
还有一种更容易被低估的成本：人的注意力。多个 Agent 并行运行，总有任务等待反馈。受访工程师描述，个人效率提高后，组织对并行工作的预期也随之提高，结果反而觉得更忙。
我更关心每个任务完成后带来了什么价值，以及人花了多少精力处理返工和切换。Agent 数量本身，不适合作为效率指标。
工程师的价值向领域判断和交付能力移动
文章观察到，部分企业对通用型工程师的需求上升，初级招聘承压，一些管理者也开始回到亲手构建产品的岗位。这些变化还不能简单概括成某类岗位的消失，但工作内容显然正在调整。
当实现能力变得更容易获得，知道应该解决什么问题就更加重要。懂业务、懂客户、懂系统历史的人，更有条件判断哪些需求值得做，哪些结果不能接受。
愿意学习 AI 工具会成为基本要求。但我不赞成把运行多少个 Agent、是否还看代码，当成能力等级。真正应该考察的是：能否把任务说清楚，能否识别错误，能否把成果可靠地交付出去。
这也是我读完文章后的判断：软件工程正在获得更强的执行能力，同时对人的判断提出更高要求。更快地构建东西，是机会；知道该构建什么，并对结果负责，才决定机会最终能否兑现。