What Happens After Coding Is Solved

I want to start with a spicy question. About six months ago — I don't know if people even remember this — you actually left Anthropic, you joined Cursor, and then two weeks later you went back to Anthropic. What happened there? I don't think I've ever heard the actual story.

先问一个辣的。大概六个月前——不知道大家还记不记得——你其实离开了 Anthropic,加入了 Cursor,然后两周后又回到了 Anthropic。中间到底发生了什么?这个故事我没听过原版。

It's the fastest job change that I've ever had. I joined Cursor because I'm a big fan of the product, and honestly I met the team and I was just really impressed. They're an awesome team. They saw where AI coding was going I think before a lot of people did.

这是我经历过最快的一次跳槽。我去 Cursor 是因为我特别喜欢这个产品,见到团队后真的被震撼了——是个非常优秀的团队,而且他们比很多人更早看清了 AI coding 的方向。

As soon as I got there, what I started to realize is what I really missed about Anthropic was the mission. And that's actually what originally drove me to Anthropic — when you talk to people at Anthropic, just like find someone in the hallway, if you ask them why they're here, the answer is always going to be safety.

但一去 Cursor 我就意识到,我真正想念的是 Anthropic 的使命。这其实也是当年把我吸引到 Anthropic 的东西——你在 Anthropic 的走廊里随便找个人问"你为什么在这里",答案永远是 safety。

No matter how exciting the work might be, even if it's building a really cool product, it's just not really a substitute for that.

不管工作多让人激动,哪怕是做一个非常酷的产品,都没办法替代那种使命感。

There's this report that recently came out by SemiAnalysis that showed that 4% of all GitHub commits are authored by Claude Code now, and they predict that it'll be a fifth of all code commits on GitHub by the end of the year. The way they put it is, "While we blinked, AI consumed all software development."

SemiAnalysis 最近的报告显示,GitHub 上 4% 的 commits 现在是 Claude Code 写的,他们预测年底会到五分之一。他们的原话是:"我们眨了下眼,AI 就把整个软件开发吃掉了。"

These numbers are just totally crazy. 4% of all commits in the world is just way more than I imagined and it still feels like the starting point. These are also just public commits. So we actually think if you look at private repositories, it's quite a bit higher than that.

这些数字真的离谱。"全世界 4% 的 commits"这个量级远远超出我之前的想象,而且这还只是起点。而且这只是公开仓库——如果看私有仓库,实际比例还要更高。

The craziest thing for me isn't even the number that we're at right now, but the pace at which we're growing. Because if you look at Claude Code's growth rate kind of across any metric, it's continuing to accelerate. So it's not just going up — it's going up faster and faster.

对我来说最 crazy 的不是当下这个数字,而是我们的增速。Claude Code 不管你看哪个指标,增长率都在持续加速——不是单纯往上,是越来越快地往上。

When I first started Claude Code, it was just supposed to be a little hack.

我刚开始做 Claude Code 的时候,它只是一个小小的 hack 项目而已。

At Anthropic, we just think in exponentials. If you look at our co-founders, three of them were the first three authors on the scaling laws paper. So if you look at the exponential of the percent of code that was written by Claude at that point, if you just trace the line, it's pretty obvious we're gonna cross 100% by the end of the year, even if it just does not match intuition at all. And so all I did was trace the line.

Anthropic 的思维方式就是"想指数曲线"。我们的联创里三个人就是 scaling laws 论文的前三作。如果你看当时 Claude 写代码占比的指数曲线、把那条线画下去,就能看出来年底跨过 100% 是显然的——哪怕这完全反直觉。我做的所有事就是把那条线画下去。

In November, that happened for me personally and that's been the case since.

11 月,这件事在我身上发生了,从那以后就一直是这样。

For Anthropic for a long time, we were building the models in this way that kind of fit our mental model of the way that we build safe AGI — where the model starts by being really good at coding, then it gets really good at tool use, then it gets really good at computer use. Roughly this is, like, the trajectory.

