Head of Claude Code: What happens after coding is solved | Boris Cherny

来源: Lenny’s Podcast (YouTube) | 时长: 1:27:45 | 播放量: 204K+ 嘉宾: Boris Cherny — Claude Code 负责人 (Anthropic)，自学工程师，前 Instagram/Meta 代码质量负责人 原文: Head of Claude Code: What happens after coding is solved 精读日期: 2026-02-24

一句话总结

Claude Code 用一年时间从”一个小 hack”成长为重写整个软件工程行业的工具；编程已基本被解决，下一个被 AI 颠覆的是所有依赖电脑工作的职能。

核心数据

• 4% 的全球 GitHub 公开 commit 现在由 Claude Code 完成（Semi Analysis 报告），私有 repo 比例更高
• 预测年底前达到 全球 1/5 的 commits
• Anthropic 工程团队过去一年人数 4x，但人均生产力提升 200%
• Boris 本人：每天 ship 10-30 个 PR，100% 由 Claude Code 写，自 11 月起 0 行手写代码
• Claude Code DAU 过去一个月翻倍，增长持续加速
• 部分 Anthropic 工程师每月 token 花费数十万美元
• Co-worker（非技术版 Claude Code）：10 天用 Claude Code 本身构建完成，上线即大hit

Claude Code 的起源

• 起点：一个月乱做原型 + 一个月 post-training（理解模型底层）→ 开始做 QuadCLI
• 第一个令 Boris 震惊的 demo：给模型一个 bash tool，问”我在听什么音乐”，模型自己想出用 tool 来回答
• 内部发布公告：只获得 2 个 like
• 为什么选 terminal 形态？不是刻意设计，就是”只有我一个人时最容易做”
• “欠资源反而是好事”：人少→被迫用 Claude 自动化→逼出最优解
• 外部发布初期并不是大hit，花了几个月用户才真正理解这是什么东西
• Opus 4 + Sonnet 4 发布后才真正爆发，增长拐点出现

关键洞见

1. 编程已经被解决了

“Coding is largely solved. In a year or two, it’s not going to matter [if you know how to code].”

• Boris 在 2025年5月就预测”年底前可能不需要 IDE”，当时全场倒吸一口冷气，但他就是”描着指数曲线”推出来的
• 下一个前沿：非技术任务（Gmail、Slack、数据分析、订停车罚单）→ Co-worker 正是这个

2. 下一个被影响的职能

• 已发生：软件工程师
• 即将发生：PM、设计、数据科学，以及所有在电脑上工作的人
• 预测：年底前”Software Engineer”职位名称开始消失，被”Builder”替代；“人人是 PM，人人会代码”
• Lenny 的非正式调查：70% 的工程师和 PM 更享受工作（设计师只有 55%）

3. 下一个前沿：AI 主动提议做什么

Claude 现在开始： - 看 Slack 反馈频道 → 自动提 PR 修 bug - 分析 telemetry 和 bug report → 主动建议 roadmap - 变得”更像一个同事”，而不只是执行者

“Quad 正在从’工具’变成’co-worker’。这是我觉得最 exciting 的事情。”

4. Latent Demand（潜在需求）原则

Boris 最推崇的产品原则：

传统定义：看用户在”误用”你的产品做什么 → 那就是真需求 - 例：40% 的 Facebook Groups 帖子是买卖 → 催生了 Facebook Marketplace - 例：Claude Code 用户用它分析基因组、恢复婚礼照片、分析 MRI → 催生了 Co-worker

新版定义（AI 时代）：看模型想做什么 → 给它工具让它做到 - Claude Code 的核心思路：不要把模型装进盒子，把产品做成模型本身，最小化 scaffolding

5. 印刷机比喻

“识字 → 原来只有 <1% 的人口（书记员）才能读写。印刷机发明后，50年内印刷品总量超过之前1000年的总和，200年内全球识字率升至70%。”

编程 = 当代”识字能力”。AI 将让人人可以编程，就像印刷机让人人可以读写。 中间的阵痛是真实的，但最终是巨大的解放。

6. 对工程师技能萎缩的看法

