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 Claude Code has just been written and rewritten and rewritten over and over and over. There is no part of Claude 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.
Are you also in the back of your mind thinking that maybe in six months you won't need to prompt that explicitly? Like the model will just be good enough to figure it out on its own?
Maybe in a month. No more need for plan mode in a month.
Oh my god.
Welcome to another episode of the Lightcone, and today we have an extremely special guest, Boris Cherny, the creator and engineer of Claude Code. Boris, thanks for joining us.
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, for months at this point? I think it was like end of November is where a lot of my friends said like something changed.
I remember for me I felt this way when I first created Claude Code and I didn't yet know if I was on to something. I kind of felt like I was on to something and then that's when I wasn't sleeping.
And that was just like three straight months.
Yeah. 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, 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, what would be 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 at the beginning it didn't really write code. Even in February when we launched, 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 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 still my advice to founders that are building on LLMs, is 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 and you just have to wait.
Going back though, do you remember when you first got the idea? Can you just talk us through that? Like was it some kind of spark, or what was even the first version of it in your mind?
You know, it's funny. It was so accidental that it just kind of evolved into this. You know, as Anthropic, I think 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 Claude Code, MCP, and the desktop app. So you can kind of see how these weave together. The particular product that we built, you know, 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 the product that harnessed this capability. So still there's this insane feeling of product overhang. But at the time it was just like even crazier because no one had built this yet. And so I started 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 Anthropic's API at that point.' And so I just built a little terminal app to use the API. That's all that I did. And it was a little chat app because you think about the AI applications of the time, and for non-coders today, most people are using just a chat app. So that's what I built. And it was in a terminal. I could ask questions, I'd get answers. Then I think tool use came out. I just wanted to try out tool use because I didn't really understand what this is. I was like, 'Tool use, this is cool. Is this actually useful? Probably not. Let me just try it.'
You built it in terminal just because it was the easiest way to get something up and running.
Yes. Because I didn't have to build a UI.
At that point, it was like the IDEs, Cursor, Windsurf taking off. Were you sort of under any pressure or getting lots of suggestions of, 'Hey, we should build this out as a plugin or as a fully featured IDE itself?'
There was no pressure because we didn't even know what we wanted to build. The team was just in explore mode. We knew vaguely we wanted to do something in coding, but it wasn't obvious what. No one was high confidence enough. That was my job to figure out. And so I gave the model the bash tool. That was the first tool that I gave it, just because I think that was literally the example in our docs. I just took the example. It was in Python. I just ported it to TypeScript because that's how I wrote it. I didn't know what the model could do with bash. So I asked it to read a file. It could cat the file. So that was cool. And then I was like, 'Okay, what can you actually do?' And I asked it, 'What music am I listening to?' It wrote some AppleScript to script my Mac and look up the music in my music player.
And this was Sonnet 3.5.
And you know, I didn't think the model could do that. And that was my first, I think, ever 'feel the AGI' moment where I was just like, 'Oh my god, the model just wants to use tools. That's all it wants.'
That's kind of fascinating. I mean, it's very kind of contrarian that Claude Code works so well in such an elegant, simple form factor. I mean, terminals have been around for a really long time, and that seemed to be like a good design constraint that allowed a lot of interesting developer experiences. Like, it doesn't feel like working. It just feels fun as a developer. I don't think about files, where everything is, and that came by accident almost.
Yeah, 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 dogfooding, because 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, who's another engineer, he just had Claude Code on his computer and he was using it to code. I was like, 'What are you doing? 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 Claude Code externally, this was in December, November, something like that in 2024. Dario asked, and he was like, 'The usage chart internally, the DAU chart is vertical. Are you forcing engineers to use it? Why are you mandating it?'
And I was just like, 'No, no, we didn't. I just posted about it and they've just been 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.
So in that 2024 period, how were the engineers using it? Were they sort of shipping code with it yet, or were they using it in a different way?
The model is not very good at coding yet. I was using it personally for automating git. I think at this point I've probably forgotten most of my git because Claude Code has just been doing it for so long. But yeah, automating bash commands, that was a very early use case, and operating Kubernetes and things like this. People were using it for coding. So there were some early signs of this. I think the first use case was actually writing unit tests because it's a little bit lower risk and the model was still pretty bad at it, but people were figuring it out and they were figuring out how to use this thing.
And one thing that we saw is people started writing these markdown files for themselves and then having the model read that markdown file. And this is where CLAUDE.md came from. Probably the single biggest principle for me in product is latent demand. And just every bit of this product is built through latent demand after the initial CLI. And so CLAUDE.md 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 CLAUDE.md 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 was no UI we could build that would still be relevant in six months because the model was improving so quickly.
Earlier we were saying we should compare CLAUDE.md's, but you said something very profound, which is yours is actually very short, which is almost the opposite of what people might expect. Why is that? What's in your CLAUDE.md?
Okay, so I checked this before we came. So my CLAUDE.md has two lines. One is, it's just two lines. So the first line is whenever you put up a PR, enable automerge. 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 CLAUDE.md that's checked into the codebase, 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 this to the CLAUDE.md,' and I'll do this many times a week.
Do you have to compact the CLAUDE.md? Like I definitely reached a point where I got the message at the top saying your CLAUDE.md is like thousands of tokens now. What do you do when you guys hit that?
So our CLAUDE.md is actually pretty short. I think it's like a couple thousand tokens, maybe something like that. If you hit this, my recommendation would be delete your CLAUDE.md and just start fresh.
I think a lot of people try to overengineer this, right? And really, the capability changes with every model. And so the thing that you want is to do the minimal possible thing in order to get the model on track. And so if you delete your CLAUDE.md and then 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. For me, I consider myself a pretty average engineer, to be honest. Like I don't use a lot of fancy tools. I don't use Vim. I use VS Code because it's simpler. I don't really...
Wait, really? I would have assumed that because you built this in the terminal that you were sort of like a die-hard terminal, Vim-only person. You know, screw those VS Code people.
Well, we have people like that on the team. There's, you know, like Adam Wolf, for example. He's on the team. He's like, 'You will never take Vim from my cold dead hands.' So there's definitely a lot of people like that on the team. And this is one of the things that I learned early on, is every engineer likes to hold their dev tools differently. They like to use different tools. There's just no one tool that works for everyone. But I think also this is one of the things that makes it possible for Claude Code to be so good, because I kind of think about it as what is the product that I would use that makes sense to me. And so to use Claude Code, you don't have to understand Vim, you don't have to understand tmux, you don't have to know how to SSH, you don't have to know all this stuff. You just have to open up the tool and it'll guide you, it'll do all this stuff.
How do you decide how verbose you want the terminal to be? Like sometimes you have to go, you know, Ctrl+O and check it out. Is it like internal bikeshed battles around longer, shorter? I mean, every user probably has an opinion. How do you make those sorts of decisions?
What's your opinion? Is it too verbose right now?
Oh, I love the verbosity because basically sometimes it just goes off the deep end and I'm watching and then I can just read very quickly and it's like, 'Oh, no, no, it's not that.' And then I escape and then just stop it and then it just stops an entire bug farm as it's happening. I mean, that's usually when I didn't do plan mode properly.
This is something that we probably change pretty often. I remember early on, this is maybe six months ago, I tried to get rid of bash output just internally, just to summarize it, because I was like, these giant long bash commands, I don't actually care. And then I gave it to Anthropic employees for a day and everyone just revolted. 'I want to see my bash,' because it actually is quite useful for, you know, like for something like git output, maybe it's not useful, but if you're running, you know, Kubernetes jobs or something like this, you actually do want to see it. We recently hid the file reads and file searches. So you'll notice instead of saying, you know, like 'read foo.md', it says, you know, like 'read one file', 'searched one pattern'. And this is something I think we could not have shipped six months ago because the model just was not ready. It would have, you know, it still read the wrong thing pretty often. As a user, you still had to be there and kind of catch it and debug it. But nowadays, I just notice it's on the right track almost every time. And because it's using tools so much, it's actually a lot better just to summarize it. But then we shipped it. We dogfooded it for like a month and then people on GitHub didn't like it. So there was a big issue where people were like, 'No, I want to see the details.' And that was really great feedback. And so we added a new verbose mode. And so that's just like in /config, you can enable verbose mode. And if you want to see all the file outputs, you can continue to do that. And then I posted on the issue and people still didn't like it, which is again awesome because like my favorite thing in the world is just hearing people's feedback and hearing how they actually want to use it. And so we just iterated more and more and more to get that really good and to make it the thing that people want.
I'm amazed how much I enjoy fixing bugs now. And then all you have to do is have really good logging and then even just say like, 'Hey, check out this particular object, it messed up in this way,' and it searches the log. It figures everything out. It can go into your... you can make a production tunnel and it'll look at your production DB for you. It's like, this is insane. Bug fixing is just going to Sentry, copy markdown. You know, pretty soon it's just going to be straight MCP. It's like an auto bug-fixing and test-making sort of... what's the new term they call it? Like making a startup factory.
Right. There's like all these concepts now of rather than having to review the code, you know, I'm old school, so I like the verbosity. I like to say, 'Oh, well, you're doing this, but I want you to do that.' Right? But there's a totally different school of thought now that says like anytime a real human being has to look at code, that's bad.
I think like Dan Chipper talks about this a lot as kind of whenever you see the model make a mistake, try to put it in the CLAUDE.md, try to put it in like skills or something like that so it's reusable. But I think there's this meta point that I actually struggle with a lot. And people talk about like agents can do this, agents can do that, but actually what agents can do, it changes with every single model. And so sometimes there's a new person that joins the team and they actually use Claude Code more than I would have used it.
And I'm just constantly surprised by this. Like for example, we had a memory leak and we were trying to debug it. And by the way, like Jared Sumar has just been on this crusade killing all the memory leaks and it's just been amazing. But before Jared was on the team, I had to do this and there was this memory leak. I was trying to debug it. And so I took a heap dump. I opened it in DevTools. I was looking through the profile. Then I was looking through the code and I was just trying to figure this out. And then another engineer on the team, Chris, he just asked Claude Code. He was like, 'Hey, I think there's a memory leak. Can you run this and try to figure it out?' And Claude Code took the heap dump. It wrote a little tool for itself to analyze the heap dump. And then it found the leak faster than I did. And this is just something I have to constantly relearn because my brain is still stuck somewhere six months ago at times.
So what would be some advice for technical founders to really become maximalists at the latest model release? 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?
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 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.
How do you screen for that when you try to hire someone now for your team?
I sometimes ask about what's an example of when you're wrong. It's a really good one. You know, some of these like classic behavioral questions, like 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 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. And this is the skill that I think in the past was very important for founders, but now I think it's very important for every engineer.
Do you think you would ever hire someone based on the Claude Code transcript of them working with the agent? Because we're actively doing that right now. We just added, just as a test, like you can upload a transcript of you coding a feature with Claude Code or Codex or whatever it is.
Personally, I think that it's going to work. I mean, you can figure out how someone thinks, like whether they're looking at the logs or not, like can they correct the agent if it goes off the rails? Like, do they use plan mode? You know, when they use plan mode, do they make sure that there are tests or, you know, all of these different things that...
You know, do they think about systems? Do they even understand systems? Like, there's just so much that's sort of embedded in that that I imagine. I just want like a spiderweb graph, you know, like in those video games like NBA 2K. It's like, 'Oh, this person's really good at shooting or defense.' It's like you could imagine a spiderweb graph of like, you know, someone's Claude Code skill level.
Yeah. What would the skills be? What would be those?
I mean, I think it's like systems, testing, must be like user behavior. I mean, there's got to be a design part, like product sense, maybe also just like automating stuff. My favorite thing in CLAUDE.md for me is I have a thing that says for every plan, decide whether it's overengineered, underengineered, or perfectly engineered and why.
I think this is something that we're trying to figure out too, because I think when I look at engineers on the team that I think are the most effective, there's essentially two, it's very bimodal. There's one side where it's extreme specialists. And so like I named Jared before, like he's a really good example of this and kind of the Bun team is a really good example. Just hyper specialists. They understand dev tools better than anyone else. They understand JavaScript runtime systems better than anyone else. And then there's the flip side of kind of hyper generalists and that's kind of the rest of the team. And a lot of people, they span like product and infra or product and design or, you know, like product and user research, product and business. I really like to see people that just do weird stuff. I think that's one of these things that was kind of a warning sign in the past because it's like, can these people actually build something useful?
Yeah, that's what it must be. But nowadays, like for example, an engineer on the team, Daisy, she was on a different team and then she transferred onto our team. And the reason that I wanted her to transfer is she put up a PR for Claude Code like a couple weeks after she joined or something. And the PR was to add a new feature to Claude Code. And then instead of just adding the feature, what she did is first she put up a PR to give Claude Code a tool so that it can test an arbitrary tool and verify that that works. And then she put up that PR and then she had Claude write its own tool instead of herself implementing it. And I think it's this kind of out-of-the-box thinking that is just so interesting because not a lot of people get it yet. You know, like we use the Claude Agents SDK to automate pretty much every part of development. 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 LLMs in this way? How do you use this new kind of automation? So it's kind of a new skill.
I guess one of the funnier things that I've been having office hours with various founders about is you have like sort of the visionary founder who has like the idea, they've built this like crystal palace of the product that they want to build. They've totally loaded in their brain, you know, who the user is and what they feel and what they're motivated by. And then they're sitting in Claude Code and they can do like, you know, 50x work. And then but they have engineers who work for them who like don't have the, you know, crystal memory palace of like the platonic ideal of the product that the founder has and they can only do like 5x work. Are you hearing stories like that?
There's usually a person who's like the core designer of a thing and they're just like, you know, trying to blast it out of their brain. What's the nature of like teams like that? You know, it seems like that's almost a stable configuration. Like you're going to have the visionary who like now is unleashed, but you know, maybe going back to the top of it, like I'm experiencing this right now. I was like, 'Oh, well, I'm only a solo person and you know, I need to eat and sleep and I have, you know, a whole job. It's like, how am I going to do this?' You know, like we just launched Claude Teams and, you know, this is a way to do it, but you can also just build your own way to do it. It's pretty easy.
What's the vision for Claude Teams?
Just collaboration. It's like there's this whole new field of like agent topologies that people are exploring. Like what are the ways that you can configure agents? There's this one sub-idea which is uncorrelated context windows. And the idea is just multiple agents, they have fresh context windows that aren't essentially polluted with each other's context or their own previous context. And if you throw more context at a problem, that's like a form of test-time compute. And so you just get more capability that way. And then if you have the right topology on top of it, so the agents can communicate in the right way, they're laid out in the right way, then they can just build bigger stuff. And so Teams is kind of like one idea. There's a few more that are coming pretty soon. And the idea is just maybe it can build a little bit more. I think the first kind of big example where it worked is our plugins feature was entirely built by a swarm over a weekend. It just ran for like a few days. There wasn't really human intervention. 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?
Yeah. An engineer on the team just gave Claude a spec and told Claude to use an Asana board. And then Claude just put up a bunch of tickets on Asana and then spawned a bunch of agents and the agents started picking up tasks. The main Claude just gave it instructions and they all just figured it out.
Like independent agents that didn't have the context of the bigger spec.
Right. If you think about the way that our agents actually start nowadays, and I haven't pulled the data on this, but I would bet the majority of agents are actually prompted by Claude today in the form of sub-agents, because like a sub-agent is just like a recursive Claude Code. That's all it is in the code. And it's just prompted by, we call her Mama Claude.
And that's all it is. And I think probably if you look at most agents, they're launched in this way.
My Claude Insights just told me to do this more for debugging so that I get... I spend a lot of time on debugging and it would just be better to have like multiple sub-agents spin up and debug something in parallel. And so then I just added that to my CLAUDE.md to just be like, 'Hey, next time you try and fix a bug, have one agent that looks in the log, like one that looks in the code path.' That just seems sort of inevitable.
For weird scary bugs, I try to fix bugs in plan mode and then it seems to use the agents to sort of search everything. Whereas like when you're just trying to do it in line, it's like, 'Okay, I'm going to do like this one task' instead of search wide. This is something I do all the time too. I just say if the test seems kind of hard, this kind of research test, I'll calibrate the number of sub-agents I ask it to use based on the difficulty of the task.
So if it's like really hard, I'll say like use three or maybe five or even 10 sub-agents, research in parallel and then see what they come up with.
I'm curious. So then why don't you put that in your CLAUDE.md file?
It's kind of case by case, you know, like CLAUDE.md, what is it? It's just a shortcut. Like if you find yourself repeating the same thing over and over, you put it in the CLAUDE.md. But otherwise, you don't have to put everything there. You can just prompt Claude.
Are you also in the back of your mind thinking that maybe like in six months, you won't need to prompt that explicitly? Like the model will just be good enough to figure it out on its own.
No more need for plan mode in a month.
