Boris Cherny：从 Meta 到 Claude Code，用通才思维打造产品

模型发展得太快了。如果你三个月或六个月后再问我这个问题，我的答案会完全不同。这是 Boris Cherny，他是 Claude Code 的创造者，前 Meta 首席工程师。我们聊了塑造他职业生涯的一切。你能解释一下“潜在需求”吗？

The models are moving so quickly. If you ask me this question in 3 months or 6 months, my answer will be totally different. This is Boris Cherny. He's the creator of Claude Code and former Meta principal engineer. And we talked about everything that shaped his career. Can you explain latent demand?

我认为潜在需求是产品中最重要的一个原则。

Latent demand I think is the single most important principle in product.

你说过有一些明显的文化差异，那很困难。

You said that there were some clear cultural differences and that was difficult.

天哪，“困难”这个词太轻描淡写了。那简直是一场噩梦。

Oh my god, difficult is such an understatement. It was a nightmare.

我们还聊了 Claude Code 以及 Anthropic 现在实际的情况。尽管 Anthropic 规模扩大了三倍，但每位工程师的生产力却因为 Claude Code 增长了近 70%。不要为今天的模型构建，要为六个月后的模型构建。我会推荐给所有人的一本技术书籍，它对我作为工程师影响最大的是……你对与 Codex 和 OpenAI 的竞争有什么看法？这是完整的一集。

We also talked about Claude Code and what's actually happening at Anthropic right now. Even though Anthropic has tripled, productivity per engineer has grown like almost 70% because of Claude Code. Don't build for the model of today. Build for the model 6 months from now. The one technical book I would recommend to everyone that has had the greatest impact on me as an engineer is... What are your thoughts on the competition with Codex and OpenAI? Here's the full episode.

我想从你故事的起点开始，你晋升为 Meta 的高级工程师。是什么项目让你获得了晋升，当时你处于什么位置？

I want to start at the beginning of your story with you getting promoted to senior engineer at Meta. What's the story behind the projects that got you promoted and where were you at the time?

如果我没记错的话，那个项目是“聊天与群组”，这是一个旨在让 Messenger 和 Facebook 更紧密联系的项目。实际上，我在 Meta 最初做的几个项目都是关于 Messenger 和 Facebook 的。第一个项目是扎克伯格的一个想法，关于同步 Messenger 聊天和 Facebook 群组。但有好几个这样的项目，都是试图让 Messenger 和 Facebook 更紧密。我认为动机是，当时有一种感觉，这种公共空间的社交产品正在消失，事情正在向聊天和更随意的实时空间转移。所以我们尝试了几个版本的产品，“聊天与群组”是成功的那一个。我记得它大概是第三或第四个版本，我当时在 Facebook 群组团队，但和 Messenger 团队在组织上距离很远。这个想法是当时的 PM Steve 提出的，他觉得我们应该做这个，我抓住了它，说“太好了，我们干吧”。于是我开始动手。很快就有了一些起色，所以我要求增加工程师，有三位工程师加入：Shatambri、Crystal 和 Chaang。他们是第一批加入的工程师，然后我们得到了数据科学和设计支持。最初只在网页上做，后来也扩展到移动端。我们证明了在 Facebook 群组里嵌入聊天是可行的，这种产品能行。但老实说，有很多地方完全不行。按现代产品标准，那体验非常粗糙。过去大家都在网页上开发，各种 bug 完全没问题。现在，视觉标准和质量标准都高多了。产品在增长，我们团队很小，每个人都得做所有事。我记得我们没有用户研究员，所以午餐时我会去食堂，带着新功能给食堂员工看，问他们能不能找到打开聊天的方法。有时他们能找到，有时不能。这就像观察性用户研究，你看人们在特定情境下如何完成任务，不给他们太多提示，看他们在哪里卡住，他们理解了什么。我们这样做，然后我教团队也这么做。很快，我们午餐时都去食堂，找食堂员工当代表用户，问他们这个功能有没有道理。

If I remember right, the project was Chats and Groups, and this was a project to bring Messenger and Facebook a little bit closer together. And I actually the first few projects that I worked on at Meta, it was about Messenger and Facebook. And I think the first one was like Zuckerberg had this idea about syncing Messenger chats and Facebook groups. But there were a few of these projects just trying to bring Messenger and Facebook closer together. And I think the motivation was there was this feeling that this kind of public space social product was disappearing and that things were moving a little bit more into chat and these kind of more casual real-time spaces. And so we tried a few versions of the product and Chats and Groups is the one that worked. I think it was like number three or number four at the time and I was in Facebook Groups or in Facebook at the time and I was working a lot with Messenger that was like organizationally very distant. And this is an idea that I think Steve who was a PM at the time he sort of had this idea this is a thing we should build and I just picked up on that and I was like yeah hell yeah let's do this. And so I started hacking on it. And then pretty soon there were some signs of life. So I asked for more engineers and there were three engineers that joined. There was Shatambri, Crystal, and Chaang. They were the first three engineers that joined this and then we got some data science support, some design support. And it started just on web. Then we also moved to mobile a little bit and yeah, I think we just kind of proved out this idea that you can have chats inside of Facebook groups and this kind of product can work. And there's just like a lot of stuff honestly that didn't work at all about it. It was like a super jank experience I think by modern product standards. Like back in the day everyone was building on web and all sorts of bugs were totally okay. Nowadays, I think the standard honestly like the visual standard, quality standard is a lot higher. And yeah so the product grew and we were such a small team like everyone had to do everything and I remember like we didn't have a user researcher so I would go to the cafeteria during lunch and we would have a new feature and we would show the cafeteria workers the feature and be like hey can you figure out how to open a chat and you know like sometimes they would find it sometimes they wouldn't be able to and this is just like an observational user research study. So you kind of see how people in a particular situation can do a task and you don't prompt them that much. So you don't want to give too much away and you kind of see where they struggle. You see what they get. And so we did this and then I kind of taught the team how to do this. So then pretty soon we would all go to the cafeteria at lunch and start bugging cafeteria workers to you know as just kind of like representative users to be like you know does this make sense or not?

有趣的是，你当时所处的早期 Facebook 文化让工程师能做很多代码之外的事情。比如，你在做用户研究。我记得在你的故事里，你还做了一些设计，并指导别人做设计。我觉得这是 Facebook 文化中非常独特的一点。

It's interesting how the early Facebook culture that you were operating in let engineers do so much outside of just like the code. For instance, you're doing UXR. It sounds like in some of it I remember in your story you did some design as well and you were coaching people to do design. So I think that's pretty interesting unique thing in Facebook's culture.

我认为这非常重要，直到今天，在 Claude Code 团队——也就是我现在所在的团队——我们非常重视通才。我喜欢和通才一起工作。如果你是一个会写代码的工程师，但也能做产品工作，也能做设计，有产品直觉，愿意去和用户交流，我就喜欢和这样的工程师合作。实际上，我们现在招聘所有职能都这样：我们的产品经理写代码，数据科学家写代码，用户研究员也写一点代码。我就喜欢这些通才，这其实是我成长的方式——从 18 岁创办第一家初创公司开始，我就得做所有事情，直到 Facebook，我都在小公司工作，什么都得干。我觉得在大公司，你往往会被迫进入特定的泳道，但这只是表面上的，因为工程到底是什么？它是一套非常狭窄的技能，但实际你是在构建产品或基础设施，端到端地做这件事需要很多除了写代码之外的东西。能在 Facebook 这样当时独特地奖励这种做法的公司工作，真的很酷。实际上，那个半年度结束时我升职了，然后下一个半年度，团队里每个工程师也都升职了。

I think this is so important and I think to this day, you know, on the Claude Code team and this is the team that I'm on right now. We really prioritize generalists. So I love working with generalists. If you're an engineer that codes, but you can also do product work. You can also do design. You have product sense. You go, you want to go talk to your users. Like I love this kind of engineer to work with. And this is actually how we recruit for all functions now. So like our product managers code, our data scientists code, our user researcher codes a little bit. So like I just love these generalists and I think this is really like the way that I grew up like from the beginning when I was running my first startup when I was like 18 I had to do everything and up until Facebook I worked at smaller companies where you had to do everything and I kind of feel like at big companies you get forced into this particular swim lane but it's just sort of official cuz like what is engineering? It's like it's a very narrow skill set, but really the thing that you're doing is you're building product or you're building infra and there's just so much more that goes into doing that end to end besides just writing code. It was just really cool being at a place that I think Facebook uniquely kind of rewarded that at that time. And I think actually at the end of that half I got promoted and then I think the half after every single one of the engineers got promoted too.

在那些早期产品中，你多次提到“潜在需求”这个概念，听起来它是很多产品方向的推动力。你能解释一下潜在需求吗？

In those early products, there was this concept latent demand that you mentioned a few times, which it sounds like was the impetus for a lot of those product directions. Can you explain latent demand?

我认为潜在需求是产品中最重要的一个原则。如果你看看 Facebook 成功的产品，每一个都有潜在需求的元素。比如 Marketplace，它源于一个观察：当时 Facebook 群组里 40% 的帖子都是买卖东西。Facebook 群组并非为商业设计，但人们却用它来做这个。所以很酷的是，你设计产品时，要让它能被“黑”出新的用途。

Latent demand I think is the single most important principle in product and I think if you look at especially at Facebook successful products, every single one has an element of latent demand. So for example, a marketplace, it came from this observation that if you looked at Facebook groups at the time, 40% of the posts were buying and selling stuff. And so Facebook groups were not designed for commerce, but that's what people were using it for. And so it's kind of cool like you design this product in a way that can be hacked.

用户可以稍微滥用一下产品，然后你观察数据，看他们是怎么滥用的，再围绕这个行为构建产品。比如 Facebook 群组出现后，又有了买卖群组，这显然成功了，因为人们本来就想在 Facebook 群组里买卖和交易，所以市场功能就是顺理成章的下一步。这只是人们已有意图的自然延伸。我觉得 Facebook 交友也很类似。当时的观察是，大约 60% 的个人主页浏览来自异性且非好友的用户。所以这种传统的“互相窥探”行为，对 Nate 和当时的 FMS 来说，就是这功能会成功的证据。我认为产品设计的原则是：你永远无法让人们去做他们还没在做的事。你能做的是发现他们已有的意图，然后引导他们更好地利用这个意图，更轻松地达成他们想做的事。

It can be abused by users a little bit, and then you look at the data, you see how they're abusing it, and then you build a product around it. So you know like there was Facebook groups and then there were buy sell groups and then that succeeded obviously because people already wanted to buy and sell and do commerce on Facebook groups and then marketplace was next. It was just a natural extension of the same intent that people had. I think Facebook dating was pretty similar. I think the observation was something like 60% of profile views were people of the opposite gender that were not friends with each other. So you know this kind of like traditional like kind of like creeping on each other and I think for like Nate and like FMS at the time like this was evidence that this would work. And I think the principle in product is you can never get people to do something they do not yet do. The thing you can do is you can find the intent that they have and then you can steer it to let them better capitalize on that intent and kind of do the thing they want more easily.

在你的故事里，你还提到你跨组织工作，因为你负责弥合 Messenger 和许多群组工程工作之间的差距。我很好奇，你说存在明显的文化差异，这很困难。对于在文化迥异的组织之间协作，你有什么建议吗？

I think also at this part of your story, you mentioned that you worked across orgs. You worked because you were bridging the gaps between messenger and a lot of the groups engineering work. I'm curious, you said that there were some clear cultural differences and that was difficult. Do you have any advice for working across very different culture orgs?

天哪，“困难”这个词太轻描淡写了。那简直是噩梦。当时的 Facebook 想要快速发布，我们只想尽快推出优秀的产品。而 Messenger 则完全关注可靠性和性能，那是他们唯一在乎的事。价值观完全相反。这不仅仅是文化问题，也不仅仅是工程师之间的差异。那个团队的工程师对我们心存疑虑，因为我们会影响他们的性能指标。从组织架构上看，他们的组织设计是为了缓慢发布且不降低指标，而我们则被设计成快速发布。目标也完全不同：他们关注服务可用性（SOA）的正常运行时间，而我们只关心日活跃用户数和参与度。所以我的体会是，这些文化价值观非常深层。它不只是人们嘴上说说，而是体现在组织设计、目标设计以及方方面面。老实说，我认为那个项目失败的原因之一——虽然最终它演变成了成功的东西，但那个版本的项目确实失败了——就是因为这种价值观差异。所以我认为，如果想让价值观迥异的公司成功合作，就必须找到某种共同目标、共同兴趣、共同信念，或者一个双方都愿意共同验证的假设，如果成功的话对双方都很有吸引力。而聊天和群组这个功能，从根本上说对 Facebook 很酷，但对 Messenger 来说，出于很多原因就没那么酷了。

Oh my god, difficult is such an understatement. It was a nightmare. Like for Facebook at the time, we wanted to ship like we just wanted to go fast and ship awesome product as fast as we could. And then Messenger was all about reliability and performance. That's all they cared about. It was just polar opposite values. And this isn't just cultural. It's not just like an engineer to engineer thing. It's like the engineers on that team were suspicious of us because we would affect their performance metrics. And organizationally, their org was set up in a way to ship slowly without regressing the metrics and we were set up to ship quickly. So it's like and then the goals were totally different you know like they had SOA up times and for us it was just about daily active users and engagement. So I think for me the takeaway is these kind of cultural values go super deep. It's not just a thing people talk about but you can actually see this in org design and in goal design and in every part of everything. And honestly, I think one of the reasons that project failed was and eventually it evolved actually into something successful, but that version of the project failed was because of this difference in values. So I think that fundamentally if you want to get companies with really different values to succeed and kind of work together, you have to find some kind of shared goal or kind of shared interest, shared belief, some kind of hypothesis that they want to test together that would be really interesting for both of them if it worked. And I think this like chats and groups thing fundamentally was really cool for Facebook, but it's not that cool for Messenger for a lot of reasons.

那么，以你现在的认知，如果回到那个项目，你会做哪些改变？

So, knowing what you know now, how would you change things going back to that kind of project?

我想我可能会直接去找扎克伯格，跟他说：如果你真的认真对待这件事，我们应该把 Messenger 并入 Facebook 的组织架构。实际上后来也确实这么做了，而且反复了好几次——Messenger 先是在组织内，然后移出去，又移进来，再移出去。大公司就是这样。但我觉得，要让这种事情成功，共同的汇报线不能太高，比如共同的经理不能是 Chris Cox 那个级别，而应该低一点。这样你才能把组织构建得更有协作性。

I think I probably would have gone to Zuck and just been like, if you're really serious about this thing, we should move Messenger into the Facebook org. And I think this has since happened and it's actually happened like a few times like Messenger was in the org then it moved out and then it moved in then moved out. It's a big company like this happens. But I think fundamentally for this kind of thing to succeed, the common report can't be, you know, the common manager can't be like Chris Cox. It has to be like a little bit lower down. And so you can structure the orgs to be a little bit more collaborative.

我明白了。就是为了对齐激励，避免那种持续不断的斗争。

I see. To align the incentives so you don't get that kind of constant struggle.

对，完全正确。

Yeah. Exactly.

在你职业生涯的这个阶段，我看到你做了很多有趣的副项目。我很好奇，这些项目产生了怎样的蝴蝶效应？比如，在加入 Meta 之前，你开发了 Undux，一个 React 的状态管理框架。我想知道，这对你的职业生涯有什么影响吗？