长期以来,Anthropic 是按一个"如何安全地造 AGI"的心智模型在做模型——先让模型在 coding 上变得非常强,再到 tool use,再到 computer use。大致就是这条轨迹。

When you look at the team that I started on — it was called the Anthropic Labs Team. The team built Claude Code, we built MCP, we built the desktop app. So you can kind of see the seeds of this idea — like, it's coding, then it's tool use, then it's computer use.

我最初加入的那支团队叫 Anthropic Labs Team,做了 Claude Code、做了 MCP、做了桌面应用。这条 thesis 的种子在产品序列里其实看得出来——先 coding、再 tool use、再 computer use。

The reason this matters for Anthropic is because of safety. AI is getting more and more powerful. The thing that's happened in the last year is that for engineers, the AI doesn't just write the code, it's not just a conversation partner, but it actually uses tools. It acts in the world.

为什么这条路径对 Anthropic 重要——是因为 safety。AI 越来越强,过去一年发生的真正变化是:对工程师而言,AI 不只是写代码、不只是聊天伙伴,它真的开始用工具、在世界里行动。

Now with Cowork, we're starting to see the transition for non-technical folks also. For a lot of people that use conversational AI, this might be the first time that they're using a thing that actually acts.

现在有了 Cowork,这条转变正在向非技术人群扩散。对很多原本只用过对话 AI 的人来说,Cowork 可能是他们第一次接触一个真正能"行动"的 AI。

I hear you have these very specific principles that you've codified for your team. I believe one of them is: what's better than doing something? Having Claude do it.

我听说你给团队定了几条很具体的原则。其中一条是:有什么比自己做更好?让 Claude 做。

There's this interesting thing that happens when you underfund everything a little bit, because then people are kind of forced to cloudify. For work where sometimes we just put one engineer on a project, the way that they're able to ship really quickly — because they want to ship quickly, this is intrinsic motivation that comes from within — is just wanting to do a good job. If you have Claude, you can use that to automate a lot of work.

有一个反直觉的现象:当你给所有事都"少配一点资源",人们反而被逼着 cloudify(把活转给 Claude)。我们有时候一个项目只放一个工程师,这种情况下他们能 ship 得非常快,是因为想做好这件事的内驱力是从内部长出来的——而不是被推着干。这时候 Claude 是天然的杠杆。

Another principle is just encouraging people to go faster. So if you can do something today, you should just do it today.

另一条原则是鼓励大家**快**——今天能做的事就今天做。

My advice generally is don't try to optimize, don't try to cost cut at the beginning. Start by just giving engineers as many tokens as possible. We're starting to see this come up as a perk at some companies — if you join, you get unlimited tokens.

我给所有公司 CTO 的通用建议是:**不要先优化、不要先省钱**。先给工程师尽可能多的 token。现在已经看到一些公司把"无限 token"当成入职 perk 在用了。

It makes people free to try these ideas that would have been too crazy. And then if there's an idea that works, then you can figure out how to scale it, and that's the point to optimize and to cost cut — figure out maybe you can do it with Haiku or with Sonnet instead of Opus.

这样做能让人放手去试那些"过去太疯狂"的想法。等里面有想法跑通了,再去考虑规模化和省钱——比如能不能用 Haiku 或 Sonnet 跑这个,而不是 Opus。

At the beginning, you just want to throw a lot of tokens at it and see if the idea works, and give engineers the freedom to do that.

最早期,你要做的就是把 token 拍上去看看想法成不成,给工程师那种自由。

There was sub 1% of the population — it was scribes that did all the writing. They did all the reading. They were employed by lords and kings that often were not literate themselves.

古登堡之前,识字的不到 1% 人口,基本是抄书匠在干所有读和写——他们的雇主常常是不识字的领主和国王。

There was this crazy stat that in the 50 years after the printing press was built, there was more printed material created than in the thousand years before. The volume went way up. The cost went down something like a hundred X over the next 50 years. And literacy went up to like 70% globally over the next 200 years.

