Inside Claude Code With Its Creator Boris Cherny

And then 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 like still my advice to founders that are building on LLMs. 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. All of Quad Code has just been written and rewritten and rewritten and rewritten over and over and over. There's no product quad code that was around six months ago. You try to think, you give it to users, you talk to users, you learn. And then eventually you might end up with a good idea. Sometimes you don't. You also in the back of your mind thinking that maybe like in six months you won't need to prompt that explicitly. But the model is good enough to grow on its own. Maybe in a month. You're working for a plan mode in a month? Oh my god. Welcome to another episode of The Lightconn. And today we have an extremely special guest, Boris Cherny, the creator, engineer of Quad 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 Quad 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. I remember for me I felt this way when I first created Quad Code 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 the rest of the month. This was September 2024. Yeah, it was like three straight months. I didn't take a single day of vacation, work 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 some believeable 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 created a route 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 said we're almost in 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 was not obvious. At Anthropic the way that we thought about it is we don't build for the model of today. And that's actually like still my advice to founders that are building on LLM's 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. Going back but when Jimi when you first got the idea you just took us through that. Like was it something like a spark or what was even the first version of it in your mind? You know it's funny it was like it was so accidental that it just kind of evolved into this. You know as Anthropic I think for Ant that bet has been coding for a long time and the bet has been the path to save to save a GI is through coding. And this is 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 this was the Anthropic Lab team and it produced three products. It was quad code MCP and the desktop app. So you can kind of see how these like weave together. The particular product that we built you know like 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 harness 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 built 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 API at that point. And so I just built like a little terminal app to use the API that's all that it did and it was a little chat app because you know like you think about the you know AI applications at the time and you know for non-coders today most what are most people using is just a chat app so that's what I built. And you know it was an terminal I can ask questions I gave answers. Then I think tool use came out I just want to try out tool use because I don't really understand what this is I was like 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 the build the UI. Okay. So it was just me. At that point it was like the IDE's cursor, Winsor for the things that were really taking off where you sort of under any pressure or getting lots of suggestions of hey like we should build this out as a plugin or as a flea featured IDE itself. There was no pressure because we didn't even know what we wanted to build. Like the team was just an explorer mode you know like we didn't we know vaguely we wanted to do something encoding but it was obvious what no one was high confidence enough that was like 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 a literary example in our docs. It just like ticked examples in Python I just ported it to TypeScript because that's how I wrote it. You know I didn't know like what the model could do with bash so I asked it to like read a file it could like cat the files like that was cool. And then I was like okay like what can you actually do and I asked it what music am I listening to? You wrote some like Apple script to script my my Mac and look up the music in my music player. Oh my god. And this was sauna 3.5. You know like I didn't think the model could do that. And that was my first I think ever feel the age I moment. It's like oh my god the model it just wants to use tools. That's how it wants. That's kind of fascinating. I mean it's very kind of contrarian that clockwork so well in such a elegant simple form factor. I mean terminals happen around for a really long time and that seemed to be like a good design constraint that allowed a lot of interesting developer experiences. It doesn't feel like working it just feels fun as a developer. I didn'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 and turn away 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 dog fitting 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. 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 quad code externally this was in December November or something like that in 2024. Dario asked and he was like the easiest chart internally like the the Dow chart is like vertical. Are you like forcing engineers to use it? Like why are you mandating them? And it was just like no no we didn't 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 see like it was the cheapest thing and it just kind of stayed there for a bit. So in that 2024 period so what how the engine is using it? Whether it's a shipping code with it yet or whether 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 probably forgotten most of my Git because quad code has been doing it for so long. But yeah like automating bash commands though that was a very early use case and like operating like Kubernetes and kind of things like this. People were using it for coding. So there was 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 is still pretty bad at it. But people were kind of 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 QuadMD came from. Probably the single for me biggest principle in 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 you know 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 QuadMD and kind of this 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. Earlier we were saying like we should compare cloud MDS 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 cloud MDS? Okay so I check this before we can. So my QuadMD has two things. One is there it is just two lines. So the first line is whenever you put up a PR enable auto merge. So soon as someone accepts it it's merged. That's just so I can like code and I don't have to kind of go back and forth with CR or whatever. And then the second one is whenever I put up a PR posted 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 cloud on the PR. I'll just do like at cloud you know like add this to the QuadMD and I'll do this you know like many times a week. Do you have to like compact the QuadMD? Like I've definitely reached a point where I got the message at the top saying your QuadMD is like thousands of tokens now. What do you do when you guys hit that? So our QuadMD is actually pretty short. I think it's like a couple thousand tokens or something like that. If you hit this my recommendation would be to delete your QuadMD 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're gonna add back a little bit out of time. And we are probably gonna 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 like I don't use like them I use you know VS code because it's some for I don't really really I would have assumed that because you built this in the terminal that you were sort of like a diehard terminal like them them only person you know screw those VS code 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 them from a cold dead hand. Yeah so there's definitely a lot of people like that on the team and this is one of the things that I wonder we on is every engineer likes to hold their DevTools 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 Quad 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 Quad Code you don't have to understand them you don't have to understand T-Mox you don't have to know how to like as I say you don't have to know all the stuff you just have to open up the tool and it'll guide you it'll it'll do all this stuff. How do you decide how verbose you want like sort of the terminal to be like sometimes you have to go you know control O and check it out and is it like internal bike shed battles around like longer or shorter I mean every user probably has a different opinion like how do you make those sorts of decisions. What's your opinion is it is a two verbose right now? Oh I love the verbosity because basically sometimes it just like 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 like stops an entire bug farm like 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 like summarize it because I was like is giant long bash commands I don't actually care and then I give it to anthropic employees for a day and everyone just revolted. I want to see my dash 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 like Kubernetes jobs or something like that so you actually do want to see it. We recently hit the hit the file reads and file searches so you'll notice instead of saying you know like red food.md it'll said you know like red one file search one pattern and this is something I think we could not have shipped six months ago because the model just was not ready you would have you know it's still read the wrong thing pretty often as a user you still have to be there and kind of catch it and debug it but nowadays I just noticed it's on the ray 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 dog fooded it for a command and then people on GitHub didn't like it so there was a big issue where people like no like I want to see the details and that was a really great feedback and so we added a new verbose mode and so that's just like in swash config you can enable verbose mode and if you want to see all the file uploads you can continue to do that and then I post on the issue and people still 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 like iterated more and more and more together really good and to make it the thing that people want I'm amazed like 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 that you know this particular object it messed up in this way and it like searches the log it figures everything out it can like go into your you can make a production tunnel and look at your production DB for you it's like this is insane bug fixing is just going to century copy markdown you know pretty soon it's just gonna be straight mcp it's like an auto bug fixing like and test making sort of what's the new term they call it like a making a startup factory yeah right there's like all these concepts now of rather than having to review the code you know I'm 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 an end a real human being has to look at code that's bad yeah yeah yeah and I'm fascinating I think like dentshipper talks about this a lot as kind of whenever you see the model make a mistake try to put in the quad Md try to put it in like skills or something like this what'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 quad code more than I would have used it and I'm just constantly surprised by this like for example there was a we had like a memory week and we were trying to debug it and by the way like Jared some of our has just been on this crusade killing all the memory weeks and it's just been amazing but before Jared was on the team I had to do this and there was this memory week I was trying to debug it and so I took a heap dump I opened it in DevTools as 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 like asked quad code he was like hey I think there's a memory week and you like that and then like try to figure it out and quad code like took the heap dump it wrote a little tool for itself to like analyze the heap dump and then it found the week faster than I did and this is just something I have to constantly re-learn because my brain is still stuck somewhere six months ago at times so what would be some advice for technical founders to really become maximalist at the latest model release it sounds like people off of 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 it's 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 scale 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 when you're wrong it's really good on 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 to think 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 cloud code transcript of them working with the agent because we're asking for doing that right now we just added just as a test like you can upload a transcript of you coding a feature with cloud code or codex or whatever it is personally I think that like 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 off the rails like does do they use plan mode you know when they use plan mode do they make sure that they're tests or you know all 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 spider a spider web graph you know like in those video games like NBA 2k and it's like oh this person is really good at shooting or defense like you can imagine a spider web graph of like you know someone's cloud code skill level yeah well with it will the skills be will be those I mean I think it's like systems testing must be like user behave I mean there's got to be a design part you're like product sense but yeah probably just like automating stuff mm-hmm my favorite thing in cloud md for me is I have a thing that says for every plan decide whether it's over engineered under engineered 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 by model there's one side where to extreme specialists and so I can aim Jared before I keys a really good example of this and kind of the bun team is a really good example just hyper specialist 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 genera list and that's kind of the rest of the team and a lot of people they span like product and in for 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 in these people actually build something useful mm-hmm that's the limits test yeah that's the limits test but but nowadays it like for example an engineer on the team daisy she was on a different team and then she transferred on to our team and the reason that I wanted her to transfer is she put up a PR for quad code like a couple weeks after she joined or something and the PR was to add a new feature to quad code and then instead of just adding the feature which it is first she put up a PR to give quad 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 quad write its own tool instead of first self implementing it and I think it's this kind of out of the box thinking that is is just so interesting because not a lot of people get it you know like we use the quad agent SDK to automate pretty much every part of development it automates code review security review it labels over 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 elems 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 like built this like crystal palace of how 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 cloud code and they can do like you know 50 x 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 product founder has and they can only do like five x work are you hearing stories like that there's usually a person who's like the core like 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 gonna 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 it's 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 and I'm like how am I gonna do this you know you know like we just want to quad teams 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 cloud teams this collaboration it's like there's this whole new field of like agent apologies that people are exploring like what are the ways they can configure agents there's this one sub idea which is uncorrelated context windows and that is just multiple agents they have fresh context windows that aren't as actually 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 and compute and so you just get more capability that way and then if you have the right to apology on top of it so the agents can communicate in the right way they're weighed 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 over a weekend we just ran for 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 and engineer on the team just gave gave quad a spec and told quad to use a a son of word and then quad just put up a bunch of tickets on a son and then spawn a bunch of agents and the agents started picking up tasks the main quad just gave it instructions and they all just figured it out independent agents that didn't have the context of the bigger spec right right if you think about the way that uh you know like how are agents actually started nowadays and you know I haven't pulled the data on this but I would bet the majority of agents are actually prompted by quad today in the form of sub agents because like a sub agent is just like a recursive quad code that's all it is in the code and it's just prompted by we call her mama quad 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 like I spend a lot of time on debugging and it would just be better to have like multiple sub agents spin up and like debug something in parallel and so then I just like added that to my Claude MD to just be like hey like next time you try and fix a bug like have one agent that like 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 gonna do like this one task instead of search wide this is something I do all the time too I just say if the if the task seems kind of hard this kind of research task I'll calibrate the number of sub agents that I ask you 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 from 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 quite MD like what is it it's just a it's a shortcut like if you find yourself repeating the same thing over and over you put in the quite MD but otherwise you don't have to put everything there you can use prompt quad you also in the vacuum line thinking that maybe like in six months you won't need to prompt that explicitly the model would be good enough to grow in time maybe in a month no money for plan mode oh my god I think plan mode probably has a limited vice fan interesting yeah some alpha for everyone here what would the world look like without plan mode you just describe it at the prompt level and it would just do it one shot it yeah we've we've started experimenting with this because Claude code can now enter plan mode by itself I don't know if you've got you guys actually in that yeah so we're trying to kind of get this experience really good so it would enter plan mode the same point where a human would have wanted to enter it so I think it's like I think it's something like this but actually plan mode there's no there's no big secret to it all it does is it adds one sentence to the prompt that's like please don't code that's all this you can you can actually just say that yeah so it sounds like a lot of the feature development for clock code is very much when we talk about a YC talk to your users and then you come and implement it it wasn't the other way that you had this master plan and then implement it all the features yeah yeah I mean that's all it was like plan mode was we saw users that that were like a quad come up with an idea plan the cell but don't write any code yet and there was kind of various versions of this sometimes it was just talking through an idea sometimes it was these very sophisticated specs that they were asking for to write but the common dimension was do a thing without coding yet and so what are you like this was like Sunday night at 10 pm I was I was just like looking at GitHub issues and kind of seeing what people were talking about and looking at our internal swak feedback channel and I just wrote this thing in like 30 minutes and then shipped it that night it went out Monday morning it was plan mode so do you mean that there will be no need for plan mode so in the sense of I'm worried that the model is going to do like it's going to do like the wrong thing or head off in the wrong direction but there will still be a need for that you need to think through the idea and figure out exactly what it is that you want and you have to do that somewhere I kind of think about it in terms of like kind of increasing model capabilities so maybe six months ago a plan was insufficient so you get quad to make a plan was even with plan mode used to have to kind of sit there and maybe sit because it can go off track now what is what I do is probably 80% of my sessions I say I say plan mode has a limited way to spend but I am a heavy plan mode user I probably 80% of my sessions I sort of plan mode in quad will you know little story will start making plan I'll move on to my second terminal tab and then I'll have it make another plan and then when I run out of tabs I open the desktop app and then I go to the co-tab and then I just start a bunch of tabs there and they all start in plan mode probably you know like 80% of the time once the plan is good and sometimes it takes a little back and forth they just get quad to execute and nowadays what I find with opus 4.5 I think it started with 4.6 it got really good once the plan is good it just stays on track and it'll just do the thing exactly right almost every time and so you know before you had to babysit after the plan and before the plan now it's just before the plan so maybe the next thing is you just won't have to babysit you can just kind of give a prompt and quad will figure it out the next step is cloud just speaks to your users directly just bypasses you entirely it's funny this is actually the current stuff for us or quad's actually like they talk to each other they talk to our users on swag at least internally pretty often my quad will like tweet once in a while no way but I actually like delete it it's just like it's a little like cheesy yeah like I don't love the tone what does it want to tweet about sometimes it will just like respond to someone because I always have like co-work running in the background and it's like it's the co-work cloud that really loves to do that because it likes using a browser that's funny I really comment pattern as I ask quad to build something it'll look in the code base it'll see some engineer touch something in the get blame and then it'll message that engineer on swag just like asking a clarifying question and then once it gets to answer back it'll keep going what are some tips for founders now on how to build for the future sounds like everything is really changing what are like some principles that will stay on and what will change so I think some of these are pretty are pretty basic but I think they're even more important now than they were before so one example is latent demands like I mentioned it a thousand times for me it's just like the single biggest idea in product it's a 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 it kind of figure this out that's what you mean by a plan made was latent demand that people were ready like and they had their clawed chat window open in the browser and we're like talking to it to figure out like the spec and and what it should do and now is the like plan mode just became that you just do it in cloud code yeah yeah sometimes what I'll do is I'll just walk around the office on on our floor and I'll just kind of stand behind people I'll say like hi so it's like then I'll just see kind of like how they're using quad code and this is also just something I saw a lot but it also came up and GitHub issues like people were talking about it it seems like you're surprised how far the terminal has gone and how far it's been pushed like how far do you think it has left to go just given with this world of swall multiple agents like do you think there's going to be a new a need for a different UI on top of it it's funny if you asked me this a year ago I would say 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 in you know it's on web like quadri-i such code it's in the desktop app you know we've had that for you know 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 via code extensions there's jet brains 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 the lifespan of the CLI so I'm probably not the person to forecast. What about like your advice to dev tool founders like someone's building a dev tool company today should they just be building for engineers and humans or should they be thinking more about like what Claude's going to think and want and build for sort of like the agent. The way I would frame it is think about the thing that the model wants to do and figure out how do you make that easier and that's something that we saw you know like when I first started hacking on cloud code I realized like this thing just wants to use tools it just wants to interact with the world and how do you how do you enable that well the way you don't do it is you put it in a box and you're like here's the API here's how you interact with me and here's how you interact with the world the way you do it is you see what tools it wants to use you see what it's trying to do and you enable that the same way that you do for your users and so like for if you're building a dev tool start about we'll think about like what is the problem you want to solve for the user and then when you use when you apply the model to solving this problem what is the thing the model wants to do and then what is the technical and product solution that serves the weight and demand of both. YC's next batch is now taking applications got a startup in you apply at ycombinator.com/apply it's never too early and filling out the app will level up your idea okay back to the video back in a day more than 10 years ago you were a very heavy heavy user and you wrote a book about TypeScript right? Before TypeScript was cool this is when everyone was a deep in JavaScript this is back in early 2010s right? Yeah something like that. Before TypeScript was a thing because back then is a very weird language it's not supposed to do a lot of things with being typed in JavaScript and now is the right thing and it feels like clot code in the terminal has a lot of parallels with TypeScript at the beginning. TypeScript makes a lot of really weird language decisions so if you look at the type system pretty much anything can be a literal type for example and this is like this is super weird because like even like like Haskell doesn't even do this it's just like it's too extreme or it has like conditional types which I don't think any language thought of at all. It was like very strongly typed. Yeah it was very strongly and the idea was like when Joe Paymer and Anders and the early team was like building this thing the way they built it is we okay we have these teams with these big untieped JavaScript code bases we have to get types in there but we're not going to get engineers to change that the the way that they code you're not going to get JavaScript people to have like you know 15 layers of class inheritance like you would a Java programmer. They're going to write code the way they're going to write it they're going to use a reflection and they're going to use mutation and they're going to use all these features that traditionally we are very very difficult to type. They're very unsafe type to an eS strong functional programmer. That's right that's right and so the thing that they did instead of getting people to kind of change the way that they code they they build a type system around us and it was just it's brilliant because there's all these ideas that no one was thinking about even in academia like no one thought of a bunch of these ideas if your week came out of the practice of observing people and seeing how JavaScript programmers want to write code and so you know for quad code it there are some ideas that are kind of similar in that you know like you can use it like a unique utility you can pipe into it you can pipe out of it. In some ways it is kind of rigorous in this way but in almost every other way it's just the tool that we wanted like I built the tool for myself and then the team built the tool for themselves and then for inthropic employees and then for users and it just ends up being really useful. It's not it's not this like principled and academic thing which I think the the proof is actually in the results now fast-forward more than 15 years later not many code bases are in Haskell which is more academic and there's tons of them now in TypeScript because it's way more practical. Right. Which is interesting. Yeah it is interesting right it's like TypeScript solves a problem. I guess one thing that's cool I don't know how many people know but the terminal is actually one of the most beautiful terminal apps out there and is actually written with React terminal. When I first started building it you know like I did front-end engineering for a while so and I was also like you know I'm sort of like a hybrid like I do like design and user research and you know right code and all the stuff and we love hiring engineers that are like this so we just we love generalists. So for me it's like okay I'm building a thing for the terminal I'm actually kind of a shitty vim user so like how do I build a thing for people like me that you know are going to be working in a terminal and I think just the delight is so important and I feel like I see this is something you talk about a lot right it's like building a thing that people love if the product is useful but you don't fall in love with it that's not great so it kind of has to do both. Designing for the terminal honestly has been hard right it's like a it's like 80 by 100 characters or whatever you have like 256 colors you have one font size you don't have like mouse interactions there's all the stuff you can't do and there's all these very hard tradeoffs. So like a little known thing for example is you can actually enable mouse interactions in a terminal so you can enable like clicking and stuff. Oh how do you do that in cloud code I've been trying to figure out how to do that. We don't we don't have it in cloud code because we actually prototyped it a few times and it felt really bad because the tradeoff is you have to virtualize scrolling and so there's all these weird tradeoffs because like the way terminals work is like there's no dumb right it's like there's like anti-escape codes and these kind of weird organically evolved specs since like the 1960s or whatever. Yeah it feels like BBS is it's like a BBS door game. Yeah yeah yeah. Oh my gosh that's like that's like a great compliment. Yeah yeah yeah yeah I feel like we're discovering Lord of the Red Dragons fantastic oh my god yeah but we have we've had to just like discover all these kind of UX principles for building the terminal because no one really writes about this stuff and if you look at the big terminal apps of you know like the 80s or 90s or 2000s or whatever these like Ed curses and they have all these like windows and things like this and it just looks kind of like chinky by modern standards it just looks too heavy and complicated and so we have to like reinvent a lot and you know for example something like the terminal spinner like just like the spinner words it's gone through probably I want to say like 50 maybe a hundred iterations at this point and probably 80% of those didn't ship so we tried it it didn't feel good move on to the axe one try it didn't feel good move on to the next one and this was like sort of one of the amazing things about quad code right is like you can write these prototypes so you can just do like 20 prototypes back to back see which one you like and then ship that and the whole thing takes maybe a couple hours. Whereas in the past what you would have had to do is like weren't you or gami or framer or something like that so you built like maybe three prototypes it took like two weeks it just took much much longer and so we have this luxury of we have to discover this new thing we have to build a thing we don't know what the right endpoint is but we can iterate there so quickly and that's what makes it really easy and that's what let's us build a product that's like joyous and that people like to use. For us you had other advice for builders and we kept interrupting you because we have so many questions. I 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 I 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 much of work you find pmf for the product right now and then you're just going to get leapfrog 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 we're in the quad code area where we sit we have a framed copy of the bitter lesson on the wall and this is the like rich certain focus that like everyone should read it if you haven't and the idea is the more general model will always beat the more specific model and there's a lot of quarrelieries to this but essentially what it boils down to is never bet against the model and so this is just like a thing to 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 it'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 a way to straight 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 like you know like the 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 this scaffolding is it's just teched out how often you rewrite the codeways of a clock code is every six months with this with this first thing that you've deleted because you don't need it anymore because the model just improved oh so much yeah like all of quad code has just been written and rewritten and rewritten and rewritten over and over and over we unshipped tools every couple weeks we add new tools every couple weeks there's no product quad code that was around six months ago it's just constantly rewritten would you say that most of the codeways for our current clock code is only say 80% of it is only less than a couple months old yeah definitely it might it might even be like less than yeah maybe like a couple months that feels about right just like the lifecycle of code now that's another alphas expecting it to be the shelf life to be just a couple months yeah for the best founders do you see a steve yaggies post about how awesome working at anthropic is and I think there's a line in there that says that an anthropic engineer currently averages 1000 x more productivity than a Google engineer at Google's peak which is really an insane number honestly like 1000 x like you know we're three years ago we're still talking about 10 x engineers now we're talking about 1000 x on top of a Google engineer in the prime like this is unbelievable honestly yeah I mean internally if you if you look at like technical employees they all use quad code every day and even non-technical employees I think like half the sales team uses quad code they they've started switching to co-work because it's a little easier to use it has like a VMs it's a little bit safer but yeah we actually we just pulled the stat and the I think the team doubled in size last year or productivity per engineer grew something like 70% it's measured by just like the simplest stupidest measure pull requests okay but we also kind of cross check that against like commits and like the lifetime of commits and things like this and since quad code came out productivity per engineer at anthropic has grown 150% oh my god and this is crazy because I want in my old life I was responsible for code quality at meta and I was responsible for the quality of all of our code bases across every product across like you know Facebook Instagram WhatsApp whatever and one of the things that the team worked on was improving productivity and back then seeing a gain of something like 2% in productivity that was like a year of work by hundreds of people and so this like 100% this is just like unheard of just completely unheard of what drew you to come over to anthropic I mean basically as a builder you could go anywhere what was the moment that made you say like actually this is the set of people or this is the approach I was living in rural Japan and I was opening up hacker news every morning and I was reading the news and it was all it just started to be like AI stuff at some point and I started to use some of these early products and I remember like the first couple times that I used it I was just like it just took my breath away those like very cheesy to say but those actually those actually the feeling like it was just like it was amazing like as a as a builder I've just never kind of felt felt as feeling like using these very very early products that was like in the quad two days or you know something like that and so I just started talking to friends at labs just to kind of see what was going on and I met Ben Mann who's one of the founders at anthropic and he just immediately won me over and as soon as I met kind of the rest of the team at end it just won me over and I think I think probably in two ways so one is it operates as a research web so the product was teeny teeny tiny it's really all about building a safe model that's all that matters and so this idea of just being very close to the model and being very close to development and being not the most important thing because the product isn't anymore it's just the model is the thing that's the most important that really resonated with me after building product for many years and then the second thing was just how mission driven it is like I'm a huge sci-fi reader my bookshelf was just like filled with sci-fi and so like I just know how bad this can go and when I kind of think about what's going to happen this year it's going to be totally insane and in the worst case it can go very very bad and so I just wanted to be at a place that really understood that and kind of really internalized that and at and you know like if you overhear conversations in the lunch room or in the hallway people are talking about AI safety this is really the thing that everyone cares about more than anything and so I just wanted to be in a place like that I know I know for me personally mission is just so important what is going to happen this year okay so if you think back like six months ago and kind of what are the predictions that people are making so Darryl predicted that 90% of the code at Anthropic would be would be written by quad this is true for me personally it's been a hundred percent for like since opus 4.5 I just I uninstalled my IDE I don't edit a single line of code by hand it's just a hundred percent quad code and opus and you know I land you know like 20 pairs a day every day if you look at Anthropic overall it ranges between like 70 to 90 percent you know depending on the team for a lot of teams it's also like a hundred percent for a lot of people it's a hundred percent and I remember making this prediction back in May when we G8 quad code that you wouldn't need an IDE 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 you know the DNA at ant because like you know three of our founders were co-authors of the scaling loss paper they kind of 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 you know for me and I think it'll be the case for everyone you know regardless of domain I think we're gonna start to see the title software engineer go away and I think it's just gonna be maybe builder maybe product manager maybe we'll keep the title as kind of a vestitual thing but the work that people do it's not just gonna be coding it's software engineers are also gonna be writing specs they're gonna be talking to users like this thing that we're starting to see right now in our team where engineers are very much generalists and every single function on our team codes like our PMs code our designers code our EM codes are like everyone are our finance guy codes like everyone on our team codes we're gonna start to see this everywhere so this is sort of this is kind of like the lower bound if we just continue the trend the upper bound I think is a lot scarier and this is something like you know we hit ASL4 and this you know at Anthropic we talked about these safety levels ASL3 is where the models are right now ASL4 is the model is recursively self-improving and so if this happens essentially we have to meet a bunch of criteria before we can release a model and so the extreme is that you know this happens or there's some kind of catastrophic misuse like people are using the model to design viruses design zero-day stuff like this and this is something that we're really really actively working on so that doesn't happen I think it's just been honestly it's just been like so exciting and humbling like seeing how people are using quad code like you know I just wanted to build a cool thing and it ended up being really useful and that was so surprising and so exciting my impression from Tracer or just the outside is basically everyone went away over the holidays and then like found out about Claude code and it's just been crazy ever since but is that how it was for you at like in terms of do you we're having like a nice Christmas break and then came back you like what happened well actually for all the December of was traveling around and I took a coding vacation so we were kind of traveling around and I was just like coding every day so those were really nice and then I also started to use Twitter at the time because like I worked on threads back then way back when so I've been a threads user for a while so I just like tried to see kind of like other platforms where people are yeah I think for a lot of people they kind of discover that was the moment where they discovered open 4.5 I kind of already knew and internally quad codes just been on this like exponential tear for many many months now so that just like it it became even more steep that's what we saw and if you look at quad code now you know there was some stat for mercury that like 70% of startups are you know choosing Claude as their model of choice there were some other stat from like semi-analysis that 4% of all public commits are made by quad code like of all code written everywhere all the companies you know use quad code from like the biggest companies to kind of you know smallest startups you know like it wrote it it plotted the course for perseverance like for the like the Mars rover this is just like this is the coolest thing for me and we like we even printed posters because the team was like wow this is just like so cool the NASA chooses to use this thing so yeah it's just like it's humbling but it also feels like the very beginning what's the sort of interaction between a quad code and then code work like you know was it a fork of quad code was it like you had quad code look at the quad code code and say let's make a new spec for non-technical people that you know keeps all the lessons and then you know it sort of went off for a couple days and did that what's the genesis of that and you know where do you think that goes this is going to be like my fifth time using the word weight and demand yeah it was just that I mean like we were looking at Twitter and there was like that one guy that was using quad code to like monitor his tomato plants there was like this other person that was using it to like recover wedding photos off of a corrupted hard drive there are people that using it for like for finance when we looked internally at ontropic every designer is using it all 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 you know a little quad code wrapper in a gooey in the desktop app and that's all it is it's just quad code under the hood is the same agent oh wow and the fewix and the team and fewix was an early electron contributor he kind of knows that stack really well and he was hacking on various ideas and they they built it in I think something like 10 days it was just like a hundred percent 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 a technical audience it runs in all the code runs in a virtual machine there's a lot of deweat protections for deletion and things like this there's a lot of permission prompting and kind of other guard rails for users but yeah it was honestly pretty obvious bores thank you so much for making something that is taking away all my sleep but in return it's making me feel creator mode again sort of founder mode again it's been an exhilarating three weeks I like can't believe I waited that long since november to actually get into it thank you so much for being with us thank you for building what you're building yeah thanks for having me and the sandbox sounds good