At this point in your career, I saw there were a bunch of really interesting side projects that you had and I'm kind of curious like what's the butterfly effect of those kinds of projects? So, for instance, even before you got to meta, you worked on Undux, the state management framework for React. I'm curious like how did that impact your career if at all?

对我来说，副线任务非常重要。我招聘工程师时，这绝对是我看重的一点。我想要有副线任务的人，比如酷炫的周末项目、有趣的副项目，甚至只是热衷于酿康普茶之类的人。你希望员工对主业之外的事物保持好奇和兴趣。他们是全面发展的人，是我喜欢共事的人。对我来说，我的很多成长都来自这些副项目。以 Undux 为例，它的起源是：React 的状态管理其实没必要那么复杂。当时的主流方案是 Flux，后来又有了 Redux，但我就是搞不懂 Redux。我自认为是个普通工程师，做产品开发的，不是那种了不起的系统工程师。对我来说，Redux 有 reducer 之类的概念，更新一点状态就要走一套非常复杂的流程，我完全理解不了。所以我做了一个更简单的方案，看起来能用。我当时在一个非营利组织做志愿者，他们开始用这个方案，工程师们很喜欢。后来我加入 Facebook，发现很多人对 Redux 感到沮丧。内部有一个 Redux 用户群，里面全是问题，大家问的都是我当初问过的那些。你知道，当你作为工程师或产品人员遇到问题时，有时只是你个人的问题，但往往其他人也有同样的问题。培养一种“蜘蛛感应”，判断这个问题是否也可能困扰别人，这很重要。而这个问题显然也困扰着别人。从支持帖子和我的团队使用 Redux 的困难中，我能看出来。所以我在内部推出了 Undux。Undux 还行，算不上多好的产品，但至少比 Redux 好。在 Facebook 时，我其实不知道如何推广它。我就发了个帖子，然后有几个人开始用了。

Yeah, I mean for me side quests are so important and for me like when I hire engineers this is definitely something I look for. I want people with side quests, like cool weekend projects, cool side projects, like even someone that's like, you know, just really into like making kombucha or something. Like you want people that are generally curious and interested in stuff outside of their main work. These are kind of well-rounded people. These are the kinds of people I enjoy working with. I think for me, this is where a lot of my growth came from is working on these kind of side projects. So something like Undux honestly where it came from is React state management is honestly unnecessarily complicated and at the time the state-of-the-art was there was like flux and then there was this other thing called Redux and I just couldn't wrap my head around Redux. I was just you know I consider myself kind of average engineer like I build product. I'm like I'm not one of these like incredible systems engineers. And so for me like Redux at the time I had these concepts of like you know like reducers and this kind of like just like this like very complicated flow you had to go to to just like update a little state and I just couldn't wrap my head around it. So I built a simpler thing that seemed to work. I used that I was volunteering at a nonprofit at the time and they started using it and their engineers liked it. And then when I joined Facebook, I saw a lot of kind of frustration around Redux usage because there was a internal group for people that use Redux and there were all these questions where people were asking the same questions I did. You know, like when you as an engineer or, you know, as a product person are running into a problem, sometimes it's just you. Often it's other people too. And I think it's important to build the spidey sense for like when this problem might be shared by others. And so this is a problem that definitely was shared by others. And I could kind of see this in support posts and by the difficulty my team had using Redux. And so I launched Undux internally and Undux is like it's fine. It's like not that great of a product, but at least it's better than Redux. And at Facebook I didn't actually know how to get adoption. So I kind of posted about it. A few people started to use it.

我记得通知团队的 Jeff Case 是个早期的重度用户，我们为此熬了好几个深夜调试一些棘手的通知相关 bug。我想提高采用率，于是写了个小脚本，抓取报告问题的人群，按团队统计。然后我通过聊天联系每个团队的技术负责人和经理，专门为那个团队安排了一场技术分享。我觉得总共可能做了 20、30、40 场技术分享，持续了几周。

I remember Jeff Case on the notifications team was a big early adopter, and we spent some late nights debugging some gnarly notification-related bugs due to it. I wanted to get more adoption, so I wrote a little script, scraped the group of people reporting issues, and tallied them by team. Then I reached out over chat to the tech lead and manager for every team and scheduled a tech talk just for that team. I think overall I did maybe 20, 30, 40 tech talks over the course of a few weeks.

我记得骑着自行车在 Meta 园区里到处做这些分享。特别有趣，因为大家都很投入，也很兴奋有人关心解决他们真正遇到的问题。有一段时间，它是 Facebook 最流行的状态管理框架，但很快就被 Recoil 和更现代的替代方案取代了。现在则是 Relay 之类的。

I remember biking around the Meta campus doing these talks. It was so fun because people were so engaged and excited that someone cared about solving this problem they really had. At some point, it was the most popular state management framework at Facebook, but it got quickly replaced by Recoil and more modern alternatives. Nowadays it's Relay and things like that.

这种副项目会出现在你的绩效评估里吗，还是说在某种程度上对你有帮助？

Does that kind of side project appear in your performance review, or does it help you in some way?

我觉得它出现在了我的绩效评估里。按 Meta 的标准，这算是锦上添花。它本身并不能让你晋升到下一个级别。但那时我还有很多其他副线任务。实际上，在上一家公司时，我深深迷上了 TypeScript。我们当时在用，但好的资源不多。于是我开始写一本关于它的书，因为我觉得总该有人做这件事。它居然不存在，这太疯狂了。这门语言太棒了，设计好得惊人。它有很多当时其他语言没有的想法——比如条件类型、所有东西的字面量类型、映射类型。这些都是极其疯狂的特性。即使是最硬核的 Haskell 程序员也会印象深刻，但没人写这些东西。所以我全身心投入，写了这本书。它耗费了我大约一年的时间。我不会推荐这么做，但深入研究真的很有趣。

I think it was in my performance review. By Meta standards, it's kind of a cherry on top. It wasn't really something that gets you to the next level in itself. But I had a lot of other side quests around that time too. At some point I got really into TypeScript, actually, at the previous company I was at. We were using it, but there weren't a lot of good resources. So I started writing a book about it because I thought someone should do this. It's crazy it doesn't exist. This language is just magnificent, with really shockingly good design. It has all these ideas that no other language had at the time—things like conditional types, literal types for everything, mapped types. These are absolutely insane features. Even the gnarliest Haskeller would be impressed, but no one was writing about this stuff. So I got super into it and wrote this book. It ate up about a year of my life. Would not recommend it, but it was really fun to go deep on it.

我还创办了当时旧金山最大的 TypeScript 聚会。那是一个很酷的机会，见到了像 Ryan Dahl（Node.js 的创建者）这样的人，以及所有那些著名的 JavaScript 名人。这让我意识到，这些人也只是普通人。每个人都在做很酷的东西，有些在特定时间很酷，但归根结底都是人，任何人都可以做这些事。

I also started what I think was the world's biggest TypeScript meetup at the time in San Francisco. That was a really cool chance to meet people like Ryan Dahl, who created Node.js, and all these famous JavaScript celebrities. It made me realize that all these people are just people. Everyone just builds cool stuff, some of it cool at a particular time, but it's all just people, and anyone can do this stuff.

你后来在 Meta 甚至 Anthropic 的时候，有没有用到 TypeScript 或者那些技术深度？

Did you end up using TypeScript or that technical depth later in your time at Meta, or even at Anthropic?

是的，说来有趣。我以前并不在意编程语言。大约 10 年前，我骑摩托车出了很严重的事故。我摔断了胳膊——两只都断了。我挂着两条吊带。大约一个月没法写代码，而且手还是疼，所以我没法写当时常用的 JavaScript。我不得不拓展学习其他语言，因为它们需要的击键次数更少。我从 CoffeeScript 开始，因为括号更少。我觉得这种语言现在可能都不存在了，没人用了。但这也是我接触 Haskell 和函数式编程的原因，因为你可以用更少的击键做同样的事。这当时就是实实在在的动机。

Yeah, it's funny. I used to not care about languages. Then about 10 years ago, I used to ride a motorcycle and got in a pretty bad accident. I broke my arms—both of them. I had two slings on. I couldn't code for about a month, and my hands still hurt, so I couldn't write JavaScript, which I used to write at the time. I had to branch out and learn other languages because they used fewer keystrokes. I started with CoffeeScript because there were fewer parentheses. I don't think that language even exists anymore; no one uses it. But that's also how I got into Haskell and functional programming, because you could do the same thing with fewer keystrokes. That was literally the motivation at the time.

后来我在 Facebook 之前的一家对冲基金工作，有个同事 Rick 非常喜欢 Scala。我当时不理解 Scala，但他带我入了门，进入了函数式编程的领域。这仍然是我会推荐给所有人的一本技术书，它对我作为工程师的影响最大：《Scala 函数式编程》。你今天可能永远不会用 Scala，但它教给你的思考编程问题的方式，与大多数人在实践或学校里编码的方式截然不同。这太不可思议了。它会彻底改变你编码的方式。对我来说，CoffeeScript、Haskell 等几个关键语言是第一步，然后是 Scala，再然后是 TypeScript。这改变了我的思维方式，因为现在我编码时用类型思考。代码中最重要的是类型签名。这比代码本身更重要。把这个搞对了，代码就会非常干净。所以即使在 Facebook，我主要写 Flow 和 Hack，后来在 Instagram 写 Python，它都非常有帮助。在 Anthropic，我主要写 TypeScript 和 Python，所以相当相关。但我认为更大的教训是：用类型思考。

Then at some point I was working at a hedge fund before Facebook, and I had a coworker Rick who was really into Scala. I didn't understand Scala, but he got me into it and into the functional programming side of things. This is still the one technical book I would recommend to everyone that has had the greatest impact on me as an engineer: Functional Programming in Scala. You're probably never going to use Scala today, but the way it teaches you to think about coding problems is such a change from how most people were coding, either practically or in school. It's incredible. It will completely change the way you code. For me, it was like CoffeeScript, Haskell, a few key languages as a first step, then Scala, then TypeScript. This changed the way I think because now I think in types when I code. The thing that matters most in your code is the type signatures. This is more important than the code itself. Getting this right leads to very clean code. So even at Facebook, where I was writing mostly Flow and Hack, and later at Instagram Python, it was very helpful. Here at Anthropic, I mostly write TypeScript and Python, so it's quite relevant. But I think the bigger lesson is just think in types.

在你职业生涯的这个阶段，你提到自己虽然经验丰富，但入职时级别偏低，是一名中级工程师，而且事后看来你很幸运级别偏低。这背后的想法是什么？

At this point in your career, you mentioned that you came in underleveled as a mid-level engineer even though you had a lot of experience, and you said in hindsight you were lucky to be underleveled. What's the thinking behind that?

就是期望值更低。在大公司，每个级别都有各种期望，比如项目影响力、人员影响力等等。具体标准因公司而异，但很多是关于项目影响力或打勾一堆复选框，所有这些都很花时间。入职时级别偏低给了我探索的空间，只是为了做酷东西而做酷东西。

Just lower expectations. At a big company, there are all these expectations at every level in terms of project impact, people impact, and all that. The specific criteria are different across companies, but a lot of it is about project impact or checking a bunch of checkboxes, and all this takes a lot of time. Coming in underleveled gave me the space to explore and just build cool stuff for the sake of building cool stuff.

我想知道这是否也有助于建立势头。如果你以中级或 E4 级别入职，然后表现非常出色，每个人都说 Boris 太棒了，这与你以预期级别入职并表现良好相比，效果不同。

I wonder if it also helps with building momentum. If you came in as a mid-level or E4 and then you're crushing it, everyone's saying Boris is amazing, as opposed to you came in at your expected level and did good.

确实如此。

Definitely.

我认为会有这样一种效应：当你入职时，真的让所有人惊艳，留下非常强烈的第一印象，这有助于建立良好的声誉，为你未来带来更多信任、更多项目等等。

I think there can be this effect when you come in and you really wow everyone. You have such a strong first impression. I think can be helpful for building a good reputation that gives you more credibility, more projects, and stuff like that in the future.

是的，我完全同意。而且我认为这可能是对任何公司都适用的好建议。很多时候工程师换工作，他们真的很想争取，比如“我想去一家不同的公司，我想升一级之类的”。但实际上，就像你说的，这有很多坏处。

Yeah, I think that's totally true. And I think actually this is probably good advice for any company. Like, I think a lot of times engineers switch jobs and they really push, you know, like "I want to go to a different company and I want like a level plus one or whatever." And actually there's a lot of downsides to that, like you said.

接下来聊聊让你晋升为 Meta 的 Staff 或 E6 的那件事。我很好奇背后的故事——当时你处于什么位置，是什么让你晋升到那个更偏领导层的职位。

Going on to the thing that got you promoted to staff or E6 at Meta, I'm curious the story behind where you were at the time and what got you promoted into more of that leadership position.

当时的情况是，Chats 和 Groups 已经上线并运行着，有一个团队在负责这个。实际上，我在加入 Facebook 之前做过很多 JavaScript，但在 Facebook 我从来没写过 JavaScript，因为全是 PHP。所以我真的很想写 JavaScript。我们有一个 Web 界面。特别是对于 Facebook Groups，很多人用网页版而不是移动端，因为比如做群组管理员之类的，在大电脑上用键盘操作更方便。当时这个网站非常卡顿，是个静态网站，全是 PHP。有一些零散的 JavaScript 片段注入到不同地方，状态不一致等各种问题层出不穷，用户体验很不好。所以我想用 JavaScript 重写它，但当时遭到了很多反对。我认为主要原因是基础设施还没准备好。幸运的是，与此同时 Comet 项目启动了，Comet 是对 facebook.com 桌面版的重新编写。参与的有 Tom Occhino（现在在 Vercel）、Jing Chen 等核心人员。我真的很想参与进去，于是主动联系他们询问如何帮忙，并提出把 Facebook Groups 作为试验田。我没有请示任何人，就直接做了。后来我找到 Facebook Groups 的领导层说：“嘿，Comet 要来了，工作量会很大，我们可以提前准备。” 这相当于为所有人设定标准，并与其他团队建立关系。但我仍然遇到了很多反对，比如“你不能把 20 个工程师放在这个项目上”。经过多次评审和争取，我们最终大概拿到了 12 个工程师，因为这次迁移规模很大，大概需要一年时间。Groups 实际上是 Facebook 中最大的产品面，这有点令人惊讶。迁移最终成功了。除了与这个基础设施团队建立关系（否则我永远不会和他们合作）之外，我觉得很有趣的一点是，我们能够影响 Comet 的方向。这有点奇怪，因为对于一个基础设施项目，产品团队通常无法影响方向，他们更多被视为客户。但在这里，因为我们帮助共同构建，我们构建了很多抽象层，这些抽象层后来被其他基于 Comet 构建的团队使用。举个例子，我记得有一个关于 Relay 突变的问题。比如你发送 API 请求，需要某种一致性。但有一个 bug：假设有一个按钮，你每次按下它，都会发送一个 POST 请求，并且按钮状态会切换。为了获得良好的用户体验，你希望按下按钮后状态立即切换，这意味着需要乐观更新。同时，当网络请求返回时，还需要更新本地缓存以确保一致性。如果你快速连续按按钮，响应可能乱序到达，导致 UI 状态不一致。所以我写了一个系统来排队处理突变，以可靠性为代价换取一致性，这在当时是正确的权衡。最终所有人都用了这个系统，我也是这样认识了 Joseph Savona 和 Relay 团队的其他成员。这真的很有趣。从那时起，无论何时我与工程师合作，我都喜欢看到人们深入一层，去理解底层原理。产品工程师也可以构建基础设施，基础设施工程师也可以去和用户交流。要对技术栈的其他部分保持好奇。

