视频来源：Head of Claude Code: What happens after coding is solved | Boris Cherny

Head of Claude Code：当“写代码”被解决之后，还剩下什么？

这期访谈最有价值的地方，不是“AI 能不能写代码”，而是一个更现实的问题：当代码生成逐步商品化之后，工程团队真正稀缺的能力会迁移到哪里。

Boris 给了几个明确判断：

• 他个人“100% 代码由 Claude Code 生成”
• 团队层面“工程师生产率提升约 200%”
• 公开市场层面，Claude Code 相关口径提到“GitHub commit 占比已到 4%”

这些数字未必能直接外推到所有团队，但足以说明一件事：写代码本身正在从核心产出，变成高层意图执行链路中的一环。

1. 从“写多少代码”转向“定义什么值得被实现”

访谈里反复出现一个转变：当模型负责编码执行，人类的瓶颈会前移到目标定义、优先级排序、验收标准。

“Now humans are necessary for figuring out what to build, what to prioritize.”

这意味着工程管理开始从“任务拆解 + 执行监督”变成“问题 framing + 反馈回路设计”。

2. 组织设计：刻意“轻资源”反而能推动 AI 采用

Boris 提到一个有争议但实用的组织策略：适度 underfunding（轻资源配置）。

核心逻辑不是压缩成本，而是逼迫团队默认进入 AI-first 工作方式。资源宽松时，团队更容易沿用旧习惯；资源受限时，才会主动把 token、agent、自动化流程用到极致。

这和很多公司“先试点、慢慢推广”的做法相反。Anthropic 的方法更像：先让一线团队在高压场景里跑出新工法，再回填制度。

3. 职能边界会变模糊，Generalist 价值上升

访谈中对招聘趋势的判断很清楚：

• 工程、产品、设计三条线的边界会持续模糊
• 能跨域协作、能端到端交付的人更稀缺
• “软件工程师”这个 title 的含义会被重写

这并不等于“专家失效”。更准确的说法是：专家仍然重要，但专家价值的呈现方式会从“单点深度”转向“深度 + 可编排能力”。

4. 产品策略：别过度约束模型，先观察“潜在需求”

Boris 提到两个产品层原则：

1. 不要一开始就把模型框死在狭窄流程里
2. 尽早发布，观察用户如何“滥用”产品（latent demand）

这对 AI 产品很关键。很多高价值场景不是 PM 预先设计出来的，而是用户在真实任务里“拧”出来的。产品团队的工作从“设计所有路径”变成“识别高价值偏离并产品化”。

5. 安全与可靠性：训练安全只是第一层，真实环境反馈同样关键

访谈里也提到安全三层：

• 对齐与可解释性（mechanistic interpretability）
• 训练期安全约束
• 上线后的真实行为观测

这基本对应了今天 Agent 系统的实践：离线评测能挡住一部分问题，但真正决定可用性的，仍然是线上任务闭环、失败恢复、审计能力。

编者分析：哪些观点值得保留，哪些需要谨慎

值得保留的部分

• “编码执行自动化，人的重心前移到问题定义”是高概率趋势
• 组织流程会被 AI 工具链重写，而不是只替换个别岗位
• 通用能力（沟通、判断、跨域整合）在 AI 时代不是软技能，而是产能技能

需要谨慎的部分

• 4%、200% 这类数字高度依赖团队基线与统计口径，跨公司可比性有限
• “title 会消失”更像方向性判断，不应被解读为短期确定事件
• “多给 token 就能创新”成立的前提是有明确验收、回滚和成本边界

给团队的 4 条可执行建议

1. 把工程绩效指标从“代码产出”改为“问题闭环速度 + 质量稳定性”
2. 让 AI 进入默认流程：PR 起草、测试建议、变更说明、回归检查
3. 招聘与培养上优先“能跨产品-工程-设计完成闭环”的人
4. 为 agent 工作流建立可观测性：失败类型、重试成本、人工接管点

当“写代码”越来越不稀缺，真正稀缺的是把复杂问题转成可执行系统的能力。这期访谈的价值，在于它给了一个一线团队视角的现实样本。