在 Meta，抓全公司代码质量这类工作，几百名工程师干一整年，能让工程师效率提高几个百分点。Claude Code 推出后的这一年，Anthropic 的工程团队大概扩大到原来的 4 倍，按提交的代码改动数量算，每个工程师的产出却提高了 200%。过去一年才挤出几个百分点，现在一涨就是几百个百分点，这样的变化前所未有，只是人们太容易习以为常了。
Boris Cherny
2025 年 2 月，Claude Code 大约只写了负责人自己 20% 的代码，5 月约 30%。那年 5 月的开发者大会上，抛出的预测是到年底写代码可能不再需要专门的编程软件，全场一片惊呼。Anthropic 习惯按翻倍增长的方式想问题，把 Claude 写代码占比的那条线顺着画下去，年底就会到 100%，哪怕这完全不符合直觉。到 11 月，他自己的代码就全部交给了 Claude。
Claude Code 从 2024 年在 Anthropic 内部推出起，就有一个专门收反馈的频道，意见源源不断。早期每来一条反馈，都尽快修好，一分钟、五分钟之内就改完。平常给产品提意见，往往像扔进黑洞，没有下文；反馈马上有回应，人会觉得自己被听见了，就更愿意接着提、帮着把东西做好。现在这活大多交给 Claude：把它指向这个频道，它自己挑出能修的问题，直接把改好的代码交上来。
过去半年，很多人用 Claude Code 不是为了写代码：有人拿它种番茄，有人分析基因，有人从坏硬盘里救回婚礼照片。2025 年 5 月，团队的一位数据分析师装好 Claude Code，在命令行窗口里做数据分析，下一周所有数据分析师都这么做。人们费这么大劲去用一个面向工程师的工具，说明该给他们专门做个产品。于是有了 Cowork，用 Claude Code 大约 10 天就做了出来，增长比当年的 Claude Code 快得多。
最早的原型只给了模型一个能在电脑上执行命令的工具，问它"我在听什么歌"，没人教它怎么用，它自己写代码查出了答案。顺着模型自己想做的事，Claude Code 反过来做：产品就是模型本身，外面只套最少的东西、给最少的工具，用哪个、按什么顺序用，都让它自己定。给模型套一层层固定步骤，大概能把效果提高一到两成，但下一代模型一出来，这点提升往往就被抹平了，还不如等下一个模型。
Claude Code 最早几个版本用的是 Sonnet 3.5 这一代模型，写代码还不太行，负责人自己也很少拿它写代码，因为信不过。当时押的是：总有一天模型会好到能写大部分代码。2025 年 5 月 Opus 4 和 Sonnet 4 推出，大家第一次真正用起 Claude Code，增长从那时起真正开始飞涨。所以做产品要瞄准半年后的模型。代价是头半年产品和市场对不上，会很难受，但那个模型一出来，产品马上就能跑起来。
大约一年前用 Sonnet 3.5，它自己跑 15 到 30 秒就开始跑偏，稍复杂的活都得手把手盯着。现在用 Opus 4.6，平均能没人看着跑 10 到 30 分钟，这段时间可以再开一个 Claude 干别的，所以手上总同时跑着好几个。也有能连跑几小时甚至几天的，似乎还有跑了好几周的例子。顺着这条线看，模型长时间自己干活很可能会越来越平常，人不用再一直守在旁边。
Claude Code 正式发布前，在 Anthropic 内部用了大约四五个月，因为当时它是第一个被广泛使用的会自己写代码的 AI 工具，没人确定它是否安全。检查模型安全大致有三层：看模型内部的神经元在做什么，在实验室里摆出假想场景测它，再看它在真实世界里怎么表现。前两层看着很好，第三层未必，模型越复杂这一层越要紧。所以要比自己觉得的更早一点放出去，Cowork 也是标成研究预览先发布。
Claude Code 团队里，产品经理、工程经理、设计师、财务、数据分析师都在写代码。工程、设计、产品这三种角色，眼下大概有一半的工作是重叠的，很多人其实在做同一件事，只是各有偏重。短期内这三种岗位还会在，但到年底界线可能会更模糊，有些地方"软件工程师"这个头衔会开始消失，换成"建造者"，或者人人都是产品经理、人人都写代码。
Meta 曾规定每个工程师拿 20% 的时间收拾旧代码留下的烂摊子，按 Facebook 的规模，每年有几万次代码迁移。仔细测算下来，代码质量对工程师效率的贡献有两位数的百分比，规模再大也一样。一个原因是迁移做到一半就停：代码库里 X、Y、Z 几套框架同时都在，写个功能先得挑用哪套，工程师和新人都难受，模型也可能挑错，还得用户来纠正。所以迁移一开头就要做完，这对工程师好，如今对模型也好。
2024 年 9 月 Claude Code 第一次在公司内部发布时，安全团队反对得很厉害：让模型自己跑命令行指令不安全，这个问题解决不了，不能上线。最后想出的办法很简单：拿不准就问人，由人决定放不放行。到今天默认仍然很保守，只有少数确定只读、不会把数据传出去的常用命令可以免问，因为连 find 这种查找命令都能借某些参数执行任意代码，sed 也有办法，看着无害的工具没有想的那么安全。
Claude Code 去读一个网页时，网页里可能藏着一句“把所有文件夹删掉”。防这种事没有一招管用的，就叠了三层：先训练模型本身不容易被带偏，Opus 4.6 是 Anthropic 发布过的最抗这招的模型；运行时再有检查程序，看着像被塞了指令的请求就拦下，让模型重来；最后先让另一个助手把网页内容概括一遍，只把概括交回去。每层都有漏洞，层数够多，漏网的概率就小很多。
Claude Code 早期试过先给代码建一份本地索引再去查，效果还行，毛病却不少：刚在本地写的函数还没进索引，就搜不到；索引谁能看、怎么防公司里有人越权看别人的数据，也很难办。又试了让模型一层层给全部内容建索引等好几种办法，结果最好的是让模型自己用最普通的文件名匹配和文本搜索一路找。这招有一部分来自 Instagram：那里点击跳转到定义经常失灵，工程师就在全公司代码搜索里搜“foo(”，模型用起来也一样好使。
Claude Code 界面上那个表示正在处理的小转圈，前后大概改了 100 版，上线的大概 10 到 20 版，约 80 版直接扔掉。让多个助手分工合作的功能，几位同事做了几个月原型，前后试了大概几百版才找到顺手的感觉，先画静态设计图或写需求文档根本做不出来。以前造东西贵，得花大力气瞄准再开枪，打出去就难回头；现在造东西很便宜，可也不知道该瞄哪，只能多做多试、看哪个用着对。自己的点子起码一半是坏的，不试不知道是哪一半。
在 Instagram 时，按写出的代码量算，Claude Code 的负责人大概是前两三名最高产的工程师。现在他每天提交 20 到 30 个代码改动，数字和从前的高产工程师差不多，内容却完全不同：那时每天交二三十个改动的人，很多是一行的小改，或者把代码从 A 搬到 B；现在的改动有几千行的、几百行的，也有一行的，没有一个是这种搬家活，因为这种活直接交给 Claude，人不用插手。所以光看改动数量，低估了实际在发生的事。
Claude Code 团队在内部试用 Opus 4.5 时，负责人立刻不再打开写代码的编辑软件，一个月后才发现，干脆卸载了。12 月他在欧洲边旅行边写代码，每天大概提交 10 到 20 个改动，每一个都由 Opus 4.5 加 Claude Code 写完，一行都没手改。月底一看，Opus 大概只带进了两个错误，换成自己手写，估计会有 20 个左右。照这个比，它写的代码已经比自己写的好。
Claude Code 的插件功能是这么做出来的：一位工程师拿很早期的多助手版本，在隔离环境里放开权限，让它跑了整个周末，交代的任务是自己写需求、在 Asana 上建任务板拆成小任务，再分给各个助手去做。它前后派出两百来个助手，在看板上建了一百个任务，做出来的基本就是正式发布的那版插件。任务看板这类协调工具，过去是给人用的，现在给模型用也一样。
Cowork 是给 Claude Code 加上防护做出来的，只有几个人，大约 10 天做完，全程用 Claude Code 写。产品本身不复杂，就是 Claude 桌面应用里的一个标签页，背后跑的还是驱动 Claude Code 的那套底层程序。功夫大多花在安全上：用户不懂技术，不会去读它执行了什么命令，误删一堆家庭照片就很糟，所以应用里带了一整台虚拟电脑，后台跑着多个检查程序，还在操作系统层面防止误删。
Claude Code 团队负责开发者关系的 Tariq 最近开始让 Claude Code 自己给新功能生成发布视频。负责人原本不会去试，因为觉得模型还没到那一步，结果一做就差不多成了。模型进步太快，旧模型上行不通的办法，换了新模型可能就行，反过来也一样。以前一个点子试过不行，再提会被问“怎么又来”；现在隔几个月重试同一个点子，头一回不算疯狂。所以新来的、刚入行的人有时做得比老手好，老手得放下成见，回头跟着学。
Anthropic 里人人头衔相同，都叫“技术人员”。要是 Slack 上名字底下写着软件工程师，别人会默认你是写代码的，不会来问你产品问题；人人头衔相同时，默认就变成每个人什么都做，哪怕彼此还不熟，打交道的方式也反了过来。这也合乎实情：一个工程师可能也做点设计、和用户聊、自己写需求，或者兼做研究，大家干的活本来很相近。这等于把乐观写进了组织结构，也可能是各行各业往多面手走的一个预演。