So what was happening was Chats and Groups that was launched and that was going, and there was kind of a team working on this. Um, and I actually had a — I'd done a lot of JavaScript before I joined, but at Facebook, I'd never actually written JavaScript because it was all PHP. And so I really just wanted to write JavaScript. And we had this like web interface. And for Facebook Groups in particular, a lot of people use web as opposed to mobile because, for example, for being a group admin or whatever, it's just easier to do on a big computer with a keyboard and stuff. And at the time the site was really janky. It was like a static site. It was all PHP. There's these little bits of JavaScript that are injected a little bit in different places. There's all sorts of inconsistent state, like all these problems that come out of it. It's just it doesn't feel like a good UX. And so I wanted to rewrite it in JavaScript and I got a lot of pushback from the or at the time. And I think the big reason was that the infra just wasn't really ready for it. Luckily, at the same time, Comet was starting and Comet was like the rewrite of facebook.com on desktop. And this is like Tom Occhino, who's now at Vercel, this was Jing Chen. There's a bunch of these kind of core people that were working on this. And I just really wanted to be involved. So, I reached out and asked how I can help. And I offered Facebook Groups as the guinea pig for it. And I didn't ask anyone. Just kind of just did it. And then later I kind of went to my leadership in Facebook Groups and I was like, "Hey, Comet's coming. It's going to be a bunch of work. We can get ahead of it." Kind of set the standard for everyone, build relationships with these other teams. And I still got a bunch of pushback that was like, "Hey, you know, you can't put 20 engineers on this." And after a bunch of reviews and kind of haggling for engineers, I think we put we got like 12 engineers or something like that because it was a pretty big migration. You know, it's going to take like a year. Groups is the single biggest product surface in all Facebook, which is actually kind of surprising. Um, yeah, and the migration kind of worked and I think something that was pretty fun about it besides just like building relationships and friendships with this infra team I never would have worked with otherwise, which was in itself so rewarding and so fun. Um, I think a lot of it was we got to influence the direction of Comet. And it's kind of weird because for an infra project, a product team often cannot influence the direction. And they're more seen as a customer of it. But what happened here was because we helped co-build it, we built a lot of the abstractions that were then used by other teams that were also building on Comet. Um, and you know, for example, a particular one I remember was like Relay mutations. So like you send API requests and you need some sort of consistency. Um, but there's actually this bug where like let's say there's like a button and you press the button. Every time you press it, you send a POST request. And every time you press the button, it toggles the state of that button. For really nice UX, what you want is as soon as you press the button, the state should toggle, which means you need an optimistic update. But also, when the network request comes back, you need to also update the local cache to make sure it's consistent. And if you're just like mashing that button, what can happen is that the responses come in out of order and you might end up with a different state than what was in the UI. Um and so I wrote a system to kind of queue up mutations. So it was like consistency at the cost of reliability and this was kind of the right trade-off at the time. Um and everyone ended up using this and this is how I met like Joseph Savona and a bunch of the Relay team that was working on the data stores. Um, and it was just really fun. And this is something that since then and before then and you know whenever I work with engineers, I just love when people go a layer deeper and, you know, just try to figure out like what's going on and like just because you're a product engineer doesn't mean you can't build infra. Just because you're an infra engineer doesn't mean you can't go talk to users. Like just be curious about these other parts of the stack.

确实。在你主动出击、提前布局 Comet 或这次大型 JavaScript 重写时，你在文章中提到，提前行动实际上给了你更多控制权，也让你优先获得了机会。那么当你谈到机会时，是不是就是指构建这些对每个使用新平台的人都有影响的基础产品基础设施？

Definitely. And in your agency and getting ahead of Comet or this big JavaScript rewrite. You mentioned in your writing that getting ahead of that actually gave you a lot more control and also dibs on opportunities. So when you talk about opportunities there, is this what you're kind of talking about, like building these fundamental pieces of product infra that are impactful for everyone that's going to take on the new platform?

是的，这是一个例子。另一个不同的例子是，Comet 比之前的版本质量高得多，因为它是单页 Web 应用，感觉更精致。但我们当时还没有完全弄清楚产品端质量到底意味着什么。所以我写了很多笔记来定义它，然后做了很多技术分享，试图向其他团队传授我们关于质量的经验，并开启相关讨论。

Yeah. Yeah, that's an example of it. Um, and then maybe you know like a different kind of example is Comet was a lot higher quality than the thing that came before because it, you know, it's like a single page web app. Um, so it can just feel a lot more polished. But we hadn't yet figured out like what exactly quality means on the product side. And so I wrote a bunch of notes trying to define that and then did a bunch of tech talks trying to just like teach people on other teams like here's what we learned about quality. Um, and just kind of like setting up the conversation about that.

你提到了这次迁移到 Comet 需要大量人力。我很好奇，如果放在今天，有了像 Claude Code 这样的新工具，情况会怎样。假设你现在了解了 Claude Code，并且由你负责为同样的工作做同样的范围评估，你觉得完成那个原本需要 12 个工程师的工作，需要多少人？

You mentioned a big headcount ask for this migration to Comet. I feel like I'd be curious what that would look like today with these new tools like Claude Code, etc. I'd be curious like knowing what you know now about Claude Code and let's say you were in charge of doing that same scoping for that same job. How many engineers do you think it'd take to do that 12 engineer job?

嗯，总的来说，迁移 Facebook Groups 最初是 12 个工程师，但最后可能用了 20 到 30 个工程师，持续了大约两年。所以这其实是一个相当大的项目。

Yeah. So I think overall to move Facebook Groups it started with 12 engineers but I think at the end it was maybe like 20 or 30 engineers or something for about two years. So it turned out to be a pretty big project.

我认为如今可能是五名工程师干六个月，差不多这样。

I think nowadays it would be maybe five engineers for six months, something like that.

所以时间是原来的四分之一，工程师人数也少了三分之一以上或不到三分之一。

So a fourth of the time and more than a third or less than a third of the engineers as well.

是的，因为你可以让每个人同时跑一堆四足机器人，让它运行几个小时，然后它就会返回一个 PR。你再给它一个像 Puppeteer 这样的工具，它就能看到 UI 并进行调整。我觉得基本上就是这样了。从编程的角度看，我们现在所处的世界已经大不相同，因为模型迭代太快了。如果你三个月或六个月后再问我这个问题，我的答案会完全不同。六个月后，答案可能就只是一个工程师了。变化太快，真的很难估算或预测未来会怎样。

Yeah, because you just have everyone running a bunch of quads in parallel, let it cook for a couple hours, and it comes back with a PR. Then you give it something like Puppeteer so it can see the UI and adjust. I think that's pretty much all it would be. The world we're in now is so different from a coding point of view because the models are moving so quickly. If you ask me this question in three or six months, my answer will be totally different. In six months, the answer might be just one engineer. It's moving so fast that it's really hard to estimate or predict how things will change.

在你职业生涯的这个阶段，你提到过一件事——也许是在开玩笑，我不确定。你说：‘这是我学会在 VP 评审中总是提供三个选项的时候，因为 80% 的情况下他们只会选中间那个。’这背后的想法是什么？

At this point in your career, you mentioned something—maybe it was tongue-in-cheek, I'm not sure. You said, 'This was when I learned to always present three options in VP reviews, since 80% of the time they'll just pick the middle option.' What's the thinking behind that?

是的，这很大程度上是开玩笑，但当时在 Meta 可能确实如此。我认为远离一线工作的决策者希望看到你做了尽职调查，找到了正确的选项和权衡，并且完成了工作，但他们也想以某种方式参与决策。所以中间选项是做到这一点的简单方法。这有点开玩笑，因为并非所有领导者都这样。很多领导者会自己做功课，或多或少信任他们的团队。运营方式有很多种。但当时我们有一位相当非技术背景的领导者，这是帮助她做决策的一种方式。

Yeah, this is very much tongue-in-cheek, but maybe it was actually true at Meta at the time. I think decision makers who are far away from the work want to know that you did the due diligence of finding the right options and trade-offs, and that you did the work, but they also want to contribute somehow to the decision. So the middle option is the easy way to do that. It's a little tongue-in-cheek because not all leaders are like this. A lot of leaders do their own work and trust their teams more or less. There are many different ways to operate. But at the time, we had a pretty non-technical leader, and this was a way to help her make decisions.

在你职业生涯的这个阶段，你离高层管理最近。你说过你曾向一位高级总监汇报，并参与了许多大规模的范围讨论。向这么高层的人汇报有什么后续影响？

At this point in your career, you had the most proximity to senior management. You said you were reporting to a senior director at some point and involved in huge scoping conversations. What are the downstream effects of reporting to someone so senior?

是的，我认为这取决于工程师和公司。例如，现在我在 Anthropic，你向哪个级别汇报并不重要。一些最资深的人向直线经理汇报，而许多直线经理本身就是 XCTO 级别。所以实际上无关紧要。我认为这是 Meta 特有的文化观察。有两件事：一是在 Meta，作为工程师，你总是需要找到自己的 scope。有些你自己找，有些你的经理帮你找，或者你的技术主管或周围的人帮你。PSC 流程在 Meta 是出了名的增长导向，所以你不得不不断谈论你的影响力。Scope 是最大的贡献因素——如果你有足够的 scope 并且执行得好，那就是影响力。另一部分是 Meta 没有头衔。即使是最资深的工程师，头衔也只是‘软件工程师’，我真的很喜欢这一点。在 Anthropic，我们更进一步：每个人的头衔都是‘技术职员’，无论你是工程师、PM 还是设计师。我喜欢这样，因为它鼓励你跳出自己的职责范围，去做那些应该做的事情，无论别人对你的期望是什么。我看到无头衔有很多好处，但我也能想象一种情况——也许只适用于大公司——当你跨公司联系某人进行合作时，如果你的头衔是‘总监’，他们就能快速判断该多认真对待你。现在 Anthropic 规模大了一些。你看到这种情况了吗？可能大家都认识你，所以你不怎么遇到。

Yeah, I think it depends on the engineer and the company. For example, now I'm at Anthropic, and it doesn't matter which level you report to. Some of the most senior people report to line managers, and many line managers are like XCTOs. So it actually doesn't matter. I think this is a very Meta-specific cultural observation. There are two things going on. One is that at Meta, as an engineer, you always needed to find scope. Some you find yourself, some your manager helps you find, or your tech lead or the people around you. The PSC process is famously growing at Meta, so you constantly have to talk about your impact. Scope is the biggest contributor—if you have enough scope and execute well, that's impact. The other part is that at Meta, no one had titles. Even the most senior engineers were just 'Software Engineer,' which I really love. At Anthropic, we go even further: everyone's title is 'Member of Technical Staff,' regardless of whether you're an engineer, PM, or designer. I love this because it encourages working outside your lane and doing things that just should be done, regardless of expectations. I see a lot of benefits to no titles, but I could also see a case—maybe only for big companies—where you reach out to someone across the company for collaboration, and if your title said 'Director,' it's a shortcut for them to understand how seriously to take you. Now Anthropic is a bit bigger. Do you see any of that? People probably all know you, so maybe you don't see it as much.

是的，这绝对是缺点。但优点大于缺点，那就是你必须赢得信任。无论你在哪家公司，你都必须赢得它。仅仅因为你以前做过很酷的事情，并不意味着你理应得到尊重——好吧，每个人都值得尊重——但这并不意味着你在新公司新环境中理应拥有权威。即使对于带着经理头衔进来的人，你也必须赢得它。在某些方面，拥有经理头衔反而让赢得信任更难一些。作为个人贡献者，无论如何你都得这么做，而没有头衔会让事情稍微容易一点。

Yeah, I think this is definitely the downside. But the upside outweighs it, which is that you have to earn trust. Regardless of what company you're at, you have to earn it. Just because you did something cool before doesn't mean you deserve respect—well, everyone deserves respect—but it doesn't mean you deserve authority at a new company in a new setting. Even for people coming in with manager titles, you have to earn it. In some ways, having a manager title makes it a little harder to earn that trust. As an IC, you have to do it either way, and the lack of titles makes it a little easier.

在你职业生涯的这个阶段，你越来越像一个技术主管或超级技术主管。你有一些关于为数百名工程师规划工作范围的故事。当有那么多事情要规划，而你只有一个人的时候，你是怎么做到的？

At this point in your career, you were becoming more of a tech lead or uber tech lead. You had stories about scoping out work for hundreds of engineers. How do you do that when there's so much to scope and you're one person?

是的，那段时间简直疯狂。我和 Tina Shutchman 合作了很多，她现在在微软，但当时她是我的经理，之后是 Ephe。当时 Facebook 群组获得了大量投资。我加入时，这个组织大概有 150 到 200 人，到我离开去 Instagram 时，已经发展到 600 到 800 人左右。

Yeah, this was a totally insane time. I worked a lot with Tina Shutchman, who's now at Microsoft, but she was my manager at the time, and then Ephe, who was my manager after. There was a lot more investment going into Facebook Groups at the time. The org was maybe 150 or 200 people when I joined, and by the time I left for Instagram, it was like 600 or 800 people, something like that.

Zach 有一种感觉，认为 Facebook 应用应该完全围绕社区，他希望我们越来越快地实现这一目标。作为高管，你最大的方式就是把合适的人放在决策位置上，并给他们资源。在 Meta 的情况下，就是工程师——你不需要 GPU，你需要工程师来做事。所以我们向 Zach 提出了这个项目，内部叫“社区作为新组织”，他批准了大量人头。我们只需要弄清楚这些人要做什么。对他来说，我理解：如果事情重要，你就投入很多人。事后看来，我会投入少得多的人，因为重要的是解决用户的问题和构建出色的产品。这必须自下而上；你要随着新产品线找到产品市场契合度而慢慢加大投入。你不能一次性做完。我们不得不把所有事情都规划好。有几周我不得不做规划文档，比如“我们要投入 30 个工程师。这里有三个技术方案。我们选这个。”下一个项目：“我们要投入 20 个工程师。这里有三个方案。我们选这个。”就这样一遍又一遍地做，以确保这件事不是完全疯狂的。我们做了一些基础的技术规划，大致将工程师数量与项目匹配。

So there's this feeling from Zach that Facebook app should be all about communities and he just wanted us to go faster and faster to make that a reality. As an executive, your biggest way to do that is to put the right people in charge of decisions and give them resources. In the case of Meta, it's just engineers—you don't need GPUs for this, you need engineers to do stuff. So we pitched this project to Zach, internally called 'Communities as the New Organizations,' and he granted a bunch of headcount. We just had to figure out what these people would do. For him, I get it: if the thing is important, you put a bunch of people on it. In hindsight, I would have put way fewer people on it because what matters is solving people's problems and building awesome product. This has to be bottoms-up; you want to slowly dial up as you find product-market fit for new product lines. You can't do it all at once. We just had to scope out all the stuff. There were weeks where I had to do a scoping doc for, say, 'We're going to put 30 engineers on this. Here are three technical options. We'll pick this one.' Next project: 'We're going to put 20 engineers on this. Here are three options. We'll pick this one.' Just doing this over and over to have some confidence that this thing isn't totally crazy. We did some baseline technical scoping roughly matching the number of engineers to the project.

