Lenny's Podcast: Product | Career | Growth
00:24:03 · Lenny Rachitsky
[00:24:03] S1: I hear you have these very specific principles that you've codified for your team that when people join you walk them through them. I believe one of them is, "What's better than doing something? Having Claude do it." And it feels like that's exactly what you describe with this memory leak is you almost forgot that principle of like, "Okay. Let me see if Claude can solve this for me."
00:24:21 · Boris Cherny
[00:24:21] S0: There's an interesting thing that happens also when you under-fund everything a little bit, because then people are forced to Claude-ify. And this is something that we see so ... For work, where sometimes we just put one engineer on a project, and the way that they're able to ship really quickly ... Because they want to ship quickly. This is an intrinsic motivation that comes from within. It's just wanting to do a good job. If you have a good idea, you just really want to get it out there. No one has to force you to do that. That comes from you. And so, if you have Claude, you can just use that to automate a lot of work, and that's what we see over and over. So, I think that's one principle is under-funding things a little bit. I think another principle is just encouraging people to go faster. So, if you can do something today, you should just do it today. And this is something we really, really encourage on the team. Early on, it was really important, because it was just me. And so, our only advantage was speed. That's the only way that we could ship a product that would compete in this very crowded coding market. But nowadays, it's still very much a principle we have on the team, and if you want to go faster, a really good way to do that is to just have Claude do more stuff. So, it just very much encourages that.
00:25:32 · Lenny Rachitsky, Boris Cherny
[00:25:32] S1: This idea of under-funding, it's so interesting, because, in general, there's this feeling like AI is going to allow you to not have as many employees, not have as many engineers. And so, it's not only you can be more productive. What you're saying is that you will actually do better, if you under-fund. It's not just that AI can make you faster, it's you will get more out of the AI tooling if you have fewer people working on something. [00:25:54] S0: Yeah. If you hire great engineers, they'll figure out how to do it. And, especially, if you empower them to do it. This is something I actually talk a lot about with CTOs and all sorts of companies. My advice generally is, "Don't try to optimize. Don't try to cost cut at the beginning. Start by just giving engineers as many tokens as possible." And now you're starting to see companies ... Like, at Anthropic, we have ... Everyone can use a lot of tokens. We're starting to see this come up as a perk at some companies where if you join you get unlimited tokens. This is a thing I very much encourage, because it makes people free to try these ideas that would have been too crazy, and then if there's an idea that works, then you can figure out how to scale it, and that's the point to optimize, and to cost-cut, figure out ... Maybe you can do it with a haiku, or with Sonnet instead of Opus, or whatever. But at the beginning, you just want to throw a lot of tokens at it, and see if the idea works, and give engineers the freedom to do that.
00:25:54 · Boris Cherny, Lenny Rachitsky
[00:25:54] S0: Yeah. If you hire great engineers, they'll figure out how to do it. And, especially, if you empower them to do it. This is something I actually talk a lot about with CTOs and all sorts of companies. My advice generally is, "Don't try to optimize. Don't try to cost cut at the beginning. Start by just giving engineers as many tokens as possible." And now you're starting to see companies ... Like, at Anthropic, we have ... Everyone can use a lot of tokens. We're starting to see this come up as a perk at some companies where if you join you get unlimited tokens. This is a thing I very much encourage, because it makes people free to try these ideas that would have been too crazy, and then if there's an idea that works, then you can figure out how to scale it, and that's the point to optimize, and to cost-cut, figure out ... Maybe you can do it with a haiku, or with Sonnet instead of Opus, or whatever. But at the beginning, you just want to throw a lot of tokens at it, and see if the idea works, and give engineers the freedom to do that. [00:26:49] S1: So, the advice here is just be loose with your tokens, with the cost on using these models. People hearing this may be like, "Of course. He works at Anthropic. You want us to use as many tokens as possible." But what you're saying here is the most interesting innovative ideas will come out of someone just taking it to the max and seeing what's possible.
00:26:49 · Lenny Rachitsky, Boris Cherny
[00:26:49] S1: So, the advice here is just be loose with your tokens, with the cost on using these models. People hearing this may be like, "Of course. He works at Anthropic. You want us to use as many tokens as possible." But what you're saying here is the most interesting innovative ideas will come out of someone just taking it to the max and seeing what's possible. [00:27:08] S0: Yeah. And I think the reality is at small-scale, you're not going to get a giant bill for anything like this. If it's an individual engineer experimenting, the token cost is still probably relatively low relative to [inaudible 00:27:21] other costs of running the business. So, it's actually not a huge cost. As the thing scales up, so, let's say they build something awesome, and then it takes a huge amount of tokens, and then the cost becomes pretty big, that's the point at which you want to optimize it. But don't do that too early. [00:27:37] S1: Have you seen companies where their token cost is higher than their salary? Is that a trend you think we're going to find and see? [00:27:44] S0: At Anthropic, we're starting to see some engineers that are spending hundreds of thousands a month in tokens. So, we're starting to see this a little bit. There's some companies that we're starting to see similar things. Yeah. [00:27:58] S1: Going back to coding, do you miss writing code? Is it something you're sad about that this is no longer a thing you'll do as a software engineer?
00:27:58 · Lenny Rachitsky, Boris Cherny
[00:27:58] S1: Going back to coding, do you miss writing code? Is it something you're sad about that this is no longer a thing you'll do as a software engineer? [00:28:06] S0: It's funny. For me, when I learned engineering, for me, it was very practical. I learned engineering, so, I could build stuff. And, for me, I was self-taught. I studied economics in school, but I didn't study CS. But I taught myself engineering. Early on, I was programming in middle school. And from the very beginning, it was very practical. So, I learned to code, so, that I can cheat on a math test. That was the first thing- [00:28:33] S1: Nice. [00:28:33] S0: ... we had these graphing calculators, and I just programmed- [00:28:36] S1: The T83. TI83? [00:28:39] S0: Yeah. T83+. Yeah. Yeah. Exactly. [00:28:40] S1: Plus. [00:28:41] S0: Plus. Yeah. I programmed the answers in, and then the next math test, or whatever, the next year, it was just too hard. I couldn't program all the answers in, because I didn't know what the questions were. And so, I had to write a little solver, so, that it was a program that would just solve these algebra questions or whatever. And then I figured out you can get a little cable, you can give the program to the rest of the class, and then the whole class gets As, but then we all got caught, and the teacher told us to knock it off. But from the very beginning- [00:29:08] S1: Wow.