有一个夸张的数据:印刷机发明后的 50 年,新印的书比之前 1000 年还多。50 年里成本降了大约 100 倍。识字率在接下来的 200 年里全球升到了 70%。

There was this interesting historical document where there was an interview with some scribe in the 1400s about: "How do you feel about the printing press?" And they were actually very excited because they were like, "Actually, the thing that I don't like doing is copying between books. The thing that I do like doing is drawing the art in books and then doing the book binding. And I'm really glad that now my time is freed up."

有一份非常有意思的史料,是 1400 年代一位抄书匠对"你对印刷机怎么看"的访谈。他其实很兴奋——他说:"我不喜欢做的事是抄写,我喜欢的是给书里画画、装订。我真的很高兴现在那部分时间被解放了。"

As an engineer, I sort of felt like at peril with this — but actually this is sort of how I feel. I don't have to do the tedious work anymore of coding because this has always been the detail of it. The tedious part — messing with Git, using all these different tools — that was not the fun part. The fun part is figuring out what to build, talking to users, thinking about these big systems, thinking about the future, collaborating with people on the team. And that's what I get to do more of now.

作为工程师,我一开始觉得自己处境危险——但其实我现在的感受恰恰就是这位抄书匠的感受。那些繁琐的部分——动 Git、调一堆工具——本来就不是 coding 的乐趣所在。乐趣是想清楚要造什么、和用户聊、想大系统、想未来、和团队协作。这部分我现在反而做得更多。

One is, don't try to box the model in. A lot of people's instinct when they build on a model is they try to make it behave a very particular way — layering very strict workflows on a model, like "you must do step one, then step two, then step three," with this very fancy orchestrator.

第一条:别把模型框死。很多人在模型上层 build 的本能,是把它压成某个非常特定的形状——给它套一层超严格的 workflow,比如"必须先 step 1、再 step 2、再 step 3",还配一个非常 fancy 的 orchestrator。

But almost always, you get better results if you just give the model tools, you give it a goal, and you let it figure it out. A year ago, you actually needed a lot of the scaffolding. But nowadays, you don't really need it.

但几乎所有情况下,**给模型工具 + 一个目标,然后放手让它自己想**,效果都更好。一年前你确实需要大量 scaffolding,但今天大多数情况下不再需要了。

Don't try to over-curate it. Don't try to put it into a box. Don't try to give it a bunch of context upfront. Give it a tool so that it can get the context it needs.

别过度策展。别把它塞进盒子里。别上来就喂一大堆 context。给它一个工具,让它**自己去拿**它需要的 context。

An even more general version of this principle is just the bitter lesson. Rich Sutton had this blog post maybe 10 years ago. His idea was that the more general model will always outperform the more specific model. The biggest one for me is just always bet on the more general model over the long term. Don't try to use tiny models for stuff. Don't try to fine-tune.

更普适的版本就是 Rich Sutton 十年前那篇 The Bitter Lesson:**越通用的模型,长期一定打败越特定的模型**。对我最重要的推论是:长期总是赌更通用的那个模型。别用小模型凑、别 fine-tune。

Scaffolding can improve performance maybe 10–20%. But often, these gains just get wiped out with the next model. So it's almost better to just wait for the next one.

Scaffolding 大概能榨出 10–20% 的提升,但下一代模型一发,这些往往直接被抹平。**很多时候等下一个模型反而更划算**。

From the very beginning, we bet on building for the model six months from now, not for the model of today.

从一开始,我们就把 Claude Code 押在"6 个月后的模型"上,而不是"今天的模型"。

For the very early versions, the model just wrote so little of my code because I didn't trust it. The bet with Claude Code was that at some point the model gets good enough that it can just write a lot of the code. This is a thing that we first started seeing with Opus 4 and Sonnet 4. We just saw this inflection because everyone started to use Claude Code for the first time, and that was kind of when our growth really went exponential.

