Boris Cherny 新访谈：开发工具正在从 IDE 变成 Agent 控制台¶
Ch04.315 Boris Cherny 新访谈：开发工具正在从 IDE 变成 Agent 控制台¶
📊 Level ⭐⭐ | 7.9KB |
entities/boris-cherny-interview-2026-ide-to-agent-console.md来源：原文存档
深度分析¶
1. 开发工具控制点正在从 IDE 光标迁移到 Agent 控制台 Boris Cherny 在访谈中描绘的愿景，核心不是"AI 帮工程师更快写代码"，而是整个软件工程的交互界面正在发生结构性迁移。过去的控制点是文件、函数、命令和光标；现在越来越多地变成目标、约束、权限、预算、验证和审查。这意味着开发工具的形态不再只是 IDE，而是一套能管理 Agent 工作流的控制台——观察、调度、审查。这不只是 Claude Code 一家的变化，而是整个软件工程控制点的一次迁移 。 2. "coding is solved" 需要拆开理解——代码生成变便宜，软件工程没有变简单 Boris 说对自己而言 coding 已经 100% solved，但这句话有严格边界：Claude Code 主栈是 TypeScript 和 React，踩在模型最熟悉的分布里，且团队整个围着 Claude Code 重新搭建了工作方式。换到 C++ 老系统、强合规银行核心、嵌入式固件，问题远不只是"代码能不能生成"，还要回答历史设计为什么是今天这样、哪些边界不能动、变更怎么过审、数据风险怎么隔离、失败以后谁来负责、审计记录怎么留。Agent 能做的越多，治理问题暴露得越早 。 3. Loop 将 Agent 从"一次回答"变成持续运行的工作进程 Boris 很多任务已经不是"一次 prompt 得到一次回答"，而是：定义目标，Agent 定期观察、持续执行、发现异常、尝试修复、记录过程、把关键结果推给人，人只在需要判断、审批、取舍时介入。这种模式的关键在于：一旦 Agent 变成长期进程，开发工具要展示的不只是"模型说了什么"，还要让人看见 Agent 正在做什么、跑到哪一步、失败几次、改了哪些文件、调用了哪些工具、花了多少 Token、有没有触碰危险资源、哪些动作需要人工确认。IDE 因此从"写代码的地方"变成"Agent 工作流的观察台、调度台和审查台" 。 4. 模型差距在缩小，Harness 差距在放大 同一模型放进不同 Coding Agent，体感差距往往不在模型本身，而在模型外面那套运行底座：工具怎么定义、上下文怎么取、状态怎么留、权限怎么管、失败怎么恢复。一旦 Harness 承重，就要像线上系统一样持续评估、观测、回滚，也要在模型升级后及时清掉那些已经过时的补丁。Boris 讲 Loop、并行 Agent、手机里的 session、Anthropic 内部流程，这些都在给 Agent 补同一套底座 。 5. SaaS 从前台入口退到 Agent 后台能力层，但不会简单消失 很多 SaaS 不会消失，但会从人的前台入口退到 Agent 的后台能力层。以前人每天打开 CRM、Jira、Notion、Google Docs、Excel、ERP、BI；以后用户可能只在一个工作台里说话，Agent 查客户记录、更新 CRM、生成跟进计划、同步 Slack、汇总报表。Salesforce 们还在、数据库还在，但人不一定再直接操作它们。变化是：能不能被安全调用的系统会继续留在工作流里，只能靠人点界面的系统存在感可能会慢慢往后退 。
实践启示¶
1. 用目标-约束-验证框架替代"分配任务"思维 工程师未来越来越重要的职责是把含糊需求整理成 Agent 可执行的规格，判断 Agent 方案是否漏了关键边界，设计测试和评估让结果自己说话。这意味着要从"分配写代码任务"转向"定义清晰的目标和约束条件，让 Agent 在边界内自主执行" 。 2. 为 Agent 搭建工作台而不是给 IDE 装插件 如果还把 AI 编程工具当作 IDE 里一个浮在旁边的加速按钮，思路就还是旧的。应该把它理解成一整套让 Agent 能进入工程链路的运行环境：读代码库、跨文件修改、运行测试、在修改文件或执行命令前请求明确权限。这意味着要重新设计工具链，而不是简单接入一个更聪明的补全工具 。 3. 区分哪些动作可以自动、哪些必须人工确认 Agent 能读仓库、改文件、跑命令、连 Slack、查数据库、修 CI、开 PR，已经不是普通插件，而是一个新的工程参与者。需要尽早建立权限边界和审批机制：哪些风险动作需要人工确认，哪些可以默认执行但保留日志，失败后怎么停下来、怎么回滚。这比问"模型会不会写代码"更贴近真实的工程问题 。 4. 组织升级比模型升级慢得多——先把流程适配进来 Anthropic 内部真正领先的，不一定是模型本身，而是组织流程。工程师还是按老流程排需求、写代码、提测、上线、修问题，AI 只是某个环节的辅助工具，这样也会有提升但和 Boris 描述的工作方式不是一回事。要真正用好 Agent，需要重新思考：哪些任务可以交给 Agent 常驻、哪些只能由人触发、Agent 之间能不能互相发消息、跨团队问题谁来兜底、失败日志归谁看、成本预算怎么算 。 5. 把成功经验沉淀成团队 Skill 或 Runbook 代码生成变快以后，样板代码、重复修改、机械排障、低风险迁移慢慢被 Agent 接过去，人可以把精力放回更难、也更有价值的问题。但一次成功经验如果不能沉淀成团队 Skill 或 Runbook，就没法复制。长期来看，团队的核心竞争力之一会是：把"会用 AI"变成"可复制的工程能力"——有结构化的 Harness、有文档化的 Skills、有可传承的流程知识 。