有一些非常有趣的事情。我记得我们曾试图在数据模型层面合并 Facebook 群组和主页。这是一次非常棘手的迁移——完全完成需要很多年，可能需要数百名工程师，因为你必须合并数据模型、产品层、完整性系统、广告系统——各种东西。当时，Ysef Carver 刚加入，我想是从 Profile 或 Events 来的，他与群组合并以推动这件事。他正在做，但在数据模型决策上遇到了困难。所以我召集了一群人，说：“好吧，整个组织的技术负责人，我们接下来三个小时要像做游戏一样进行架构设计。”我把所有人分成两队，我记得是蓝队和绿队。我们给每个人这个问题：如何合并这些数据模型？这里是需求。每个人有三小时在白板上设计。很酷的是，进去时我们完全不知道怎么做，因为看起来太疯狂了。但出来时，我们有两个 80% 相同的设计。所以很明显我们可以执行什么。存在差异的 20% 让风险非常明显，所以我们可以通过技术预研来提前承担一些风险，但也立即开始执行，因为我们确切知道要做什么。

There was some pretty fun stuff. I remember we were trying to merge Facebook Groups and Pages at some point on the data model side. This was a very gnarly migration—to fully do it would take many years and probably hundreds of engineers because you have to merge across the data model, product layer, integrity systems, ad systems—all sorts of stuff. At the time, Ysef Carver had just joined, I think from either Profile or Events, and he joined forces with Groups to make this happen. He was working on it but struggling with a decision on the data model. So I took a bunch of people and said, 'Alright, the tech leads across the entire org, we're going to spend the next three hours on this day and do this essentially like a game where we get to do architecture.' I split everyone into two teams, I think it was blue team and green team. We gave everyone this problem: how do you merge these data models? Here are the requirements. Everyone had three hours at a whiteboard to come up with a design. What was cool is that going in, we had no idea how to do it because it seemed too crazy. But coming out, we had two designs that were 80% the same. So it was really obvious what we could execute on. The 20% where differences existed made the risk very obvious, so we could front-load a bit of that risk with technical spikes, but also start execution right away because we knew exactly what to do.

是的，当我看到这个时觉得非常有趣——一个所有高级工程师参与的技术设计竞赛，把人们分到不同房间来设计方案。我从没听说过类似的事情。当你提出在组织内进行这个设计竞赛的想法时，人们是兴奋还是觉得这是个疯狂的主意？

Yeah, that was really interesting when I saw that—a technical design competition with all the senior engineers, putting people in separate rooms to come up with designs. I've never heard anything like that. When you proposed that idea for this design competition within the org, were people excited about it or was it kind of a crazy idea?

是的，这有点疯狂。对于这种事情，你只能去做。所以我直接告诉大家：“嘿，我们要做这个。”然后把它放进每个人的日历。这看起来很有趣，你知道？作为工程师，你会想参与。但我认为这种事情有时需要共识，有时你必须行动。在这种情况下，因为路径不清晰，行动很重要。但同时，我不知道如何推进，所以我们必须把大家聚在一起建立共识。作为领导者，你总是在平衡这两件事。

Yeah, it was sort of crazy. With this sort of thing, you just have to kind of do it. So I just told everyone, 'Hey, we're doing this.' Then I put it on everyone's calendar. It just seems fun, you know? As an engineer, you would want to do it. But I think this is the sort of thing where sometimes you need consensus and sometimes you just have to act. In this case, because the path was unclear, it was important to act. But at the same time, I didn't know how to proceed, so we had to get everyone together to build consensus. As a leader, you're always juggling these two things.

在经历了被给予数百名工程师并规划事情之后，你对于需要快速做规划的技术负责人有什么建议吗？有什么对你特别有效的做法？

After that experience of being given hundreds of engineers and scoping things out, do you have any tips for someone who's a tech lead who needs to do quick scoping? Anything that worked well for you?

我认为我看到的最大敌人是人们花太长时间，陷入细节。细节总是无穷无尽。从高层开始。大多数技术规划你可以在 30 分钟内非常粗略地完成。如果你不了解系统，现在你可以用 Claude Code 在代码库中运行，问它涉及哪些系统。它实际上可以为你做这件事。这是另一个完全疯狂的变化——当我做这些事情时，我从未想过 AI 现在能为我做这个，但现在它可以。过去，我最大的建议是：设定时间限制。花大概 30 分钟，最多几个小时。如果你必须深入代码，一定要联系专家，列一个专家清单。和他们所有人谈。向他们展示设计。不要只征求意见——给他们一个初步方案，这样他们就能给你反馈，你也有东西可以讨论。

I think the biggest foe I've seen is people taking too long and getting too into the weeds. There's always an infinite number of details. Just start with a high level. Most technical scoping you can do within 30 minutes very roughly. If you don't know the systems, nowadays you would just use Claude Code to run in the codebase and ask it what all the systems involved are. It can actually do this for you. This is another totally insane change—when I was doing this stuff, I never would have expected that AI could do this for me now, but now it does. In the past, my biggest advice would have been: time-box it. Spend maybe 30 minutes, maybe a couple hours max. If you have to dig through code, definitely reach out to experts and make a list of experts. Talk to all of them. Run the design by them. Don't just ask for input—give them a straw man, because then they can give you feedback and it's something to go off of.

继续你的职业故事，我认为让你晋升到高级员工或 IC7 的是 Facebook 上的公开群组。所以我很好奇你参与其中的故事，以及当时发生的任何有趣的事情。

Continuing with your career story, I think the thing that got you promoted to senior staff or IC7 was public groups on Facebook. So I'm curious about the story behind your involvement in that and anything interesting that happened at that point.

是的。公开群组是这些项目之一，源于让 Facebook 群组更关注社区的规划。我们想做一个非常狭窄的改动，表面上看起来很简单，但底层非常复杂。向没参与的人解释这个很有趣——他们会说：“等等，这就像一行代码的改动。”而我说：“不，不是。”实现起来非常困难。

Yeah. Public groups was one of these projects that came out of the scoping for making Facebook groups more about communities. There was this one very narrow change we wanted to make that seems so simple on the surface, but it was so complex underneath. It's funny explaining this to anyone who wasn't there—they're like, 'Wait, this is like a one-line change.' And I'm like, 'No, it's not.' It was very difficult to pull off.

所以这个改动是，要参与公开的 Facebook 群组，你不再需要先加入。

And so the change was in order to participate in a public Facebook group, you no longer have to join first.

所以你的意思是，你可以直接查看，基本上对所有群组或公开群组都有读取权限？

So you're saying you can just view, like you have read access for all groups essentially, or public groups?

对所有群组都有读取权限，对某些群组甚至还有评论权限。所以你可以不加入就评论。

Read access for all groups, and for some groups even comment access. So you can comment without joining first.

有意思。

Interesting.

而且这件事，你知道，感觉像是一行代码的改动，实际上也确实是一行代码的改动，但所有下游影响都非常棘手。其中一个问题是，在数据模型中，数据库里有一个字段叫“群组成员”，我们为此进行了非常激烈的技术争论：那些在群组里评论的人，算不算群组成员？模型也变了，以前加入 Facebook 群组需要管理员批准，所以相当于有一种信任投票，证明你可以加入这个群组。然后我们切换到新模型后，加入公开群组只需要点击“关注”。我们反复讨论，应该用“加入”还是“关注”？哪个动词更合适？但本质上就是“关注”，因为没有互惠动作。你知道，如果你关注了一个群组，你是成员吗？应该存储在数据库的同一部分吗？我们为此争论了一段时间。我记得当时有一位非常资深的工程师 Bob，他基本上是当时组织里最资深的工程师，他强烈认为不应该用同一个字段，而且他逼我们逼得很紧，尽管迁移工作会非常庞大。我们最终还是做了，因为他实际上是 Facebook 群组的早期工程师之一，所以非常了解，而且他态度很坚决。还有其他一些下游变化，比如审核、新的管理工具，管理员需要处理垃圾信息涌入等问题。我记得当时想，如果任何人都能评论，评论里就会堆满垃圾信息。我很难说服别人。后来我建了一个蒙特卡洛模拟的可视化，展示这个机制如何运作。就是一个非常简单的草稿，比如一条评论进来，有一定概率是好是坏，然后评论实际会怎样。我觉得这很好地说服了诚信团队加入帮忙。当时页面诚信团队介入了，他们帮忙做了评论排名，因为把垃圾评论排到后面是让人们看不到这些评论的主要技术机制。所以让用户参与带来了很多棘手的下游影响。还有我们正在做的数据模型迁移。为了完成这一切，我们不得不组建一个大团队。我们招了一位新总监 Yammen，他招了一批工程师。还有很多内部调动，组织里一些最资深的工程师，比如 Henry、Henry Long、Joe Cham 和其他几位，都在做这个项目，而我和他们同级。我当时是 IC6，他们也是。我记得自己有种冒充者综合征，要指导他们、分配工作，心里知道我们同级，尽管级别是隐藏的。你通过传闻之类知道谁是什么级别。事后看来，我觉得这种冒充者综合征是错位的，因为级别根本不重要——这是我现在的看法。有些非常初级的人能做出惊人成果，有些非常资深的人也可能搞砸。所以级别其实没那么重要。但当时我确实一直在想这件事，很难进入这个角色。最终我做到了。有趣的是，最终让我升到 IC7 的，正是推翻 Bob 的决定，因为他想做那次大迁移。我们做了，但工作量巨大，花了 6 个月到 1 年时间，迁移了成百上千个调用点。技术上，我觉得我们实际上只是在每个调用点加了一个 if-else。我们审计了所有调用点，知道是安全的，但没有改变逻辑。所以我们学到的是，“成员”字段确实适合同时建模关注者和群组成员。这是正确的决定。于是我让做迁移的同一个工程师去撤销它。推他去做是对的，因为他表现出成熟，答应了并且能完成。他技术上上下文最多，所以做得最好。对 Bob 来说，这也让他对我作为技术领导更放心，因为他知道我愿意挑战甚至资深同事的决定。最终这是正确的做法。我们撤销了迁移。虽然也花了很长时间，但最终让所有基于这个信息构建的人都能顺畅工作，不再总是纠结“该用这个字段还是那个字段”。

And this is the thing, you know, it feels like a one-line change, and it actually was a one-line change, but there's all these downstream implications that were so tricky. So one is, you know, in the data model, there's essentially a field in the database that was like 'group member', and we had this really intense technical debate about like, these people that are commenting in a group, are they group members? And the model also changed where before, to join a Facebook group, an admin had to approve you, so there's kind of a vote of confidence that you can be in this group. And then after we switched to this model, where to join a public Facebook group, you just essentially press like 'follow'. And we actually went back and forth, should it be 'join' or 'follow'? Like, what's the right verb to describe this? But it was essentially 'follow', because there's no reciprocal action. You know, if you follow a group, are you a member? Like, should you be stored in that same part of the database? And we just went back and forth on this for a while. And I remember at the time, there was this really senior engineer, Bob. He was kind of the most senior engineer in the org at the time, and he felt very strongly that it should not be the same thing, and he kind of pushed us pretty hard, even though it would be a ton of engineering work to migrate stuff to make it a different thing. And so we did this work, because he was actually one of the early engineers on Facebook Group, so he knew it really well, and he felt pretty strongly. There's a bunch of these other like downstream changes around like moderation and different new like admin tooling that admins would need to handle kind of the influx of spam and things like this. And I remember at the time thinking, like, if anyone can make a comment, the comments are just going to be filled up with spam. And I had a hard time convincing people of this. And so at some point I built this like Monte Carlo like visualization of how this would work. And it was just like this really simple kind of like scratch pad of, you know, like a comment comes in, there's a certain probability of it being good or bad, and then like what actually happens to comments. And I think that actually did a pretty good job of convincing the integrity teams to jump in and help with this. And so at the time, the Pages integrity team jumped in and they helped with a comment ranking, because kind of ranking spam comments lower was the main technical mechanism to make it so people don't see these comments. So there's a bunch of these like pretty gnarly downstream implications of letting people participate. There's also this data model migration that we're doing. And so to do all this, we had to staff a big team to make this happen. And so we hired a new director, Yammen, who hired a bunch of engineers. There's a bunch of internal transfers. So some of the most senior engineers from the org, like there was Henry, Henry Long, Joe Cham, there was a few other engineers, and they were all working on this, and I was the same level as them. I was like an IC6 at the time, and so were they. And I remember just feeling this kind of imposter syndrome of having to kind of direct them and kind of point them at work, knowing kind of in my mind that we're the same level, even though levels are hidden. You kind of know through like rumors and stuff who's what. You know, in hindsight, I think this is sort of like misplaced imposter syndrome, because levels don't matter at all. This is my current view. And you know, some people that are very junior can shoot way higher than that and just give you amazing results. Some people that are very senior can give you terrible results. And so the level actually doesn't matter that much. But at the time, I remember just really thinking about this, and it was just kind of hard to step into this role. And eventually I did it. And it's funny, eventually the thing that got me the promo to IC7 was reversing this decision that Bob did, because he wanted to do this big migration. And we did it. And it was just like, dude, it was so much work. It was like 6 months or a year of work or something, just migrating just hundreds and hundreds and hundreds of call sites to do this correctly. And then technically, I felt like actually what we did is we essentially just added an if-else at every single one of these call sites in the process. We audited all the call sites. So we kind of knew that it was safe, but we didn't actually change the logic. And so actually what we learned is that 'yes, member is the right field to model both followers and group members.' This was the right decision. And so I pushed the same engineer that did this to then undo it. It was the right thing to push this engineer, because it showed maturity on his part that he said yes and was able to do it. He also had the most context technically, so he could do it the best. And I think for Bob, it made him feel better about me as a technical leader, because he knew that I was willing to push back on decisions that even senior folks make. And in the end, this was the right thing. So we reversed the migration. It also took a long time to do it, but in the end it made it so everyone building on this info could do it, and everyone wasn't always constantly bumping into this like 'should I use this field or this field?'

嗯，我对这部分很好奇，因为你当时和 Bob 或那位资深技术领导有强烈的技术分歧。但最终结果似乎反而加强了关系。他在你的晋升中成了支持者。所以我想问，你建议如何处理强烈的技术分歧，同时不损害关系？

Yeah, I'm curious about that part because you had a strong technical disagreement with Bob or senior TL. But the outcome at the end is actually it seems like it strengthened the relationship. He was a champion for you in your promotion. So, I'm curious, how would you recommend going about strong technical disagreement in a way that doesn't hurt the relationship?

我认为最重要的是你得赢得信任。你必须赢得信任，这可以很简单，就像我一开始做的：先表示异议但承诺执行，表明我愿意这样做，如果别人认为这是个好主意，而且我尊重他们，我就愿意执行。但你也得展示你有良好的技术判断力。不过在你赢得信任之前，你无法真正展示这一点。所以先花时间赢得信任。

I think the biggest thing is you have to earn it. You just have to earn trust, and it could be as simple as, you know, like what I did at the beginning, which is just disagreeing and committing and showing that I'm willing to do that and I'm willing to just execute if someone else thinks it's a good idea and I kind of look up to them. But also you have to kind of show that you have good technical judgment. But you can't really do that until you earn trust. So take the time to get that trust first.

然后关于冒充者综合征，领导那些同样很强的工程师。你有什么克服冒充者综合征的建议吗？

