Skip to content

Podcast

Inside Claude Code With Its Creator Boris Cherny

Y Combinator Startup Podcast

Source ↗ ← All highlights
  • Design For The Next Model
    • Build for the model six months from now, not today’s capabilities.
    • Anticipate model improvements and design products that will benefit from near-future advances. Transcript: Boris Cherny At Anthropic, the way that we thought about it is we don’t build for the model of today. We build for the model six months from now. That’s actually still my advice to founders that are building on LLMs. Just try to think about what is that frontier where the model is not very good at today? Because it’s going to get good at it. All of quad code has just been written and rewritten and rewritten and rewritten over and over and over. There is no part of quad code that was around six months ago. You try a thing, you give it to users, you talk to users, you learn. And then eventually you might end up at a good idea. Sometimes you don’t. Other Speaker Are you also in the back of your mind thinking that maybe like in six months you won’t need to prompt that explicitly? Would the model just be good enough to figure out on its own? Boris Cherny Maybe in a month. Other Speaker No more need for plan mode in a month? Oh my god. Welcome to another episode of The Light Cone. And today we have an extremely special guest, Boris Cherney, the creator, engineer of Claude Code. Boris, thanks for joining us. Thanks for having me. Thanks for creating a thing that has taken away my sleep for about three weeks straight. I am very addicted to Claude Code and it feels like rocket boosters. Has it felt like this for people like for, you know, months at this point? I think it was like end of November is where a lot of my friends said like something changed. Boris Cherny I remember for me, I felt this way when I first created QuadCode and I didn’t yet know if I was onto something. I kind of felt like I was onto something. And then that’s when I wasn’t sleeping. And that was just like three straight months. This was September 2024. Yeah, it it was like three straight months. I didn’t take a single day vacation, worked through the weekends, worked every single night. I was just like, oh my God, this is, I think this is going to be a thing. I don’t know if it’s useful yet because it couldn’t actually code yet. If you look back on those moments to now, like what would be like the most surprising thing about this moment right now? It’s unbelievable that we’re still using a terminal. That was supposed to be the starting point. I didn’t think that would be the ending point. And then the second one is that it’s even useful. Because, you know, at the beginning, it didn’t really write code. Even in February, when we GA’d it, it wrote maybe like 10% of my code or something like that. I didn’t really use it to write code. It wasn’t very good at it. I still wrote most of my code by hand. So the fact that it actually, like, our bets paid off, and it got good at the thing that we thought it was going to get good at, because it wasn’t obvious. At Anthropic, the way that we thought about it is we don’t build for the model of today. We build for the model six months from now. And that’s actually, like, still my advice to founders that are building on LLMs, is, you know, just try to think about, like, what is that frontier where the model is not very good at Today? Because it’s going to get good at it and you just have to wait. (Time 0:00:00)
  • Models Prefer Tooling
    • Models want to use tools and interact with the world, not just answer chat prompts.
    • Enabling tool use unlocks capabilities the model already seeks to exercise. Transcript: Boris Cherny It was like, it was so accidental that it just kind of evolved into this. You know, as Anthropic, I think for Ant, the bet has been coding for a long time. And the bet has been the path to safe AGI is through coding. And this has kind of always been the idea. And the way you get there is you teach the model how to code, then you teach it how to use tools, then you teach it how to use computers. And you can kind of see that because the first team that I joined at Anthropic, it was called the Anthropic Labs team. And it produced three products. It was QuadCode, MCP, and the desktop app. So you can kind of see how these weave together. The particular product that we built, no one asked me to build a CLI. We kind of knew maybe it was time to build some kind of coding product because it seemed like the model was ready, but no one had yet really built a product that harnessed this capability. So like still there’s this insane feeling of product overhang, but at the time it was just like even crazier because like no one had built this yet. And so I started like hacking around and I was like, okay, we build a coding product. What do I have to do first? I have to understand how to use the API because I hadn’t used the Anthropic API at that point. And so I (Time 0:02:47)
  • Terminal Prototype Spread Organically
    • Boris prototyped a terminal CLI to use the Anthropic API because it avoided building a UI.
    • The terminal prototype spread internally by coworkers sharing it and dogfooding it. Transcript: Boris Cherny It was an accident. I remember, so after the terminal started to take off internally, and honestly, like after building this thing, I think like two days after the first prototype, I started giving it To my team just for dogfitting. Because, you know, like, you know, if you come up with an idea and it seems useful, the first thing you want to do is you want to give it to people to see how they use it. And then I came in the next day and then Robert, who sits across from me, he’s another engineer, he just like had quad code on his computer and he was like using it to code. I was like, what? What are you doing? Like, this thing isn’t ready. It’s just a prototype. But yeah, it was already useful in that form factor. And I remember when we did our launch review to kind of launch quad code externally, this was in December, November or something like that in 2024. Dario asked, and he was like, the Ushis chart internally, like the DAO chart is like vertical. Are you like forcing engineers to use it? Like, why are you mandating them? And I was just like, no, no, we didn’t. I just like posted about it. And they’d just been like telling each other about it. Honestly, it was just accidental. We started with the CLI because it was the cheapest thing and it just kind of stayed there for a bit. (Time 0:06:07)
  • Keep Your QuadMD Minimal
    • Keep your context/config (QuadMD) minimal and iterate only when needed.
    • Delete and restart QuadMD if it grows noisy; add small fixes incrementally as models change. Transcript: Boris Cherny Probably the single, for me, biggest principle and product is weight and demand. And just every bit of this product is built through weight and demand after their initial CLI. And so QuadMD is an example of that. There’s this other general principle that I think is maybe interesting where you can build for the model and then you can build scaffolding around the model in order to improve performance A little bit. And depending on the domain, you can improve performance maybe 10, 20%, something like that. And then essentially the gain is wiped out with the next model. So either you can build the scaffolding and then get some performance gain and then rebuild it again, or you just wait for the next model and then you kind of get it for free. The CloudMD and kind of the scaffolding is an example of that. And really, I think that’s why we stayed in the CLI is because we felt there is no UI we could build that would still be relevant in six months because the model was improving so quickly. Other Speaker Earlier, we were saying like we should compare CloudMDs, but you said something very profound, which is, you know, yours is actually very short, which is almost like the opposite of What, you know, people might expect. Why is that? What’s in your CloudMD? Boris Cherny Okay, so I checked this before we came. So my CloudMD has two things. One is, it’s just two lines. So the first line is whenever you put up a PR, enable auto merge. So as soon as someone accepts it, it’s merged. That’s just so I can code and I don’t have to go back and forth with CR or whatever. And then the second one is whenever I put up a PR, post it in our internal team stamps channel, just so someone can stamp it and I can get unblocked. And the idea is every other instruction is in our QuadMD that’s checked into the code base. And it’s something our entire team contributes to multiple times a week. And very often I’ll see someone’s PR and they make some mistake that’s totally preventable, and I’ll just literally tag Claude on the PR. I’ll just do like add Claude, you know, like add this to the QuadMD, and I’ll do this, you know, like many times a week. Other Speaker Do you have to like compact the quad MD? Like I definitely reached a point where I got the message at the top saying your quad MD is like thousands of tokens now. What do you do when you guys hit that? Boris Cherny So our quad MD is actually pretty short. I think it’s like a couple thousand tokens, something like that. If you hit this, my recommendation would be delete your quad MD and just start fresh. Interesting. I think a lot of people like they try to over engineer this, right? And really, like, the capability changes with every model. And so the thing that you want is do the minimal possible thing in order to get the model on track. And so if you delete your QuadMD and then, you know, the model is getting off track, it does the wrong thing. That’s when you kind of add back a little bit at a time. And what you’re probably going to find is with every model, you have to add less and less. (Time 0:07:58)
  • Agent Found A Memory Leak
    • Claude analyzed a heap dump and wrote a tool to find a memory leak faster than Boris did.
    • The team repeatedly learns that agents can outperform humans on debugging tasks. Transcript: Boris Cherny And then another engineer on the team, Chris, he just asked Quad Code. He was like, hey, I think there’s a memory leak. Can you find this? And then try to figure it out. And Quad Code took the heap dump, it wrote a little tool for itself to like analyze the heap dump. And then it found the leak faster than I did. (Time 0:15:19)
  • Hire For Humility And Learnability
    • Hire people with a beginner’s mindset and intellectual humility.
    • Ask behavioral questions like “When were you wrong?” to screen for learning ability. Transcript: Other Speaker It sounds like people fresh off of school or that don’t have any assumptions might be better suited than maybe sometimes engineers who have been working at it for a long time. And how do the experts get better? Boris Cherny I think for yourself, it’s kind of beginner mindset. And I don’t know, maybe just like humility. Like I feel like engineers as a discipline, we’ve learned to have very strong opinions and senior engineers are kind of rewarded for this. In my old job at a big company, when I hired like architects and this kind of a type of engineer, you look for people that have a lot of experience and really strong opinions. But it actually turns out a lot of this stuff just isn’t relevant anymore. And a lot of these opinions should change because the model is getting better. So I think actually the biggest skill is people that can think scientifically and can just think from first principles. Other Speaker How do you screen for that when you try to hire someone now for your team? Boris Cherny I sometimes ask about what’s an example of when you’re wrong. It’s a really good one. Some of these classic behavioral questions, not even coding questions, I think are quite useful. Because you can see if people can recognize their mistake in hindsight, if they can claim credit for the mistake and if they learn something from it. And I think a lot of these like very senior people, especially there are some founder types like this, but I think founders in particular are actually quite good at it. But other people sometimes will never really take, they’ll never take the blame for a mistake. But I don’t know, like for me personally, I’m wrong probably half the time. Like half my ideas are bad and you just have to try stuff. And, you know, you try a thing, you give it to users, you talk to users, you learn. And then eventually you might end up at a good idea. Sometimes you don’t. (Time 0:15:52)
  • Automate Repetitive Dev Work
    • Automate repetitive development workflows with agents and SDKs.
    • Use agents to handle code review, security review, labeling, and shepherding to production. Transcript: Boris Cherny It automates code review, security review. It labels all of our issues. It shepherds things to production. It does pretty much everything for us. But I think externally, I’m seeing a lot of people start to figure this out. But it’s actually taken a while to figure out how do you use LMs in this way? How do you use this new kind of automation? (Time 0:20:21)
  • Plugins Built By Agent Swarm
    • The plugins feature was built by a swarm of agents over a weekend with minimal human intervention.
    • Engineers gave a spec and agents created tickets and executed tasks autonomously. Transcript: Boris Cherny It just ran for like a few days. There wasn’t really human intervention. Other Speaker And plugins is pretty much in the form that it was when it came out. How did you set that up? Like, did you spec out sort of the outcome that you were hoping for and then let it sort of figure out the details and then, like, let it run? Boris Cherny Yeah, an engineer on the team just gave Quad a spec and told Quad to use a Asana board. And then Quad just put up a bunch of tickets on Asana and then spawned a bunch of agents, and the agents started picking up tasks. (Time 0:22:45)
  • Exploit Latent Demand
    • Chase latent demand: make what people already try to do much easier.
    • Observe current user behavior and remove friction rather than inventing new habits. Transcript: Boris Cherny I think some of these are pretty basic, but I think they’re even more important now than they were before. So one example is latent demand. Like I mentioned it a thousand times for me, it’s just like the single biggest idea in product. It’s a thing that no one understands. It’s a thing I certainly did not understand my first few startups. And the idea is like people will only do a thing that they already do. You can’t get people to do a new thing. If people are trying to do a thing and you make it easier, that’s a good idea. But if people are doing a thing and you try to make them do a different thing, they’re not going to do that. And so you just have to make the thing that they’re trying to do easier. And I think Quad is going to get increasingly good at kind of figuring out these kind of product ideas for you just because it can look at feedback, it can look at debug logs, like kind of Figure this out. (Time 0:28:48)
  • Terminal Persisted Unexpectedly
    • The terminal unexpectedly remained a powerful, long-lived interface for agent-driven coding.
    • Multiple form factors exist, but CLI kept relevance due to rapid iteration and developer habits. Transcript: Boris Cherny Funny. If you asked me this a year ago, I would have said the terminal has like a three-month lifespan and then we’re going to move on to the next thing. And you can see us experimenting with this, right? Because Quad Code started in a terminal, but now it’s on web. Like Quad IIS hash code, it’s in the desktop app. We’ve had that for like three months or six months or something, just in the code tab. It’s in the iOS and Android apps, just like in the code tab. It’s in Slack. It’s in GitHub. There’s VS Code extensions. There’s JetBrains extensions. So we’re just like, we’re always experimenting with different form factors for this thing to figure out what’s the next thing. I’ve been wrong so far about the lifespan of the CLI, so I’m probably not the person to forecast that. (Time 0:30:18)
  • Don’t Bet Against The Model
    • Never bet against the model; prefer general models over narrow handcrafted features.
    • Evaluate scaffolding as temporary tech debt and invest only when necessary. Transcript: Boris Cherny Would say, so, okay, so maybe two pieces of advice that are kind of weird because it’s like about building for the model. So one is don’t build for the model of today, build for the model of six months from now. This is like sort of weird, right? Because like you can’t find PMF if the product doesn’t work, but actually this is the thing that you should do because otherwise what will happen is you spend a bunch of work, you find PMF for the product right now, and then you’re just going to get leapfrogged by someone else because they’re building for the next model and a new model comes out every few months. Use the model, feel out the boundary of what it can do, and then build for the model that you think will be the model maybe six months from now. I think the second thing is, you know, actually in the quad code area where we sit, we have a framed copy of The Bitter Lesson on the wall. And this is this like Rich Sutton block post. Like everyone should read it if you haven’t. And the idea is the more general model will always be the more specific model. And there’s a lot of corollaries to this, but essentially what it boils down to is never bet against the model. And so this is just like a thing that we always think about where we could build a feature into quad code. We could make it better as a product and we call this scaffolding. That’s all this code. That’s not the model itself. But we could also just wait like a couple months and the model can probably just do the thing instead. And there’s always this trade-off, right? It’s like engineering work now, and you can kind of extend the capability a little bit, maybe 10, 20% or whatever in whatever domain on this spider chart of what you’re trying to extend. Or you can just wait and the next model will do it. So just always think in terms of this trade-off. Where do you actually want to invest? And assume that whatever the scaffolding is, it’s just tech debt. (Time 0:37:43)
  • Coding Done Entirely By Agent
    • Boris now writes 100% of his code via QuadCode since Opus 4.5 and uninstalled his IDE.
    • Anthropic teams report 70–90% of code generated by Quad, with some teams at 100%. Transcript: Boris Cherny So Dario predicted that 90% of the code at Anthropic would be written by quad. This is true. For me personally, it’s been 100% since Opus 4.5. I uninstalled my IDE. I don’t edit a single line of code by hand. It’s just 100% quad code in Opus. And I land 20 PRs a day every day. If you look at Anthropic overall, it ranges between 70% to 90%, you know, depending on the team. For a lot of teams, it’s also like 100%. For a lot of people, it’s 100%. And I remember making this prediction back in May when we GA’d quad code that you wouldn’t need an ID to code anymore. And it was totally crazy to say, I feel like people in the audience gasped because it was such like a silly prediction at the time. But really all it is, is like, you just like trace the, you know, the exponential. And this is just like so deep in the DNA at Ant because like three of our founders were co-authors of the scaling loss paper. They saw this very early. And so this is just like tracing the exponential. This is what’s going to happen. And yes, that happened. So continuing to trace the exponential, I think what will happen is coding will be generally solved for everyone. And I think today coding is practically solved for me. (Time 0:43:45)
  • Wrap Agents For Nontechnical Users
    • Build GUIs for nontechnical users by wrapping agent logic, not reimplementing core agent behavior.
    • Add VM sandboxing, permission prompts, and guardrails to make agents safe for broader audiences. Transcript: Other Speaker And where do you think that goes? Boris Cherny This is going to be my fifth time using the word wait and demand. It was just that. We were looking at Twitter and there was that one guy that was using QuadCode to monitor his tomato plants. There was this other person that was using it to recover wedding photos off of a corrupted hard drive. There were people that were using it for finance. When we looked internally at Anthropic, every designer is using it. The entire finance team at this point is using it. The entire data science team is using it not for coding. People are jumping over hoops to install a thing in the terminal so that they could use this. So we knew for a while that we wanted to build something. And so we’re experimenting with a bunch of different ideas. And the thing that kind of took off was just a little quad code wrapper in a GUI in the desktop app. And that’s all it is. It’s just quad code under the hood. It’s the same agent. Oh, wow. And Felix and the team, and Felix was an early electron contributor. He kind of knows that stack really well when he was hacking on various ideas. And they built it in, I think, something like 10 days. It was just like 100% written by quad code. And it just felt ready to release. There was a lot of stuff that we had to build for non-technical users. So it’s a little bit different than technical audience. It runs in a, all the code runs in a virtual machine. There’s a lot of protections for deletion and things like this. (Time 0:48:08)