“编程本来就是工具，不是目的本身。就像打孔卡 → 软件 → 今天，每次升级都有人说’这不算真正的编程’。这次也一样。”

• 他不担心自己的技能萎缩，因为编程对他从来都是手段（第一次编程是为了在 TI-83 里存数学题答案作弊）
• 但承认对某些人，这会有”失去感”和”怀旧感”

给 AI 产品构建者的建议

建议 1：不要把模型装进盒子

• 不要用严格的 workflow 约束模型（step 1 → step 2 → step 3）
• 给模型工具 + 目标，让它自己决定怎么做
• 一年前这些 scaffolding 还有用，现在大多数已经不需要了

建议 2：Bitter Lesson（Rich Sutton）

• 更通用的模型永远会赢过更专用的模型
• 不要微调、不要用小模型、不要过度定制
• Scaffolding 最多提升 10-20% 性能，但每次模型更新这些增益就消失了
• “Almost always bet on the more general model”

建议 3：为 6 个月后的模型构建，不是为今天的

• Claude Code 能成功，很大原因是从一开始就在”等”更好的模型，而不是优化现在的模型
• 前 6 个月 PMF 会很差，但模型跟上来后会直接命中靶心
• 对初创公司的具体建议：看什么功能”几乎能用但不够好” → 那就是 6 个月后的机会

建议 4：把 token 给够工程师

• 不要一开始就优化 token 成本，先让工程师自由实验
• “Unlimited tokens” 已成为 Anthropic 和部分公司的招聘福利
• 成本优化应该等到 idea 验证之后

Claude Code 使用 Pro Tips（Boris 本人）

1. 用最好的模型：Opus 4.6 + 开 Maximum Effort。用差一点的模型看似省钱，但因为效率低实际 token 消耗更多
2. Plan Mode 优先：80% 的任务先走 Plan Mode（terminal 里 Shift+Tab×2）。Plan Mode 本质上只是在 prompt 里加一句”先别写代码”，但效果显著。计划看起来对了之后 auto-accept edits，Opus 4.6 几乎总是一次命中
3. 探索不同界面：不一定要用 terminal。desktop app、iOS/Android app、Slack 集成都是同一个 agent，找到适合自己工作流的

Anthropic 的安全观

三层模型安全体系： 1. 机械可解释性（Mechanistic Interpretability）：研究模型神经元，追踪特定概念（如”欺骗”神经元）的激活。Chris Olah 发明了这个领域 2. Evals（实验室环境）：把模型放在”培养皿”里，用合成情景测试对齐 3. 野外观测：真实用户使用 → 最重要，尤其是模型越来越复杂之后

Claude Code 内测了 4-5 个月才对外发布，正是在研究 safety。 “Race to the top”：开源 sandbox，让其他 agent 也能用，推动全行业安全标准提升。

有趣细节

• Boris 和 Lenny（主持人）都来自乌克兰敖德萨市（Boris 88 年离开，Lenny 95 年）
• Post-AGI 计划：回日本农村做味噌（白味噌最少发酵3个月，红味噌2-4年，学会在工程快节奏之外以年为单位思考）
• Boris 的爷爷是苏联第一批程序员之一，用打孔卡编程；他妈妈小时候在打孔卡上画蜡笔画

Actionable Takeaways（对我的参考价值）

1. “欠资源”原则：团队人少时反而能逼出更激进的 AI 自动化。这对 OPC 投后项目评估有参考意义——资源受限的团队更可能把 Claude Code 用到极致
2. Bitter Lesson 应用：选择 AI 工具/供应商时，倾向于”更通用的基础模型”而非过度微调的专用方案，后者很容易被下一版模型整体碾压
3. 为 6 个月后构建：评估 AI 项目时，当前模型”几乎能做到”的能力，6 个月内大概率会完全解决，可以当作投资信号
4. Plan Mode：立刻养成对所有复杂任务先走 Plan Mode 的习惯
5. Latent Demand 新版：在 AI 产品设计中，观察模型想做什么而不仅仅是用户在做什么，这是找到下一个产品方向的关键信号

精读于 2026-02-24