And then on the imposter syndrome, leading those engineers that were also very strong. Do you have any advice for overcoming imposter syndrome?

有，别想太多。

Yeah, just don't overthink it.

其实，无论处于哪个级别，没有人真正知道自己在做什么。没人知道。我们都在摸索。

You know, no one really knows what they're doing at any level. No one really knows. We're all just trying to figure it out.

说起来容易做起来难。有没有某个顿悟时刻，让你觉得“也许我能行”或“这没什么大不了”？

That's easier said than done. Was there an aha moment where you realized maybe I do got this or this isn't that big of a deal?

我不这么认为。没有某个单一时刻。这种感觉是慢慢消失的。而且我认为，无论你处于哪个级别，都应该有一点冒名顶替综合征，因为如果没有，说明你对自己要求还不够高。

I don't think so really. There wasn't a single moment. It just goes away over time. And I think at every level, it doesn't matter what level you're at, you should always feel a little bit of imposter syndrome because if you don't, then you're not pushing yourself hard enough.

在你职业生涯的这个阶段，你越来越像技术负责人，因此写代码越来越少。你提到，尤其是在 Meta，有时其他职能人手不足，你认为这对工程师来说是一个机会，可以更有产品思维，并帮助填补 PM 的机会。我很好奇，什么时候应该朝这个方向走，而不是升级问题说“我们需要更多 PM 支持”，然后尝试写更多代码？

At this point in your career, you were more and more of a tech lead and therefore you were writing less and less code. You mentioned that at Meta especially, there are cases where other functions are understaffed and you view that as an opportunity for engineers to be more product-minded and help out with PM opportunities. I'm curious, when would you say you should go that direction as opposed to escalating and saying we need more PM support and trying to write more code instead?

是的，你必须理解权衡。我认为这是很多人在推动事情时没有真正理解的一点。一个非常常见的失败模式是：工程师推动一个想法，然后当没有人认同或愿意投入资源时感到沮丧，或者组织根本不听，领导也不听。但你要做的是理解权衡。无论你想说服谁，都要从他们的角度思考：他们在乎什么？他们在做什么项目？这个权衡是针对什么的？如果他们做了这件事，他们会认为自己的工作成功吗？所以我认为这非常重要。对于某些组织，有时他们可能没有 PM，因为项目不够吸引人，很难招到人，也许领导已经感受到了这种痛苦。对于另一些组织，他们可能正在招聘 PM，但那些 PM 应该去更重要的项目。还有一些组织，PM 可能太多了。所以如果你提出要求，那是正确的做法，因为他们可以把一个不太重要项目上的 PM 调到你的项目上，因为你的项目更重要。所以我认为，具备情境意识、了解你所处的环境以及决策者的想法非常重要。

Yeah, you have to understand the trade-offs. I think this is the thing that a lot of people don't really get when they push for stuff. A very common failure mode is an engineer will push for an idea and then get frustrated when no one else buys into it or wants to fund it, or the organization just doesn't listen or their leader doesn't listen. But what you have to do is understand the trade-offs. And whoever it is that you're trying to convince, think of it from their point of view. What do they care about? What are the projects they're working on? What is this trade-off against? If they do this thing, are they going to see their work as a success? So I think that's really important. And for some orgs, at some times they might not have PMs because it might just not be a very sexy project and so it might be really hard to hire, and maybe the leader is already feeling that pain. Maybe for some orgs, they are trying to hire PMs but there are actually much more important things those PMs should go to. For other orgs, they might actually have too many PMs. And so if you ask, that's the right thing to do, because they could just take a PM off a less important project and put on your project because it's more important. So I think it's really important to be situationally aware, understand the context you're in, and understand how your decision makers think about it.

到这里，差不多是你故事第一部分的结尾。你把很多成功归功于“支线任务”和这些副项目，或者你所谓的“20% 时间想法”的持续清单。我很好奇，你有什么建议帮助工程师找到机会吗？

At this point, this is kind of the end of part one of your story. You credit a lot of your success to the side quests and having these side projects or a running list of what you called 20% time ideas. I'm curious, do you have any tips on how to find opportunities for engineers?

是的，我想当时大概有 5000 名工程师在从事我规划并衍生出来的各种支线任务。所以几乎每周，我都会想到某个项目——比如在跑步时或写代码时——我会做一些基本验证，然后联系我认识的工程师，问“嘿，你对这个感兴趣吗？”然后我会把他们和另外几个可能感兴趣的工程师联系起来。这样积累得很快。对我来说，思考工作的一种方式是：我怎样才能做得更少？作为工程师，我们实现这一点的超能力是自动化。最繁琐的事情你可以自动化。这对其他领域来说很难，但对我们来说，这是我们可以做到的不可思议的事情。很多工程师出于各种原因并没有这样做，但我们应该一直这样做。这非常重要。这是杠杆，是免费的杠杆。所以我经常做的一件事是：每次做代码审查时，如果我对某个特定问题（比如风格问题）发表评论，我会用一个电子表格记录这个问题，并附上拉取请求的链接。每次代码审查都这样做。当我对同一类问题评论超过几次时，我就会写一个 lint 规则来自动化它。这就是杠杆的一个例子。到后来，我自动化了大部分代码审查，因为我有一堆 lint 规则在替我完成所有工作。我认为这其实很相似，因为所有这些支线任务都在改进生产基础设施和开发基础设施。而这些正是拖慢我日常编码的事情。这就是为什么当我做西海岸编码时，这实际上非常危险，因为作为工程师，你需要扎根于现实。你需要那种直觉，如果你不再写代码，你会很快失去它。那是一个非常危险的状态。所以对我来说，当我大量写代码时，从中涌现出很多很酷的想法，这些想法不仅对我自己，而且对整个边缘团队都产生了杠杆作用，因为原则是：如果你遇到一个问题，很可能其他人也有同样的问题。我以前参加过 YC，YC 教你的第一件事就是先为自己构建。你必须构建很棒的东西，构建人们喜欢的东西。但如果你想找到一个市场去构建，就从为自己构建开始。这是一个很好的指标，表明其他人可能也有同样的问题。

Yeah, I think at some point there were probably 5000 engineers or something like that just working on these side quests that I scoped out and spun out of various points. So pretty much every week I'll think of some project, just like on a run or while I'm coding, I'll do some basic validation and then I'll ping an engineer that I know and be like, 'Yo, are you interested in this?' And then I'll connect them with a couple other engineers that might be interested. And this kind of added up very quickly. I think for me, one way that I really think about my work is how can I do less of it? And as an engineer, our superpower to do this is automation. The most tedious stuff you can automate. And this is something that's really hard for other fields, but for us it's this incredible thing that we can do. And it's something a lot of engineers don't really do for whatever reason, but we should all be doing it all the time. It's so important. It's leverage. It's like free leverage. And so a thing I often did was every time I did a code review, if I was commenting about a particular kind of issue, maybe like a stylistic issue, I literally had a spreadsheet where I would tally up that issue and I posted the link to that pull request, and then I would do this for every code review. When I commented about the same kind of thing more than a few times, I would just write a lint rule for it to automate that. So this is an example of leverage. And at some point I automated most of my code reviews because I had a flock of lint rules that were just doing all this work for me. And I think this is actually kind of similar because all these side quests were improving prod infra and dev infra. And these are things that slowed me down in my day-to-day coding. And this is why when I was doing west coding, this was actually very dangerous because as an engineer you need to be anchored to reality. You need that intuition, and if you're not in the code anymore then you lose it very quickly. It's a very dangerous place to be in. And so for me, when I was in the code a lot, there were all these really cool ideas that came out of it, and it was leveraged not just for me but for the whole edge team because of this principle: if you have a problem, probably other people have it too. And I did YC back in the day, and in YC they teach you that first you build for yourself. You have to build awesome stuff. You have to build stuff people love. But if you're trying to find a market to build for, you start by building for yourself. And that's a pretty good indicator other people probably have that same problem.

是的。你写过一句话，我觉得非常好。你说“更好的工程能力是工程师扩展人脉和获得影响力的最简单方式”。所以我完全能理解，你的影响力范围远远超出了你写的代码，因为你把所有这些好主意传递给人们并指导他们。这种杠杆作用真的不可思议。

Yeah. There was a quote that you wrote that I thought was really good. You said 'Better engineering is the easiest way to grow your network and gain influence as an engineer.' So I could totally see your scope of influence was so much further than just the code you're writing because you're passing people all these great ideas and overseeing them. The leverage is really insane.

当然。是的。这也是情境意识的一个例子，因为在当时的 Meta，工程师在绩效周期中接受评估。我们看项目影响、人员，你还记得其他吗？方向和边缘卓越。边缘卓越是很多工程师感到困难的地方。所以我就是那种过来说“嘿，如果你想做边缘卓越，这里有个项目”的人。而人们本来就有动力去做，所以他们把它视为一个机会。我想这就是……我也说不清。

Absolutely. Yeah. And it's also just an example of being contextually aware, because at Meta at the time, engineers were evaluated in the performance cycle. We looked at project impact, people, do you remember the other? Direction and edge excellence. And edge excellence is a thing that a lot of engineers struggled with. And so I was one of the people that came along and was like, 'Hey, if you want to do edge excellence, here's a project.' And people are already incentivized to do it. So they see it as an opportunity. And I think this is just like, I don't know.

我认为这是一个磨练我与人合作技巧的机会，你永远不要在任何情况下告诉任何人该做什么。在个人场合、工作场合，每个人都讨厌被指挥。但如果你了解一个人想要什么，你就可以带着真正的机会去找对的人，他们会把它视为机遇。这对每个人都更有效。当我想到这些 20% 时间创意时，有漏斗顶部——发现创意，然后实际执行——让某人去做，无论是你自己还是别人。我感兴趣的是漏斗顶部，比如作为一名工程师，你如何为这些有影响力的副线项目找到这么多创意？

I think it was a chance for me to kind of hone my skills about working with people where you never ever want to tell anyone what to do in any context. In a personal context, in a work context, everyone hates being told what to do. But if you understand what a person wants, then you can go to the right person with a real opportunity and they see it as an opportunity. And this just always works better for everyone. When I think about these 20% time ideas, there's the top of funnel, finding the ideas, and then there's actually executing on them, getting someone to do it or whether it's yourself or someone else. The thing I'm interested is the top of funnel, like how do you source so many ideas as an engineer for these side quests that are impactful?

就是常识吧。我不知道。也许是蜘蛛感应。我不知道合适的词。比如怎么做的？有什么具体例子吗？

Just common sense. I don't know. Maybe spidey sense. I don't know the right word. Like how so? What's a concrete example?

是的，一个非常具体的例子是 lint 规则。另一个例子是，我们有很多 SEV（严重事件），因为 Facebook 群组没有用非常大的数据集进行测试。所以，比如，这有点像 Facebook 的说法——数据库中的行。你可以想象一个拥有 1000 万成员的 Facebook 群组。从来没人测试过这个。没有针对它的单元测试。你只在生产环境中看到它。当我审视整个组织时，我开始看到类似的案例。例如，如果你有一个拥有 2000 万粉丝的个人主页，很多东西都会出问题。但显然没有人以自动化方式测试这个，因为用这么多数据写单元测试很烦人。所以有很多这样的实例。然后我向一位工程师提议，让他构建一种为大数据集编写单元测试的方法。你知道，一个非常大的对象，比如有很多成员的群组、有很多粉丝的个人主页、有很多参与者的活动。我认为这个基础设施仍然存在。它防止了很多问题。这是一个你可以界定范围的事情，然后他带了一群其他工程师来做这项工作并帮助他。所以我想，只要思考你每天实际遇到的问题就行。

Yeah, a really concrete example is lint rules. Maybe another one is there were all these cases where we had SEVs because Facebook groups were not being tested with very large sets of rows. So, for example, this is kind of a Facebook way of saying rows in a database. So you could imagine a Facebook group with 10 million members. No one's ever tested this. There's no unit test for this. You only see it in production. And when I looked across the org, I started seeing similar cases. For example, if you have a profile with 20 million followers, a lot of stuff breaks. But obviously no one tests this in an automated way just because it's kind of annoying to write a unit test with this much data. So there are a bunch of instances of this. And then I pitched an engineer to build a way to write unit tests for large data sets. So you know, a really big object like a group with a lot of members, a profile with a lot of followers, an event with a lot of attendees. And I think this infra still exists. And it prevents a lot of issues. This is something where you can scope it, and then he brought in a bunch of other engineers to do the work and help him out. So I guess just think about the problems that you actually hit day-to-day.

明白了。好的。所以思考问题，如果你反复遇到同一个问题，那就是时候自动化了，这是一个很好的工程项目。

Got it. Okay. So think about the problems and if you're experiencing that problem repeatedly then it's time for automation and that's a great engineering project.

是的。完全正确。就像如果你遇到同一个问题两三次，你应该环顾四周，看看其他人是否也遇到了那个问题。

Yeah. Exactly. Exactly. Like if you hit the same problem two or three times, you should probably look around and see if other people are hitting that problem too.

你在 Meta 职业生涯的最后一段，你获得了 E8 晋升。我知道你换了组织。所以，你在 Facebook 群组完成了所有成长，然后你转到了 Instagram。我很好奇，你转到 Instagram 组织背后的故事是什么？

The last leg of your career at Meta, this is where you got the E8 promo. I know that you moved orgs. So, you did all of your growth in Facebook groups and then you moved to Instagram. I'm curious, what's the story behind you moving orgs to Instagram?

当时，我和我妻子还在约会。她住在伯克利，我住在旧金山。某个时候，她说：‘我找到了梦想中的工作。’我说：‘太好了，真棒。’然后她说：‘我们得搬家了。’我说：‘好的，没问题。’我们当时才约会了三个月左右，正在决定是否要继续交往。所以她说：‘是的，如果你想继续约会，我们就得搬家。’我说：‘好的，我愿意。我们搬吧。’然后那份工作最终是在日本乡下，一个偏僻的地方。我试图想办法解决，因为我真的很喜欢我当时的工作。所以我先和 Facebook 群组的领导层谈了，试图为 Facebook 群组设立一个日本分部。但由于一些组织规则，这没有成功。然后我尝试和 VR 组织合作，实际上进展顺利，但后来赞助这件事的人离职了，去了 YouTube 还是什么地方。那时，Will Bailey 联系了我，他在 Instagram 东京办公室，是 Instagram 落地团队的一员。他说：‘嘿，我想扩大这个办公室。你想加入吗？’我说：‘好，我们干吧。’我什么都不知道。我当时甚至没有安装 Instagram，这辈子从没用过。所以我答应了，然后立刻下载了 Instagram，接着我大概下周就搬过去了。实际上，我在美国待了几周。但我很快就搬出去了。我真的很喜欢 Instagram 的文化。它和 Facebook 的文化非常不同。非常强调打造出色的产品，发布人们不用的功能，不仅从数据角度思考，还从人性和体验角度思考。你可以在应用和其中的工艺中看到这一点。两家公司的工程、产品和设计文化完全不同。所以我在那个团队学到了很多，那是一段非常有趣的旅程。