早期版本,模型给我写的代码非常少,我也不信任它。Claude Code 的赌注就是:某天模型会好到能写大量代码。这件事从 Opus 4 和 Sonnet 4 开始真正发生——所有人第一次开始用 Claude Code,我们的增长曲线就是从那时候起飞为指数的。

This is advice that I give to a lot of folks, especially people building startups. It's going to be uncomfortable because your product market fit won't be very good for the first six months. But if you build for the model six months out, when that model comes out, you're just going to hit the ground running.

这是我给很多创业者的建议:**前 6 个月你的 PMF 会很难看,这是必经的**。但如果你押的是 6 个月后的模型,当它真出现时,你已经在起跑线上准备好了。

For people that are just starting to use Cowork: download the Claude desktop app, go to the Cowork tab, it's right next to the Code tab.

想上手 Cowork 的人,先下载 Claude 桌面 app,打开 Cowork 这一栏,就在 Code tab 旁边。

The thing that I recommend doing is — start by having it use a tool. Like, clean up your desktop, summarize your email, or respond to the top three emails. It actually just responds to emails for me now too.

我推荐的第一步是:先让它用一个工具。比如"整理我的桌面"、"总结一下我邮箱"、"回复一下最重要的三封邮件"。Cowork 现在已经在帮我回邮件了。

The second thing is connect tools. So like, "Look at my top emails and then send Slack messages," or, "Put them in a spreadsheet." For example, I use it for all my project management. We have a single spreadsheet for the whole team. There's a row per engineer where every week everyone fills out a status, and every Monday Cowork just goes through and it messages every engineer on Slack that hasn't filled out their status — and so I don't have to do this anymore. And this is just one prompt. It'll do everything.

第二步是把多个工具连起来。比如"看我邮箱里的重点邮件,然后发到 Slack",或者"塞到电子表格里"。我自己用 Cowork 做团队项目管理:一张全队共用的表,每个工程师一行,每周填周报。每周一 Cowork 自己跑一圈,发 Slack 给那些没填的人催更——这件事我现在已经不用做了。整个流程就一个 prompt 全包。

And then the third thing is just run a bunch of Claudes in parallel so it can co-work. You can have as many tasks running as you want. Start one task, then have it do something else, then something else — and then I just go get a coffee while it runs.

第三步是**并行跑多个 Claude**——这就是所谓的 co-work。任务多少都可以同时挂着。我自己的节奏是:启动一个、再启动一个、再启动一个,然后去喝杯咖啡,回来发现都干完了。

It just feels like this is 1% done and there is so much more to go. Most of the world still does not use Claude Code. Most of the world still does not use AI.

感觉我们才走完 1%,后面还有非常长的路。世界上绝大多数人还没用过 Claude Code,世界上绝大多数人甚至还没用过 AI。

Miso is this interesting thing where it teaches you to think on these long timescales that's just very different than engineering. A batch of white miso takes at least three months to make. A red miso is like two, three, four years. You just have to be very patient. Post-AGI, or if I wasn't at Anthropic, I'd probably be making miso.

做味噌教你用一种和工程完全不同的时间尺度思考。一批白味噌至少三个月,红味噌两到四年,你必须特别耐心。如果哪天到了后 AGI 时代、或者我不在 Anthropic 了,我大概率就去专心做味噌。

Do you have a favorite life motto that you often come back to in work or in life?

你有什么常常回到的人生格言吗?

Use common sense. A lot of the failures that I see, especially in a work environment, is people just failing to use common sense. They follow a process without thinking about it. They just do a thing without thinking about it. Or they're working on a product that's not a good product or not a good idea, and they're just following the momentum and not thinking about it.

用常识(common sense)。我看到的大部分失败,尤其是工作里的,都是人在不思考地走流程、不思考地做事、不思考地跟着惯性把一个其实不好的想法往前推。

The best results that I see are people thinking from first principles and just developing their own common sense. If something smells weird, then it's probably not a good idea.

真正出好结果的人,都是从第一性原理出发,自己长出自己的 common sense 的人。如果一件事闻起来不对,大概率它就不是个好主意。