本文为视频内容简介，由 AI 整理生成。
假设有一天，AI 写代码已经比你强，软件工程师还剩下什么工作？
这是 Anthropic Claude Code 团队的 Daisy Hollman 在这场演讲里提出的问题。她曾经长期参与 C++ 标准委员会，但过去一年多在 Anthropic 的经历，让她越来越觉得「自己能不能比模型更熟练地写代码」正在变得没那么重要。
因为当 Agent 可以自己读代码、改文件、运行测试、发现错误并继续修改时，人的工作就开始从「我来写代码」变成另外一件事：定义问题，提供信息，设计工具，建立反馈，然后同时管理多个 Agent 的工作。
我觉得这也是整场演讲最有意思的地方。它不是在介绍 Claude Code 的几个高级用法，而是在讨论一个更大的变化：当 AI 越来越会编程之后，我们该如何重新建设软件工程环境？
Agent 没有想象中神秘
Daisy 先拆解了 Agent 到底是什么。ChatGPT 最初只是人提问、模型回答；后来模型可以调用 Bash、读取文件、修改代码，再把执行结果放回 Context；当这个循环可以持续很多轮，而且模型能自主决定下一步做什么，它就成了 Agent。
所以 Claude Code、Codex、Cursor 这些 Coding Agent，核心其实都可以概括成：
1 | LLM + Tools + Loop |
甚至 Claude Code 的文件编辑工具都比很多人想象得原始，本质上接近一次精确字符串替换：给出文件名、旧字符串和新字符串。它没有人类使用 IDE 时的光标、选区，也没有天然的代码结构感知。
但模型能力进步之后，即使工具这么简单，它仍然可以完成越来越复杂的任务。这说明 Coding Agent 的瓶颈正在发生变化：问题不再只是模型会不会写代码，而是我们给它的环境够不够好。
为什么小项目里很强，进了大公司就变笨
Claude Code 开箱能看到的东西很少：当前代码仓库和 Shell。
可一个真正的软件工程师完成任务时，信息只存在 Git 仓库里吗？显然不是。工程师还要看 Slack 里的讨论、Jira 上的需求、CI 的结果、Grafana 的监控、内部 Wiki、设计文档、历史 PR，以及那些只有团队成员才知道的约定和失败经验。
这就是 Programming 和 Software Engineering 的区别。写出一段代码只是 Programming；知道为什么要这样改、会影响哪些系统、过去为什么没有采用另一个方案，才是 Software Engineering。
小项目的大部分信息就在代码里，所以 Agent 看起来无所不能。进入大型组织之后，真正决定修改是否正确的信息散落在十几个系统里，而 Agent 默认一个也看不到。你让它只拿着仓库和 Shell 工作，就像让一个刚入职的工程师在不能问同事、不能看文档、不能进内部系统的情况下修线上问题。
Daisy 的核心判断是：如果 Claude 没有工程师完成任务时拥有的信息和工具，就不能期待它完成工程师的工作。
Context Window 才是真正稀缺的资源
于是一个自然的想法是：把所有资料都提供给模型。
但这很快会碰到另一个问题。模型训练完成后，公司内部知识只能通过 CLAUDE.md、文档、MCP、Skill、Hook 等方式进入 Context，而 Context Window 并不是无限的。每塞进去一段当前任务用不到的说明，都在挤占模型真正思考问题的空间。
这也是演讲里反复出现的一条原则：
不要为没有使用的信息支付 Context 成本。
MCP 可以让 Claude 访问外部系统，但每个 Tool 的名称、说明和参数 Schema 都需要占用 Context。如果一个大公司接入几十个 MCP Server、暴露几百个工具，Agent 可能还没开始工作，上下文就已经被工具说明吃掉一大块。
Tool Search 的做法是先给模型一个轻量索引，需要时再加载完整工具定义。Skill 则更像 Lazy System Prompt：模型最初只看到名称和简短描述，判断与任务有关后才读取完整的 SKILL.md。Subagent 更进一步，让另一个 Agent 在独立 Context 中阅读大量文件，主 Agent 最后只接收压缩后的结论。
这些机制看似不同，其实都在解决同一个问题：不要让模型一开始知道所有东西，而要让它在需要的时候找到正确的东西。
比长 Prompt 更有价值的是红色波浪线
Daisy 最喜欢的机制是 Hook，因为它几乎不消耗 Context，却能建立非常紧密的反馈循环。
例如 Claude 修改 Java 文件后，Hook 自动运行 Checkstyle、编译器、内部 Lint 或架构检查。没有问题就保持沉默；出现问题才把具体错误返回给模型。它很像 IDE 里的红色波浪线：工程师不需要在写每行代码之前背一遍语言规范，只需要在犯错的位置立即收到反馈。
这比继续往 Prompt 里增加「请注意代码规范」「请不要破坏架构」更可靠。Compiler、Test、Lint、CI 之所以重要，不是因为 Agent 不够聪明，而是因为再资深的工程师也需要这些工具。模型能力越强，这类确定、及时、可执行的反馈反而越有价值。
演讲里有一个很好的区分：有些工具是为了限制一个能力不足的 Agent，例如禁止它修改某个目录；另一些工具则是高级工程师也离不开的工作台，例如测试、编译器和监控。前一种工具可能随着模型变强而失去价值，后一种工具却可以与模型能力一起扩展。
当一个工程师同时管理几十个 Agent
到了 Anthropic 内部实践的部分，问题又变了。
Daisy 认为，2025 年的主要挑战还是「怎么把正确的信息送进模型」；到了 2026 年，挑战开始变成「怎么把模型正在做什么高效地告诉人」。因为一个工程师已经可以同时启动十几个，甚至几十个 Agent。此时最稀缺的资源不再是 Token，而是人的注意力。
Anthropic 内部会用 Git Worktree 给多个 Agent 建立独立工作区，每个 Agent 可以有自己的名称、颜色和 Memory，像长期协作的虚拟团队成员。Agent Teams 让 Agent 之间直接通信和分工，不需要每条消息都经过人类中转。/loop 可以让 Agent 定期检查 CI，失败后继续修改，成功后自动停止。Auto Mode 则尝试在自动执行和安全确认之间寻找平衡，避免几十个 Agent 不断弹出授权请求，把工程师重新变成人肉调度器。
这里最值得注意的不是「Anthropic 同时跑了多少个 Claude」，而是软件工程的瓶颈已经开始向上移动：过去我们优化人写代码的速度，后来优化 Agent 获得信息的效率，接下来要优化的是一个人如何理解、协调和验收大量 Agent 的工作。
软件工程没有消失，只是换了对象
演讲最后给出的三个建议很简单：让模型能访问完成工作所需的信息和系统；认真考虑有限的 Context Window 里应该放什么；选择能够扩展到大型软件工程环境的抽象。
这场演讲让我印象最深的地方，是它没有把 Coding Agent 描述成一个更聪明的代码补全工具。它真正讨论的是：如果未来写代码本身越来越便宜，工程师的价值会转向哪里？
答案可能是为 Agent 建设它所处的环境。让知识可以按需发现，让错误能够立即反馈，让任务可以并行但仍然可控，让人的注意力只花在真正需要判断的地方。
AI 没有让软件工程消失。相反，当写代码的不再只有人，软件工程可能才刚刚变得更重要。
References
How Anthropic uses Claude Code: Agentic Software Engineering at Scale - Daisy Hollman