At the time, I was dating my wife and we were still dating. And she was living in Berkeley, I was living in SF. And at some point, she said, 'I found my dream job.' And I was like, 'Sweet, awesome.' And then she said, 'We're gonna have to move.' And I was like, 'Okay, great.' We had been dating like three months at the time and we were kind of deciding whether we should keep dating. And so she said, 'Yeah, we would have to move if you want to keep dating.' And I was like, 'Yeah, okay, I do. Let's do it.' And then the job ended up being in rural Japan, like middle of nowhere. And I was trying to figure out how to do it because I really liked the work that I was doing. So first I talked to Facebook groups leadership and tried to set up a Japan outpost for Facebook groups. That didn't really work for a bunch of organizational rules. Then I tried to do this with the VR org and it was actually working, but then the person that was sponsoring it left to go to, I think, YouTube or something. And then at the time, Will Bailey reached out and he was in the Instagram Tokyo office. He was part of this landing team for Instagram and he said, 'Hey, I kind of want to grow this office. Do you want to be part of that?' And I was like, 'Yeah, let's do it.' And I didn't know anything. I didn't even have Instagram installed at the time. I'd never used it in my life. And so I said yes and then I immediately downloaded Instagram and then I moved, I think, like the next week or something. Actually, I think it was a few weeks that I had in the US. But I moved out pretty quickly. And I actually really fell in love with the Instagram culture. It was very different than Facebook culture. Big emphasis on building awesome products, on shipping stuff that people don't use, on thinking about things not just from a data point of view, but also from a human point of view and an experience point of view. And you can see this in the app and in the craft that goes into it. It's just completely different engineering and product and design cultures between the two companies. So I learned so much being on that team and that was such a fun journey.

你提到了“取消发布”的部分。那是什么？

You mentioned the unshipped part. What is that?

“取消发布”是指，如果你只是给应用添加功能，这对一小部分用户来说很酷，但实际上对大多数不使用该功能的用户来说是不好的。所以你可以想象一个只添加功能的应用。随着时间的推移，功能会累积起来。如果每个功能只有大约 10% 的人使用，那么普通用户会看到一堆他们不用的功能。所以看起来杂乱且令人困惑。当他们打开应用时，不知道该怎么办。从根本上说，软件的屏幕尺寸是有限的。那是有限的资源。所有不同的功能都在争夺这个有限的资源。所以添加一个功能，你就剥夺了用户可能使用的另一个功能的机会。因此，“取消发布”是指你必须达到某种使用门槛，如果一个功能没有达到这个门槛，我们就删除它。一小部分用户会生气，但这实际上对大多数用户有好处。平均而言，这对每个人都有好处。

Unshipping is the idea that if you just add features to an app, it's cool for some small percent of users, but it's actually bad for most users that don't use the feature. So you can think of an app where you only add features to it. Over time, the features accumulate and they add up. And if every feature is used by like 10% of people, the average user sees a bunch of features that they don't use. So it seems cluttered and confusing. And when they open the app, they don't know what to do. With software, fundamentally the screen is a limited size. That's the limited real estate. It's a limited resource that all the different features are competing for. So by adding a feature, you're taking the opportunity away from a different feature the person could have used. And so unshipping is the idea that you have to meet some sort of usage bar, and if a feature doesn't meet that bar, then we just delete the feature. A small percent of users are going to be pissed, but it's actually great for the majority of users. And on average, it's really great for everyone.

而且我认为，当你在现有组织中是资深的 tech lead，拥有大量信誉时，更容易把事情做成或至少影响他人，因为他们会说：“哦，我认识 Boris，我知道他过去的工作。”但我很好奇，当你在 Instagram 时，离其他人那么远，你是如何建立信誉的？

And I think when you're such a senior tech lead with a lot of credibility in your existing org, it's much easier to get things done or at least influence others because they say, "Oh, I know Boris and I know his past work." But I'm curious, how did you build up credibility at Instagram when you were so far away from everyone else?

我认为早期的很多功劳要归功于像 Nam Guian 这样的人——他至今仍是 Instagram 的工程副总裁——还有 Jeff Hang，他当时是我的总监，现在已是副总裁。这些人帮我建立了很多联系。比如，Nam 说：“嘿，你真的很喜欢做代码质量和技术债务削减这类工作，我们在 Meta 称之为‘更好的工程’。”然后他把我介绍给做这方面工作的人，比如 Lucas Camera、Gabe 和其他一些人。这些联系非常有用。然后我认为很大一部分是我必须重新赢得信任。老实说，这是一件健康的事情。Meta 工程文化中很棒的一点是，没有头衔。你必须不断地重新赢得信任。即使我过去是一名优秀的工程师，我在 Instagram 也不一定优秀。如果我不优秀，那我就不配拥有影响力，不配拥有人们倾听的响亮声音。所以我必须和其他人一样去赢得它。最初的几周，我花了很多时间与人见面，梳理组织架构，明确目标，并写大量代码来熟悉代码库。但在日本就完全不同了，因为东京时间下午 4 点相当于纽约时间早上 9 点——几乎没有时区重叠。

I think a lot of the credit early on goes to people like Nam, who was Nam Guian—he's still the VP of Engineering at Instagram—and Jeff Hang, who was my director at the time but is now a VP. There were a lot of connections made by these people. For example, Nam said, "Hey, you really like working on code quality and tech debt reduction, which we call 'better engineering' at Meta," and he connected me with the people working on it, like Lucas Camera, Gabe, and a bunch of other folks. Those connections were really useful. Then I think a lot of it was I just had to earn the trust again. Honestly, this is a healthy thing to do. One of the really awesome things about Meta's engineering culture is that there are no titles. You have to constantly re-earn your trust. Even if I was a great engineer in the past, I may not have been a great engineer at Instagram. If I wasn't, then I don't deserve influence. I don't deserve to have a really loud voice that people listen to. So I had to earn it along with everyone else. My first few weeks I spent a lot of time meeting people, mapping out the org, mapping out goals, and writing a lot of code to get to know the codebase. But then in Japan it was totally different because 4:00 PM Tokyo time was like 9:00 AM New York time—there was just no time zone overlap.

那很艰难。

It was rough.

是的。但这也很好，因为在之前的几年里，我开了太多会、写了太多文档，就是不写代码。我开始感到很不开心，因为作为工程师，我们写代码——这就是我们的工作。这是我们选择这份工作的原因。对我来说，当我写代码时，我与代码有一种情感联系。当我深入一个问题时，我会思考它；我会梦到它。所以写代码对我来说非常重要。当我有好几年不写代码时，感觉有点糟糕，我想我开始有点倦怠了。实际上，身处这个时区是一种礼物，因为我根本无法开会——人们要么没醒，要么不想为了聊天而开晚上 9 点的会。所以我不再做任何一对一的会议。这至今仍是我坚持的习惯——我仍然不做任何固定的一对一会议。我可以花大量时间写代码。我意识到，当时在 Instagram，我是少数几个写这么多代码的工程师之一。人们也写代码，但不会写那么多，因为有很多事情占用了时间——会议、文档，以及其他各种义务。我能够做很多其他人想做但没有时间做的事情。这在那个组织里算是一种超能力。很早的时候，Nam 把我介绍给了 Joel Pamer，他至今仍是好朋友和导师，现在在 Google。我们开始讨论当时代码库是用 Python 写的，由于很多原因，情况有点糟糕。实际上，代码库应该迁移到 Hack——那是 Facebook 的主要单体仓库，所有语言支持都在那里。基础设施非常强大；HHVM 是一个绝对出色的 Web 服务栈，在效率方面无与伦比。如果你使用 GraphQL，你绝对要用它，因为它对此做了高度优化。Instagram 完全没有使用这些，工程团队因此很痛苦。在早期，比如 Mikey 在 Instagram 的时候，基本决策原则是“做简单有效的事”。这非常有效，但到了某个节点，当代码库有上千甚至两千名工程师在开发，并且积累了多年的技术债务和层层叠加的产品时，你就必须做出与开始时略有不同的决策。所以即使 Python 在开始时绝对是正确的选择，但到了我在的时候，它已经不再正确了。作为工程师，这一点显而易见，我想很多其他人也看到了，但阻止他们的是迁移所需的工作量。所以我开始评估范围，弄清楚需要做什么。我首先找到了那些会反对的人。有一些老员工认为这是个糟糕的主意，永远行不通。我先去和他们聊，比如在纽约一起吃饭，喝点啤酒，在讨论技术问题之前先了解他们这个人。你必须建立信任。所以我必须先了解他们这个人，这非常有价值——这些人至今仍是我很多的朋友。建立信任后，我还发现其实有很多人想做这件事，但有点不敢说出来。所以这些人也纷纷冒了出来。最终我们开始规划，这个项目就逐渐成型了。实际上它至今仍在进行，有很多工程师在参与。有趣的是，在 Facebook，我认为这类问题很少发生，因为组织是工程驱动的。而在 Instagram，这类问题很多，因为组织是产品驱动的。没有太多时间留给那些工程驱动的倡议。

Yeah. But it was also great because in the few years before, I was doing so many meetings and docs and all that stuff, I just wasn't coding. I started to feel pretty unhappy because as an engineer, we code—that's what we do. That's the reason we pick this job. For me, when I write code, I have an emotional relationship with the code. It's something I think about when I'm really deep in a problem; I dream about it. So it's just so important for me to code. When I wasn't doing this for years, it was sort of rough, and I think I was starting to burn out a bit. Actually, it was a gift to be in this time zone where I literally couldn't do meetings because people weren't awake or didn't want to do 9:00 PM meetings just to talk. So I didn't do any more one-on-ones. This is still something I don't do—I still don't do any standing one-on-ones. I just could spend a lot of time coding. What I realized was I was one of a few engineers at Instagram at the time that was coding this much. People code, but people don't code that much because there's all this stuff that fills up your time—meetings, docs, and all these other obligations. I was able to do a lot of stuff that I think everyone else wanted to do but just didn't have time. This was kind of a superpower in that org. Pretty early on, Nam connected me with Joel Pamer, who's still a good friend and mentor, and he's at Google now. We just started talking about how at the time the codebase was written in Python, and it was sort of rough for a lot of different reasons. Really, the codebase should have been moved over to Hack, which is the main Facebook monolith—that's where all the language support is. There's so much infra; HHVM is just an absolutely phenomenal web serving stack. There's nothing else like it in terms of efficiency. If you're using GraphQL, you absolutely have to use it because it's just so optimized for this stuff. Instagram just wasn't using any of this, and engineering was suffering. In the really early days, like when Mikey was at Instagram, really basic decisions were made on the principle of "do the simple thing that works." This worked really well, but at some point it stopped working once you get to like a thousand engineers, 2,000 engineers working on the codebase, and many years of tech debt and products built on top of each other. You have to make slightly different decisions than you would have made at the start. So even if Python was absolutely the right decision at the beginning, it was not the right decision by the time I was there. This was painfully obvious as an engineer, and I think a lot of other people saw this, but what stopped them was just the amount of work it would have taken to move the stuff over. So I just started scoping this and figuring out what it would take. I started by finding the people that would disagree. There were a bunch of these old-timers that just thought this was a terrible idea and would never work. So I went to talk to them first, like over food in New York, got a bunch of beer, and just got to know them as people before we even talked about the technical problem. You have to build trust. So I had to get to know them as people, and this was so valuable—these are still a lot of my friends today. After building this trust, I also learned there were a bunch of other people that actually did want to do this but were kind of afraid to say it. So these people came out of the woodwork too. Eventually we started scoping this, and this project kind of spun out. It's actually still going today, with many engineers working on it. It's funny because at Facebook, I think this kind of problem rarely happens because the org is so engineering driven. At Instagram, there were many problems of this shape because the org is very product driven. There isn't just a lot of time for those engineering-driven initiatives.

这个项目在某个时候——我的意思是，你把它启动起来了，算是一种自下而上的倡议，然后到了某个时候，它的优先级变得足够高，需要有人不在日本、能面对面支持。我理解 Jake Bolum 是你引入项目的人，他承担了更多的领导角色，而且因为地理位置靠近其他人，可以帮助推动项目。我很好奇你对这个委派点的看法。

This project at some point—I mean you got it off the ground, kind of this bottoms-up initiative, and then at some point it became high priority enough where it needed that in-person support of someone that wasn't in Japan. I understand that Jake Bolum is someone that you helped onto the project and he kind of took more of a lead role, but location-based and close to everyone else so he could help shepherd it along. I'm curious your thoughts on that point of delegation.

比如，你什么时候决定把这么大的事情委派出去，什么时候又决定自己还得盯着，你是如何权衡这个取舍的？

Like when do you decide when to delegate something so big and when do you decide, oh, I need to still be around and how do you navigate that trade-off?

Jake 非常出色。我们是朋友。每次我去西雅图，我们都会聚一聚，他是我认识的最好的工程师之一。所以，很明显他会是这件事的合适负责人。委派的规则一如既往。你知道，你要委派。你永远不要委派自己不想做的事情，这是最重要的规则。你总是委派你想做且擅长的事情，因为这样你就能监控进展，确保一切顺利。有一本很棒的书，安迪·格鲁夫写的《高产出管理》。他是英特尔的前 CEO，这本书听起来可能是最无聊的书，但它就是最好的。其中一条建议就是：委派你喜欢做的事情，这样你就可以监控进展。所以，是的，道理是一样的。你稍微委派一点，然后检查进度。信任越多，检查就越少。而 Jake 技术非常出色，又积极主动，我几乎不需要做什么。从一开始事情就进展得很顺利。

Jake is amazing. We're friends. Every time I go to Seattle, we hang out and he's just one of the best engineers I know. So, it was obvious that he would be a good owner for this. The same rules of delegation apply as always. So, you know, you delegate. You never delegate the thing you don't want to do. That's kind of the most important rule. You always delegate the thing you do want to do and that you know well because then you can monitor the progress and make sure it's going well. And there's this really great book, High Output Management by Andy Grove. He was an old Intel CEO and it's just like the most boring sounding book ever, but it's just like the best. And this is one of the pieces of advice: delegate the thing that you like to do so then you can monitor progress. And so yeah, it's kind of the same thing. You kind of delegate a little bit, you check in. The more trust you have, the less you have to check in. And with Jake, he's so good technically and so proactive. There's just very little I had to do. It was very much on track from the start.

所以我认为，再加上其他一些工作，比如大规模迁移到 GraphQL 或现代化 Instagram 的部分数据模型，最终让你在离开 Meta 之前晋升到了这个首席级别。这次晋升背后有什么故事，或者你有什么可以分享的吗？

And so I think this coupled with some other work, a large migration to kind of GraphQL or modernize some of Instagram's data model, ended up getting you promoted to this principal level before you left Meta. What was the story behind the promotion or anything that you might share?

那次晋升？我想是在我和我的经理 Will 的一对一谈话中，他说：“嘿，我觉得我们应该推荐你晋升 IC8。”我说：“酷。”差不多就是这样。我之前没怎么想过这件事。是的，这并非我主动要求的。我觉得 Will 非常善于识别人才，并为他团队的人争取机会，他觉得我准备好了，就这样。

That promotion? I think Will in a one-on-one that I had with Will, my manager, he was like, "Hey, I think you should like we should put you up for IC8." And I was like, "Cool." And that was pretty much it. I hadn't really thought about it. Yeah, it's not something I really asked for. I think Will was just like does a great job of recognizing people and kind of advocating for his team and he felt that I was ready and yeah, that was that.

在你的职业生涯中，听起来你只关注影响力，你的影响力、杠杆和信誉都在增长，而晋升只是随之而来的副产品。我很好奇，你是如何构建关于如何获得更多杠杆或更大影响力的思考的？你有没有考虑过级别，还是说你觉得不应该想“下一个级别是什么？”，而应该更多地从杠杆或影响力等角度思考？

At any point in your journey, because it sounds like you were impact and impact only and growing and your leverage and your credibility everything was growing and then the promos were this lagging thing where they just kept happening as a byproduct. I'm curious though to structure your thinking about how to get more leverage or kind of have more impact. Did you ever think about the levels or would you say that it's not good to think about like, "Oh what's the next level?" more think in terms of just leverage or impact or something else?

你必须思考级别的用途。级别存在是为了让公司能够向工程师传达对他们的期望。它也存在是为了有一定的问责制。例如，在绩效评估中，你可以将某个级别的工程师与同级别的另一位工程师进行比较。有时在财务方面，不同工程师的成本也不同。所以你可以考虑你想要什么样的人才组合。因此，级别存在是为了公司的原因，而不是工程师的原因。对我来说，我从未以这种方式思考过这些问题。我喜欢做的事情是从事有趣的项目。我喜欢找出问题并解决它们。我喜欢让人们使用的产品变得令人愉悦，这就是真正激励我的东西。所以对我来说，这从来都不是我思考问题的方式。而且，我不知道，我在 Facebook 的第一周，我是一个 IC4，我有各种关于我们应该构建什么的想法。于是我就开始写产品简报。然后我记得我去找连接部门的副总裁，向他推销一个想法，他完全不明白，觉得这个想法很糟糕。然后那没成功。后来我又有了一个关于 Messenger 的想法，我去推销，他们也没有采纳。但几年后，他们确实构建了这个特定的想法。所以，对我来说，就是：有哪些酷点子？我能如何帮忙？还有谁对这些东西感兴趣？我们如何构建酷的东西？

You have to think about what levels are for. Levels exist so that the company can communicate to an engineer what it is they expect the engineer to do. It also exists so that there's some accountability. For example, in performance reviews, the engineer at a particular level you can compare them to another engineer at that same level. And also sometimes on the finance side, different engineers cost a different amount. So you can kind of think about what kind of portfolio you want. So levels kind of exist for company reasons and not for engineer reasons. And for me, it's just never the way that I thought about any of this. Like the thing that I like to do is work on interesting projects. I like to figure out the problems and solve them. I like to just make the things that people use delightful, like the products that they use delightful. This is what really motivates me. So for me, this was just never really the way I thought about it. And I don't know, my first week at Facebook, I was like an IC4 and I had all these ideas for stuff that we should build. And so I just started writing like product briefs. And then I remember I went to like the VP of connectivity and like pitched him some idea and he just didn't understand it at all and thought it was terrible. And then that didn't work. And then I had another idea for messenger and I went and pitched that and they also didn't do it. But then they actually did end up building it a couple years later, this particular idea. So yeah, for me it's just like, you know, what are the cool ideas and how can I help and who else is interested in this stuff and how can we build cool stuff?

你离开 Meta 去了 Anthropic，我很好奇你当时是怎么考虑去 Anthropic 的。

You left Meta to go to Anthropic and I'm very curious what was your thinking about going to Anthropic.

我记得 ChatGPT 刚出来时我第一次使用它。那是几年前了，我当时在日本。我是镇上唯一的工程师，也是唯一会说英语的人，没有人可以和我聊技术。我记得每天早上我读 Hacker News，然后使用 ChatGPT，我被这个产品震撼了，它给我的感觉是——现在我们习以为常了，但你知道，LLM 就是魔法。这是一项绝对不可思议的技术。现在我的看法已经转变了。对我来说，LLM 就像一种外星生命形式，我们可以培育它，把它带到这个世界上。它不仅仅是一项技术。而且我是一个非常喜欢阅读的人，我读了很多科幻小说，那是我主要的阅读类型。所以当时我想：“天哪，我必须从事这方面的工作。”那么，有哪些实验室在做这个呢？于是我去和在不同实验室工作的朋友聊了聊。我觉得当我来到 Anthropic 时，我记得我的第一顿午餐。是和 Ben Mann 一起，他是这里的创始人之一。我们和他以及其他一群人坐在一起吃午餐。我提到了一本我喜欢的奇怪科幻小说。我想是格雷格·伊根写的，他是硬科幻作家。我从来没有遇到过读过这本书的人。我在餐桌上讲了一个书中的趣事。结果桌子周围的人都说：“哦，是啊，那本书不错，但另一本书呢？”所以这就是一群狂热的科幻迷，他们深入思考着和我关心的同样的问题。我觉得另一部分原因是，当你读了很多科幻小说，你会以一种非常推测的方式，感知到这件事可能如何发展。AI 对社会具有如此变革性的影响。我认为它首先冲击工程领域，然后会冲击社会的每一个部分。它会影响到一切。我们现在正看到它的第一波浪潮。我想，我读得足够多，知道它可能以糟糕的方式发展，而且有很多方式会出错。

I remember using ChatGPT for the first time when it came out. This was years ago and I remember I was in Japan. I was the only engineer in my town. I was the only person that spoke English in my town and there's just no one that I could talk to about tech stuff. And I remember every morning I read Hacker News and I remember using ChatGPT and I was just blown away by the product and just this feeling that it gave me of just nowadays we take it for granted but you know LLMs are just magic. It's just this absolutely incredible technology. And I think now my view of it has shifted. It's like to me, LLMs are this kind of alien life form that we get to nurture and we get to bring into existence. It's not just a technology. And I'm also a really big reader. I read a lot of sci-fi. That's kind of my big genre. And so at the time I was like, "Oh my god, I have to work on this stuff." And you know, what are the labs that are working on it? So I went to talk to friends working at various labs. And I feel like when I came to Anthropic, I remember my first lunch. This was with Ben Mann, who's one of the founders here. And we were sitting at lunch with him and a bunch of other people. And I mentioned this weird sci-fi book that I like. It was I think it was by Greg Egan or something. It's hard sci-fi author. And I've literally never met anyone that's read this book. And at the table I kind of gave an anecdote from it. And everyone around the table was like, "Oh yeah, yeah, that book was good, but like what about this other book?" And so it was just this group of people of these intense sci-fi nerds, these people that think so deeply about these same problems I care about. And I think the other part for me was how you're reading a lot of sci-fi, you kind of get a sense of, in a very speculative way, how this thing can play out. AI is just so transformative to society. I think it's hitting engineering first and it's going to hit every part of society. It's going to affect everything. And we're seeing the very first waves of this right now. And I think I just, you know, like I read enough that I kind of knew the bad ways that this can play out and there can be so many ways this thing goes wrong.

所以对我来说，Anthropic 是显而易见的选择，因为我希望在一个地方，哪怕以最微小的方式，也能确保这件事顺利发展——作为一名工程师，这是我所能做的全部。有趣的是，加入之前，我把安全当回事，觉得它可能发生。在 Meta，它总被视为一种税——安全团队之类的——他们让你做事，但没人真正乐意做，因为那不是产品。这是我之前对安全的看法。但同时，我猜测它可能完全不同。现在在 Anthropic，我知道它完全不一样。我看到每个新模型及其带来的新风险，以及公司如何言行一致——投入多少算力用于安全研究和对齐研究，有多少人从事这项工作。我们曾推迟模型发布，因为不确定它们是否安全，必须确保安全才行。到了 Opus 4，风险大幅上升。如果模型能设计生物病毒、做真正危险的事，那就不只是选举操纵这样的基线风险了——那对低级别模型来说已经是大事。随着模型越来越危险，风险也越来越高，很快你就会进入这样的领域：人们可以用模型构建真正危害人类的东西，不只是一个国家的政治，而是人类的存亡。这不是科幻。这是今天真实存在的风险，我们必须积极应对。所以对我来说，能参与其中并贡献一点力量——这就是让我下定决心的地方。

And so for me, Anthropic was just the obvious choice because I wanted to be at a place where, in the tiniest way, I could make sure this thing goes well, which as an engineer is all I can do. It's funny. Before I joined, I took safety seriously as a thing that could happen. At Meta, it was always seen as a tax—integrity teams and so on—they get you to do stuff, but it's not really what anyone's excited to do because it's not the product. That was my view of safety before. But at the same time, I speculatively knew it could be a very different thing. Now at Anthropic, I know it's completely different. I see every model that comes out and the new risks that come with it, and how as a company we put our money where our mouth is in terms of how much compute goes to safety research and alignment research, and how many people work on this. We've held up model releases in the past because we didn't know they were safe and had to make sure before. With Opus 4, the risks went way up. If the model can design bioviruses and do things that are really dangerous, it's not just baseline risks like election manipulation—that was a big deal for a low-level model. As models get more dangerous, the risks get higher, and quickly you get into territory where people can use the model to build things actually dangerous for humanity, not just politics in a country but literally the existence of humanity. This is not sci-fi. This is a real risk today that we actively have to fight. So for me, getting to be a part of this and contribute a little bit—that's what put me over.

那你加入的时候呢？回想你之前所在的工程文化与 Anthropic 相比，有没有什么特别突兀的差异？

What about when you joined? When you think about the engineering cultures you came from compared to Anthropic, were there any really jarring differences?

是的，我会说两点。第一，它仍然是一家初创公司，有很多常识。有趣的是——这是每家大公司都会失去的东西，你必须与之抗争，因为随着时间的推移，决策者离他们决策的影响越来越远，无论是产品还是人员。你必须想出各种流程来拉近他们与影响的距离，提高决策质量。但在一家初创公司，每个人都很有常识，通常都会做正确的事。所以我不用花很多时间说服别人。如果某件事应该做，那是显而易见的，大家都会去做。第二，对我个人来说，我逐渐认识到最能激励我的是使命。它非常重要——是它让我每天兴奋地去上班。是它让我在周末写代码，因为我想写，而不是因为有截止日期。我在 Facebook 群组部门时深有体会。那里非常以使命为导向。很长一段时间，Jen Dolski 是副总裁，她曾是 Change.org 的 CEO。她把 Facebook 群组当成非营利组织来运营。她有一套变革理论，关于如何将人们与志同道合的人联系起来形成社区，做这个工作非常激励人。在 Instagram，也许是因为地理距离或其他原因，我从未真正感受到同样的使命感。但在 Anthropic，我强烈地感受到了，这可能是最让我兴奋的事。

Yeah, I would say two things. One is still being a startup, there's a lot of common sense. It's funny—this is something every big company loses, and you have to fight it because over time decision makers get more distant from the impact of their decision, whether it's the product or the people. You have to come up with processes to bring them closer and improve decision quality. But still being at a startup, everyone just has common sense and generally does the right thing. So I don't have to spend a lot of time convincing people. If we should just do something, it's obvious and everyone does it. The second thing is, for me personally, something I learned over time that motivates me the most is mission. It's so important—it's what keeps me going to work every day excited. It's what makes me code on weekends because I want to, not because there's a deadline. I felt this a lot at Facebook Groups. It was very mission-oriented. For a long time, Jen Dolski was the VP, and she used to be the CEO of Change.org. She ran Facebook Groups like a nonprofit. She had a theory of change about connecting people to like-minded people to form communities, and it was so motivating to work on that. At Instagram, maybe because of geographic distance or something else, I never quite felt that same mission. But at Anthropic, I feel that so strongly, and that's probably the most exciting thing for me.

我知道你被认为是 Claude Code 的创造者，而且你在很多地方讲过这个故事。但我很好奇——我和一个朋友聊过，Claude Code 出现时环境是什么样的，实际上有很多已有的竞争工具都接入了模型。Claude Code 有什么不同之处，让它胜出并在内部像野火一样蔓延开来？

I know you're credited as the creator of Claude Code, and I think you've told that story in many places. But I'm curious—I was talking with a friend about what the environment was like when Claude Code came, and there were actually a lot of competing existing tools that hooked into the model. What was different about Claude Code that won out and caught like wildfire internally?

当时，编程看起来非常不同。如果你想到 AI 编程，人们想到的是自动补全。基本上就是这样。有一些非常早期的智能体，但相对于自动补全来说，它们是次要的。通常用于问答，而不是真正的编程。所以当人们想到 AI 用于编程时，他们想象的是一个完全不同的产品——按 Tab 键自动补全。我以为就是这样，这就是当时的状况。然后 Ben，我当时的上司，推动我想得更远一些。他真正内化了缩放定律——他从 Anthropic 成立之初就在那里，之前也在其他实验室——所以他理解模型改进的速度有多快。他强烈推动我：不要为今天的模型构建，要为六个月后的模型构建。老实说，在很长一段时间里，Claude Code 并不是一个很好的产品。即使在内部使用，我也只把它用于大约 10% 的代码。你有时会用，但它真的做不了大部分事情，因为模型能力不够。然后某个时候，我们发布了 Sonnet 和 Opus 4——我想大概是今年三月——产品突然就奏效了。我们在使用数据中看到了这一点，我自己的编程中也感受到了。我开始能够用它编写大约一半的代码。这完全得到了验证，因为那正好是项目启动六个月后——就是这个时间线。现在，Claude Code 的大部分代码都是用 Claude Code 编写的。我想大概是 80% 或 90%。如果你看看 Anthropic 的团队，有些团队 90% 的代码都是用 Claude Code 写的。这不只是我们团队。

At the time, coding looked very different. If you thought about AI coding, people thought about autocomplete. That was essentially it. There were some very early agents, but it was kind of a secondary thing next to autocomplete. Often it was used for Q&A, not really for coding. So when people thought about AI for coding, it was a completely different product you imagined—tab to autocomplete. I thought that's what it was, and that was the state of it. Then Ben, who was my manager at the time, pushed me to think a little bigger. He really internalized the scaling laws—he was there from the beginning of Anthropic and at other labs before—so he understood how quickly the models are improving. He pushed me hard: don't build for the model of today, build for the model six months from now. Honestly, for a long time, Claude Code was not a great product. Even when used internally, I used it for maybe 10% of my code. You'd use it sometimes, but it really couldn't do most things because the model wasn't capable enough. Then at some point we released Sonnet and Opus 4—I think this was maybe March of this year—and the product just worked. We saw this in the usage data, and I saw it in my own coding. I started to be able to use it for probably half of my code. This was totally borne out because it was literally six months after starting the project—that was the timeline. At this point, most of Claude Code is written using Claude Code. I think it's like 80 or 90%. If you look at teams at Anthropic, some teams have like 90% of their code written using Claude Code. This is not just our team.

如果你看看对生产力的影响，尽管 Anthropic 自年初以来规模扩大了两倍，但每位工程师的生产力（按 poor cost 衡量，我们之前聊过这个）因为 Claude Code 增长了近 70%。所以作为产品负责人，我通常会往前想一步。在实验室工作，你得换个思路：往前想一步，不是两步，同时还要对模型和我们所处的指数级增长潜力保持清醒。

And if you look at the impact on productivity, even though Anthropic has tripled since the start of the year, productivity per engineer measured in poor cost—we were talking about this before—has grown almost 70% per engineer because of Claude Code. So as a product person, I usually think a step ahead. Being at a lab, you have to think differently: you have to think a step ahead, not two steps ahead, but also be really aware of the model and the exponential potential we're on.

你看了 Karpathy 最近的采访吗？

Did you see the recent interview with Karpathy?

我还没机会看。

I haven't had a chance to watch it yet.

好的。他在播客里提到了一点，算是稍微泼了点冷水：虽然 vibe coding 能生成很多神奇的结果，但也会产生很多“垃圾”或者说有一些缺点。所以我很好奇，当模型生成大量代码，但可能不完全符合你的要求，或者最终结果有一些不易察觉的问题时，你是怎么看的？

Okay. So one thing he said in the podcast was kind of pushing back a little bit because basically vibe coding, although it has a lot of miraculous results because of what it can generate, there's also a lot of slop or some drawbacks. So I'm curious how you think about that when the model produces a lot of code but maybe it's not exactly how you'd like it, or the end result has some non-obvious problems.

AI 编程就像我们使用的其他工具一样，你得学会怎么用它。Karpathy 显然会写代码。我觉得很多刚接触这类工具的人，要么让它做太大太复杂的事，要么对模型写的代码和对自己写的代码标准不一样。所以我在团队里做的一件事是：在 Claude Code 团队，我们对代码的标准是一样的，不管代码是模型写的还是人写的。如果代码很烂，我们就不合并。标准完全一样，你只需要让模型改进代码，让它变得更好。使用这些工具也有不同的方式。有时候你想 vibe coding——这对一次性代码和原型很重要，这些代码不在关键路径上。我经常这么做，但这绝对不是你想一直做的事，因为有时候你需要可维护的代码，有时候你需要对每一行都深思熟虑。所以根据问题不同，你需要不同的方法。我有一套常用的方法。有时候我会 vibe coding——这其实很少见，主要用于原型和一次性代码。通常我会和模型结对编程来写代码。首先我们对齐一个计划——在 Claude Code 里按 Shift+Tab 进入计划模式。模型会制定一个计划，然后我看代码，可能会要求它改进或清理。这是一个非常深入的过程；我和模型结对，一起写代码。有时候我仍然会手写代码。对于核心查询循环的某些部分，我对参数命名或某行代码放在哪里有很强的意见，所以我会手写。问题是，模型整体上还是不擅长编程。还有很大的改进空间，而且这是它们最差的时候了。但想想一年前 AI 编程的状态——就像自动补全——现在完全是另一个世界了。想想未来会怎样，接下来几个月和几年会是什么样子。对我来说，让我兴奋的是了解我们正在走的这条轨迹。

AI coding is a tool like every other tool we use, and you have to learn how to use it. Karpathy obviously knows how to code. I think a lot of people new to this kind of tool tend to ask it to do stuff that's a bit too big, or they hold a different bar for the model's code versus their own code. So something I do for the team is: for the Claude Code team, we have the same exact bar regardless of whether the code was written by the model or by a human. If the code sucks, we're not going to merge it. It's the same bar, and you just ask the model to improve the code and make it better. There are also different ways of wielding these tools. Sometimes you want to vibe code—this is really important for throwaway code and prototypes, code that's not in the critical path. I do this all the time, but it's definitely not what you want to do all the time, because sometimes you want maintainable code, sometimes you want to be very thoughtful about every line. So depending on the problem, you want a different approach. There's a set of approaches I use. Sometimes I'll vibe code stuff—this is actually quite rare, mostly for prototypes and throwaway code. Usually I pair with a model to write code. First we align on a plan—this is like Shift+Tab in Claude Code to get into plan mode. The model will make a plan, then I'll see the code, and I might ask it to improve or clean it up. It's a very involved process; I'm pairing with the model, working together to write code. And sometimes I'll still write the code by hand. For some parts of our core query loop, I have very strong opinions about things like the names of parameters or which particular line of code something is on, so I'll still write it by hand. The thing is, models are still overall not great at coding. There's still so much room to improve, and this is the worst it's ever going to be. But it's insane to think back a year to where the state of AI coding was—like type-ahead—and it's a completely different world. You think about where this is headed, what's about to happen, and what this looks like over the next few months and years. For me, what keeps me really excited is having the context about this trajectory we're on.

当人们听到 Claude Code，他们会想到编程，但在软件工程之外还有很多用例，比如数据科学家查询数据。当你想到 Claude Code 用于一切时，你有什么想法？

When people hear Claude Code, they think about coding, but there are many use cases outside of software engineering, like querying data for data scientists. What are your thoughts when you think of Claude Code for everything?

我走进办公室时看到最疯狂的事。我记得大概 6 个月前走进办公室，我们的数据科学家 Brandon 的电脑上开着 Claude Code。他坐在我们旁边，我说：“哥们，你在干嘛？你在试用吗？”他说：“不，不，我在用它做我的工作。”我说：“什么？”于是他学会了怎么用终端、安装 Node.js，然后装了 Claude Code，它就在写一堆 SQL 并为他做分析。现在当我走过我们旁边的数据科学家时，每个人同时开着好几个 Claude Code——不再只是一个了。他们在做各种事情：写 SQL、处理数据、写 DBT 管道、写代码。所以编程之外有这么多应用，看到人们用它做各种事情真是太酷了。甚至还有完全非技术用户——Anthropic 一半的销售团队用 Claude Code 做他们的工作。他们可以把它连接到 Salesforce 和不同的数据源，然后这样工作。看到这个真是太酷了。这不是我们设计的方式，也不是我们的初衷。

It was the craziest thing when I walked in. I remember walking into the office maybe 6 months ago, and our data scientist Brandon had Claude Code up on his computer. He sits next to us, and I'm like, "Dude, what are you doing? Are you trying it out?" And he's like, "No, no, I'm using it for my work." I was like, "What?" So he figured out how to use a terminal, install Node.js, then installed Claude Code, and it was writing a bunch of SQL and doing analysis for him. Now when I walk by the data scientists that sit next to us, every person has a bunch of Claude Codes up at the same time—not just one anymore. They're doing all sorts of stuff: writing SQL, crunching data, writing DBT pipelines, writing code. So there are all these applications outside of coding, and it's just so cool to see how people are using this for all sorts of stuff. There are even totally non-technical users—half of our sales team at Anthropic uses Claude Code to do their work. They can connect it to Salesforce and different data sources, and they can do their work this way. It's so cool to see. This is not how we designed it; this is not the intent.

当我听到 Claude Code，我也会想到 Codex，最大的竞争对手之一。我很好奇你对与 Codex 和 OpenAI 竞争的看法。Claude Code 做得更好的是什么？另外，我也好奇这些 AI 产品的粘性——是什么让人们留在 Claude Code 而不是 Codex 之类的？

When I hear Claude Code, I also think of Codex, one of the biggest competitors. I'm curious about your thoughts on the competition with Codex and OpenAI. What does Claude Code do better? Also, I'm curious about the stickiness of these AI products—what keeps people in Claude Code versus Codex, for instance.

我不太确定。我个人不用其他产品。

I'm not totally sure. I don't personally use the other products.

好的。

Okay.

对我来说，我告诉团队的是：很容易因为关注竞争对手而分心。我认为大公司经常陷入这种失败模式，因为竞争对手太多，而且很容易通过复制看到你能构建什么。想出能更好解决用户需求的新颖想法要难一些。所以我努力做的一件事，也是我推动团队做的事，就是不要被所有这些其他产品带偏。总会有很多产品，而且越多对我们来说越是成功的标志。我们保持高度专注，解决我们自己的问题，解决 Anthropic 研究人员的问题，解决我们用户的问题。

For me, the thing I tell the team is: it's so easy to get sidetracked by looking at competitors. I think big companies fall into this failure mode a lot because there are so many competitors and it's so easy to see the thing you could build by just copying it. It's a bit harder to come up with novel ideas that solve the user need better. So the thing I try really hard to do, and the thing I nudge our team to do, is don't get sidetracked by all these other products. There will always be a lot, and the more there are, the bigger a sign of success that is for us. We stay laser focused on solving our problems, solving Anthropic researchers' problems, and solving our users' problems.

在对话的最后，我想问几个关于职业反思的问题。

Coming to the end of the conversation, I just want to ask a few career reflections.

我注意到你没有计算机科学学位，却成为了如此出色的软件工程师。在你的职业生涯中，有没有哪个阶段这让你受阻，还是你觉得它并不必要或无关紧要？

One thing I was curious about when I was looking is that you didn't have a CS degree or a computer science degree, and you've become such a strong software engineer. Was there any part in your career where it might have held you back, or do you think it's not necessary or relevant?

我学的是经济学，实际上还辍学去创业了。对我来说，任何事情都是在工作中学习的。编程是一项非常实用的技能。我无法想象在学校里学的东西——比如你上数据结构课，只是跑跑代码，却从未构建过产品，这有什么意义？所以我建议人们从实践中学编程。这是一项非常实用的技能。之后如果你想回头学理论，再去学。但就我个人而言，从未觉得这对我有任何阻碍。

Yeah, I studied economics and I actually dropped out to do startups. For me, anything you do, you learn on the job. I think programming is such a practical skill. I couldn't imagine the kinds of things you learn in school. If you're in a data structures class, you're running that, but you haven't built a product—how is it relevant at all? So my recommendation would be to learn coding practically. It's a very practical skill. Then if you want to go back and learn the theory after, go do that. But personally, I've never felt it held me back at all.

那关于生产力技巧呢？我看到你说自己每天大约朝九晚六，只用两根手指打字，但产出却惊人。你有这么多副业项目，主业也毫不含糊。你最重要的生产力技巧是什么？或者你是如何保持这种状态的？

What about productivity tips? I saw that you said you work roughly 9 to 6 every day and you only type with two fingers, but your output is ridiculous. You have all these side projects and your main stuff is no joke. So what's your top productivity tips or how do you maintain that?

如今我的建议和几年前完全不同了。现在的建议就是学会使用 Claude Code，并学会运行多个 Claude Code 来完成任务。几周前我们发布了插件，负责构建它的工程师 Daisy 让她的 Claude 设置了一个 Jira 看板、创建任务，然后让 20 个 Claude 智能体集群在周末构建插件。她在 Docker 容器中以危险模式运行，几天后就完成了。这就是工程学的未来。现在谈到生产力技巧，就是学会用 Claude 来自动化繁琐工作，以及如何让一群智能体协同工作。你更像是在编排，而不是手动写代码。几年前我的建议会平淡得多，比如划出整块时间之类的。

Nowadays my tips are very different from what I would have said a couple years ago. Now the tip is just learn how to use Claude Code and learn how to run a bunch of Claude Codes to do stuff. We launched plugins a couple weeks ago, and Daisy, one of the engineers who built it, just had her Claude set up a Jira board, make tasks, and then she had a swarm of 20 Claude agents just build plugins over the weekend. She ran it in a Docker container in dangerous mode and it was done after a couple days. This is the kind of thing that is the future of engineering. Nowadays when we talk about tips for productivity, it's learn how to use Claude in order to automate toil and also how to use a bunch of agents together to do work. You're kind of orchestrating instead of manually writing code. Years ago my tips would have been a lot more prosaic, like blocking off time and things like that.

Claude Code 很有意思。我想知道这对著名的“创造者日程”与“管理者日程”有何影响。感觉你刚才说的意思是，软件工程师越来越像管理者那样工作——你有一群 Claude Code，不需要深度专注就能推进工作，而是需要在 20 件不同事情之间切换上下文。那么你不再需要大块的专注时间写代码了吗？

It's interesting with Claude Code. I wonder what that does for the famous maker schedule versus manager schedule. It feels like what you just said is that software engineers are becoming more like a manager style of working, where you have a fleet of these Claude Codes and you don't need deep focus to move forward. You need context switching across 20 different things. So do you no longer have big focus blocks for coding?

没那么多了。我周末也会写代码，所以我喜欢安静的时间。但除此之外，我每天早上都会打开 Claude Code 和移动应用。现在 Claude 里有一个代码标签页——我们这周刚发布，但我们已经用了一段时间了。每天早上我醒来后，启动几个智能体来开始我当天的代码。这很疯狂，因为如果你六个月前问我是否会这样写代码，我会说：“不，你疯了吗？怎么能这样写代码？”但它确实有效。它就在这里，而且管用，我现在很多代码都是这样写的。我会启动几个智能体，然后到电脑前检查状态。有时如果代码看起来不错，我就直接合并。有时我会拉到本地，跳转过去编辑一点。你之后会和 Fiona 聊，据她告诉我，她已经十年没写过代码了，但现在她每周写好几次代码，因为作为管理者，尽管日程疯狂，她仍然可以用移动应用和网页打开终端来写代码。这太疯狂了——我们正经历着这种转变，我们所做的事情，我从小成长起来的东西，正在彻底改变。它正在变得人人可及。

Not as much. I tend to code on the weekends also, so I love the quiet time. But otherwise, I'll start every morning by opening Claude Code and the mobile app. There's a code tab in Claude now—we just launched this this week, but we've been using it for a while. Every morning I wake up and start a few agents to start my code for the day. It's crazy because if you'd asked me six months ago if this is how I would code, I would say, 'No, are you crazy? How can you code in this way?' But it actually works. This is here and it works, and this is how I write a lot of my code now. I'll start a few agents, then when I get to a computer, I'll check in on the status. Sometimes I'll just merge it if the code looks good. Sometimes I'll pull it locally and teleport to edit a little bit. You're going to talk to Fiona later, and from what she told me, she hasn't coded in a decade, but she's writing code multiple times a week now because as a manager, even though her schedule was insane, she can still use the mobile app and the web to open a terminal and write code. It's just crazy—we get to live through this transition where the thing that we do, the thing I grew up on, is totally changing. It's becoming accessible to everyone.

最后一个问题：以你现在的职业阅历，如果能回到刚入行时给自己一些建议，你会说什么？

Last question for you: knowing everything that you know now in your career, if you could go back to yourself when you just entered the industry and give yourself some advice, what would you say?

就用常识。我认为有很多东西，尤其是在大公司里，会让你偏离常识。有很多组织惯性——事情之所以这样，是因为它们一直这样。有很多激励错位。当然也有很多好东西，但这些也都在。所以运用常识非常重要。在我职业生涯早期，我创办过很多初创公司，也在很多初创公司工作过。那里也一样：用常识去判断市场想要什么、用户想要什么，然后去构建。所以，相信你自己，培养你的常识。

Just use common sense. I think there's a lot of stuff, especially in big companies, that pulls you away from common sense. There's a lot of organizational inertia—things are this way because they have been this way. There's a lot of misaligned incentives. There are also a lot of good things, but these things exist too. So it's really important to use common sense. Early on in my career, I was starting a bunch of startups and worked at a lot of startups. There too, it's the same thing: use common sense to figure out what the market wants and what users want, and build it. So yeah, trust yourself and develop your common sense.

太棒了。非常感谢你，Boris，抽出时间。真的很感激。

Awesome. Well, thank you so much, Boris, for your time. Really appreciate it.

谢谢。感谢收听播客。我不卖任何东西，也不做赞助，但如果你想支持播客，可以在 YouTube 或 Spotify 上互动内容。如果你愿意写个评论，那会非常有帮助。如果你希望邀请某位嘉宾，请告诉我。我觉得寻找非常资深的个人贡献者——谷歌上并没有一个现成的列表可以搜索。所以如果你所在的组织或公司里有你真正敬仰、想听其职业故事的人，请告诉我，我会去联系。

Yeah. Thanks. Thanks for listening to the podcast. I don't sell anything or do sponsorships, but if you want to help out with the podcast, you can support by engaging with the content on YouTube or on Spotify. If you want to drop a review, that'll be super helpful. And if there's any guests that you want to bring on, please let me know. I feel like sourcing very senior ICs—there's no well-studied list out there on Google that I can just search this up. So if there's someone in your org or at your company who you really look up to and you want to hear their career story, let me know and I'll reach out.