And 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 LOMs. 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 over and over and over. There is no part of Quad code that was around six months ago. You try to think, you give it to users, you talk to users, you aren't.
And then eventually you might end up with an idea. Sometimes you don't. But you also know about human thinking that maybe like in six months, you won't need to prompt that explicitly. But the model should be not true at all in time.
Maybe in a month. I'm going to start playing mode. Oh my God. Welcome to another episode of the Litecone.
And today we have an extremely special guest, Boris Churney, 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.
Right. I'm very addicted to cloud code and it feels like rocket boosters has it felt like this for people like 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 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 three straight months. This was September, 2024.
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, this is, I think this is going to be a thing. I don't know if it's useful yet because it could 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 changed it.
It wrote maybe like 10% of my code or something like that. I don't really use it to write code. 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. And 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 device to founders that are building on LMS 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 Jim when you first got the idea, can you just talk through that?
Like, was it like a spark or what was even the first version of it in your mind? You know, it's funny. It was like so accidental that it just kind of evolved into this. You know, as anthropic, I think for the bet has been coding for a long time.
And the bet has been the path to save to save AGI is to recording. And this is this is kind of always been idea. And the way you gather is you teach the model how to code and you teach it how to use tools and 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 CI. 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 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 them for API at that point.
And so I just felt like a little terminal app to use the API, that's all that I 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 a terminal, like an ask question, I get the 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, oh, yes, this is cool. Is this actually useful?
Probably not. Let me just try it. You put it in terms of just because it was the easiest way to get something up and running. Yes.
Because I didn't have to build the UI. Okay. It was just me. At that point, it was like the IDEs cursor, winter for the things that were really taking off where you sort of under any pressure or getting a suggestion.
So, hey, like we should build this out as a plug-in or as a, as a free feature ID itself. There's no pressure because we didn't even know what we wanted to build. Like the team was just an explore mode. You know, like we didn't, we know vaguely we wanted to do something encoding, but it wasn't 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 very good example in our docs. It was like, take the example. I just put it to the TypeScript because that's how I wrote it. You know, I didn't know like what the model could do with that.
So I asked to like read a file. I could have 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 Mac and look up the music in my music player. Oh my god. And this was Sonic 3.5.
You know, like I didn't think the model could do that. And that was my first, I think, ever field at AGI moment. Where it's like, oh my god, the model, it just wants to use tools. That's all it wants.
That's kind of fascinating. I mean, it's very kind of contrarian that clockwork so well in such an 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. 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 dog feeding. 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 me, who's another engineer, he just like had quad code on his computer and he was like using it to code.
What are you doing? Like this thing is already is just a prototype. But yeah, he 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 user's chart internally, like the Dell chart is like vertical. Are you like forcing engineers to use it? Like, are you mandating them? And I was just like, no, we didn't.
I just like posted about it. And they just been like telling each other about it. Honestly, it was just accidental. We started with the C.
Like, it was the cheapest thing and they just kind of stayed there for a bit. So in that 2024 period, what, how would the engineer is using it? Whether they're shipping code with it yet? So whether using it in a different way.
The model is not very good at coding it. I was using it personally for automating Git. I think at this point, I've ever forgotten most of my Git. Cloud code has been doing it for so long.
But yeah, like automating bash commands, 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 was 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 quadindic came from.
Probably the single for me biggest principle in product is latent demand. And just every bit of this product is built through latent demand after the initial CLI. And so quadindic 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 quadindic and kind of 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 since 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 yours is actually very short, which is almost like the opposite of what people might expect. Why is that?
What's in your cloud MD? Okay, so I checked this before we came. So my quadindic has two things. One is, it's just two lines.
So the first line is whenever you put up a PR, enable AutoMerge. So 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, I posted in our internal teams' channel just so someone can stamp it and I can get unblocked. And the idea is every other instruction is in our quad 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 like mistake that's totally preventable.
And I'll just literally tag quad on the PR. I'll just do like add quad, you know, like add this to the quad MD and I'll do this, you know, like many times a week. Do you have to like compact the cloud MD? Like I've definitely reached a point where I got the message at the top saying your cloud MD is like thousands of tokens now.
What do you do when you guys hit that? 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 to do 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 quad MD and then, you know, the model is getting on track, that's the wrong thing. That's when you kind of add back a little bit at a time. And we are probably going to find this 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 die hard terminal, like them, them only person, you know, screw those VS code people.
You know, we have people like that on the team. You know, like, I'm well, for example, he's on the team. He's like, you will never take them from my cold head. 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 def 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 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 TMX.
You don't have to know how to like SSH. You don't have to know all the stuff. You just have to open up the tool and it'll guide you. It'll do all the stuff.
How do you decide how verbose you want the terminal to be? Sometimes you have to go control O and check it out. Is it internal bike shed battles around longer, shorter? Every user probably has a different 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 changed 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, it's a 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 some like get output, maybe it's not useful. But if you're running, you know, like, Kubernetes jobs or something like that, 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 dot MD, it'll set, you know, like, red one file search, 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, you know, still read the wrong thing pretty often as a user used to have to be there and kind of catch it and debug it.
But nowadays, I just noticed 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 talked through to it for a command and then people on GitHub didn't like it. So there's a big issue where people are like, no, like, 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 such 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 put 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 like iterated more and more and more together really good and to make a good 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're this particular object 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 going to 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. 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 an inch, a real human being has to look at code. That's bad. Yeah. Yeah.
Fascinating. I think like Denshipter talks about this a lot as kind of whenever you see the model making the state try to put in the quad MD, try to put it in like skills or something like this, what's reasonable. But I think there's a medical 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 is change it 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, Jared Sumner 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 heaped on by open it in def tools, I was looking through the profile and 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, and then like try to figure it out and quad code like took the he dumped it wrote a little tool for itself to like analyze the heat up. 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 going to begin a reminder and I don't know, maybe just 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.
And my old job at a big company, when I heard 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 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 going 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 mistaken hindsight, if they can clean credit for the mistake and if they weren't 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 actually quite good at it. But other people sometimes whenever we 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 weren't.
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 actually 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 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 the rails? Like do they use plan mode? You know, when they use plan mode, do they make sure that their tests or all these different things that you know, do they think about systems or even understand systems? Like there's just so much that 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, it's like, oh, this person's really good at shooting or defense. Like you can imagine a spider web graph of like, you know, someone's Claude Code skill level. Yeah, well, this will be what we do. I mean, I think it's like systems testing must be like user behavior.
I mean, there's got to be a design part, you know, for sure. Product sense, but you know, it's 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 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 bimodal.
There's one side where it's extreme specialists. And so like I named Jared before, he's a really good example of this. And kind of the bun team is a really good example. Just hyper specialist, they understand dev tool is better than anyone else.
They understand JavaScript runtime systems better than anyone else. And then there's the flip side of hyper-regenerless and that's kind of the rest of the team. And a lot of people, they span like product and infrared product 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 to fast, because it's like, and these people actually build something useful. That's a limbist test. Yeah, this limbist test. But nowadays, like for example, an engineer on the team, 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 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 she did 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 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 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 lot to figure out how to use a LEMs in this way, how to 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 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 product 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 like designer of a thing and they're just like 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 like, how am I gonna do this, you know?
You know, like we just want quad 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 cloud teams? It's collaboration.
It's like there's this whole 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 when it was an idea is just multiple agents. They have fresh context windows that aren't necessarily 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 apologize 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 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 gave Quads spec and told Quads to use a son board and then put up a bunch of tickets on a son and then respond to agents and the agents started picking up tasks and then Quads gave instructions and they all just figured it out.
But independent agents have been in the context of the bigger spec, right? Right. If you think about the way that how are agents actually started nowadays and I haven't pulled it in on this, but I would bet that majority of agents are actually prompted by Quads today in the form of sub-agents. Because I guess that agent is just like a recursive quad code that's all it is in the code and it's just prompted by a weak over mama quad.
And that's all it is. And I think probably if you look at most agents that are launched in this way. My clod insights just told me to do this more for debugging. So that I get like I spent 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 I just like added that to my clod empty to just be like, okay, like maybe try to 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 tried to fix bugs in plan mode and then it seems to use the agents to sort of, you know, 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 to. I just say if the task seems kind of hard, this kind of research that 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 ten sub-agents research in parallel and then see what they come up with. I'm curious to then why didn't you put that in your clod empty file? It's kind of case by case, you know, like quite empty. Like what is it?
It's just a shortcut. Like if you find yourself repeating the same thing over and over, you put in the quad empty, but otherwise you don't have to put everything there. You can just prompt one. And you also end up thinking about thinking that maybe like in six months you won't need to prompt that explicitly, but the model would be good enough to go out in time.
Maybe in a month. You're running for plan mode? Oh my god. I think Plan Mode probably has a limited lifespan.
Interesting. That's something alpha for everyone here. What would the world look like without Plan Mode? Do you just describe it at the prompt level and it would just do it?
One shot it? Yeah, we've started experimenting with this because quad code can now enter a plan mode by itself. I don't know if you've got you guys in that. So we're trying to kind of get this experience really good.
So it would enter Plan Mode at 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 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 actually just say that. Yeah. So it sounds like a lot of the feature development for quad code is very much when we talk about it.
I see. Talk to your users and then you come and implement it. It wasn't the other way that you have this master plan and then implement all the features. Yeah, yeah.
I mean, that's all it was. Like Plan Mode was we saw users that were like, hey, come up with an idea, plan this out, but don't write any code yet. And there was kind of various versions of it. Sometimes it was just talking through an idea.
Sometimes it was very sophisticated specs that they were asking to write. But the common dimension was do a thing without coding yet. And so literally, this was like Sunday night at 10 p.m. I was just like looking at GitHub issues and seeing what people were talking about and looking under internal Slack feedback channel.
And I just wrote this thing in like 30 minutes and then shipped it that night and went out Monday morning. How's Plan Mode? So do you mean that there'll be no need for Plan Mode in the sense of I'm worried that the model is going to do like the wrong thing, right 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, can I increase the model capabilities? So maybe six months ago, a plan was insufficient. So you get quad to make a plan was even with Plan Mode. You still have to kind of sit there and babysit because it can go off track.
Nowadays, what I do is probably 80% of my sessions. I say Plan Mode has a limited with. I'm a heavy Plan Mode user. I probably 80% of my sessions, I start in Plan Mode and quad will, you know, it will start, I'll start making a plan, I'll move on to my second terminal tab and then I'll have another plan and then when I run out of tabs, I open the desktop app and then I go to the code tab and then I just start a bunch of tabs there and they all start in Plan Mode.
Probably like 80% of the time. Once the plan is good and sometimes it takes a little back and forth, you 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 give a prompt and quad will figure it out. The next step is, Cloud just speaks to your users directly. It's just five buses, you entirely.
It's fine, this is actually the current software. Or, they talk to each other, they talk to our users on swag, at least internally pretty often. Like quad will tweet once in a while. But I actually like to weed it.
It's just like, it's a little cheesy. I don't love the tone. What does it want to tweet about? Sometimes it'll 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 I like using a browser.
That's funny. Really common pattern is I ask quad to build something, it'll look in the codebase, it'll see some engineer touch something in the get flame and then it'll message that engineer on swag. Just like asking a clarifying question. Then once it gets answered back, it'll keep going.
What are some tips for founders now on how to build the future? Sounds like everything is really changing. What are some principles that we'll stay on and what will change? So 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 waiting the mends. 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 figuring out these kind of product ideas for you just because it can look at feedback and look at the bug logs that kind of figure this out.
That's when you buy a plan mode with Leighton demand that people already have their claw chattman down in the browser and we're talking about the spec and what you should do and manage that like plan mode just became that you just do it in your code. Yeah. Sometimes what I'll do is I'll just walk around the office on our floor and I'll just kind of stand behind people. I'll say like hi.
So I'll just see how they're using quad code. And this is also something I saw a lot. But also give up on GitHub issues. Like people are talking about it.
It seems like you're surprised how far the terminal has gone and how far it's been finished. Like how far do you think it has left to go? Just given with this world of swarm or small agents? Do you think there's going to be a new need for it?
Different UI on top of it? It's funny if you ask 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 in, you know, it's on web. You can like quality as such code. It's in the desktop app. You know, 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 before tasks. But like your advice to dev tool founders, like someone's building a dev tool company today, should they just like be building for engineers and humans?
Or should they be thinking more about like what code kind of thing 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 quad code, I realized like this thing just wants to use tool. So 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 think about like what is the problem you want to solve for the user.
And then 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 way and demand of both. YC's next batch is now taking applications. Got to start up in you?
Apply at y Combinator.com slash apply. It's never too early and filling out the app will level up your idea. Okay, back to the video. Back in the day, more than 10 years ago, you were a very heavy, heavy user and you wrote about TypeScript, right?
Before TypeScript was cool. This is when everyone was a deep in Java script 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 Cloud 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 even 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 that he was like when Joe Pamer and Anders and the early team was building this thing. The way they built it is we have these teams with these big on TypeScript code bases. We have to get types in there. But we're not going to get engineers to change the way that they code.
You're not going to get JavaScript people to have like 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 reflection and use mutation.
And they're going to use all these features. That traditionally are very, very difficult to type. They're a very unsafe type to any strong functional programmer. That's right.
That's right. And so the thing that they did instead of getting people to change the way that they code, they built a type system around this. And it's brilliant because there's all these ideas that no one was thinking about, even in academia, no one thought of a bunch of these ideas. If you're here, we can have the practice of observing people and seeing how JavaScript programmers want to write code.
And so for quad code, there are some ideas that are kind of similar in that. You can use it like a unique utility. You can back into it. In some ways, it is kind of rigorous in this way.
But in almost every other way, it's just a tool that we wanted. I built a tool for myself and then the team built a tool for themselves and then for anthropic employees and then for users. And it just ends up being really useful. It's not the principle of an academic thing.
Which I think the proof is actually the result. It's 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 the type of code.
It's way more practical. Which is interesting. Yeah, it is interesting. It's like TypeScript solves the 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, I did front-end engineering for a while. And I was also like a hybrid design and user research and write code and all the stuff. We love hiring engineers that are like this.
So 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 user. So how do I build a thing for people like me that are going to be working in a terminal?
And I think just that the light is so important. And I think I see this as something you talk about a lot, right? It's like building the thing that people love. If the product is useful, we don't fall in love with it.
That's not great. So it kind of has to be both. Designing for the terminal honestly has been hard. It's like 80 by 100 characters or whatever.
You have 256 colors. You have one font size. You don't have like mouse interactions. There's all the stuff you can do.
And there's all these very hard trade-offs. So a little known thing, for example, is you can actually enable mouse interactions in a terminal. So you can enable 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 have it in Cloud Code because we actually prototyped it a few times and it felt really bad. Because the trade-off is you have to virtualize scrolling. And so there's all these weird trade-offs, because the way terminals work is like, there's no DOM, right?
It's like there's like anti-escape codes and these kind of weird organically evolved specs since the 1960s or whatever. It feels like PBS's. It's like a PBS store game. Oh my gosh.
That's like a great complement. Yeah. Yeah. Yeah.
It's like discovering the Lord of the Red Dragons. Fantastic. Oh my God. Yeah.
But we've had to just 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 like 80s or 90s or 2000s or whatever, these like Edcirces and they have all these windows and things like this. And it just looks kind of like janky 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 100 iterations at this point, and probably 80% of those didn't ship. So we tried it. It didn't feel good.
Move on to that. Try it. Didn't feel good. Move on to the next one.
And this was like sort of one of the amazing things about code, right? It's like, you can write these prototypes and you can just do like 20 prototypes back to back, see which one you like and then shift that and the whole thing takes maybe a couple of hours. Whereas in the past, what you would have had to do is like, once you were a gummy or a framer or something like this, you'd be 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 where the right endpoint is, but we can iterate there so quickly.
And that's what makes it really easy. And that's what lets us build a product that's like joyous and that people like to use. Of course, you had other advice for builders and we kept interrupting you because we have so many questions about it. I would say, so maybe two pieces of advice that are kind of weird because it's like about building for the model.
So when is a don't build for the model 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. That actually 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, fill 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 say we have a framed copy of the better lesson on the wall. And this is like a rich button. If I get everyone to read it, if you haven't.
And the idea is that the more general model will always be the more specific model. And there's a lot of core releries to this, but essentially what it was done to is never bad 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.
It'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 extend the capability a little bit maybe 10, 20% or whatever and whatever domain on this like, you know, like the spider chart or what you're trying to extend or you can just wait in the next model to 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 can you rewrite the code ways of a clock code? Is this every six months with this with this particular scaffolding that you've deleted because you don't need any workers to improve?
Oh, so much. Yeah. Like all of quad code has just been written and rewritten and rewritten over and over and over. We unshift tools every couple weeks.
We add new tools every couple weeks. There's no part of quad code that was around six months ago. We just constantly rewritten. Would you say that most of the code base for our current clock code is only 80% of it is only less than a couple months old?
Yeah, definitely. It might even be like less than maybe like a couple months that's not what I write. Just like the life cycle of code now. That's another alpha is expecting it to be the shelf life to be just a couple months for the best founders.
Yeah. Steve Yaggis posts about how awesome working at Anthropik is. And I think there's a line in there that says that an anthropic engineer currently averages 1000x more productivity than a Google engineer at Google's peak, which is really an insane number. Honestly, like 1000x, three years ago, we're still talking about 10x engineers now.
We're talking about those next on top of a Google engineer in the prime. Like this is unbelievable, honestly. Yeah. I mean, internally, if you look at like technical plays, they all use quad code every day.
And even non-technical employees, I think like half the sales team uses quad code. They've started switching to go 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 this ad and the I think the team doubled in size last year, but productivity per engineer grew something like 70%.
It's measured by just like the simplest to do with this major pull request. 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 went in my old life, I was responsible for code quality and I was responsible for the quality of all of our code bases across every product across Facebook, Instagram, 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 100 people. And so this is 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. 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 of times that I used, I was just like, it just took my breath away.
It was like very cheesy to say. But that was actually the feeling. Like it was just like, it was amazing. Like as a builder, I just never kind of felt this feeling like using these very, very early products.
Those like in the quad two days or 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 the end, it just won me over. And I think probably in two ways. So one is it operates as a research web. So the product work 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 book shelf is 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, you know, 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 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 for me personally the mission is just so important.
What is going to happen this year? Okay. So if you think about like six months ago, and kind of what are the predictions that people are making? So Dario predicted that 90% of the code on anthropic would be would be written by quad.
This is true. For me personally, it's been 100% for like since I was 4.5. I just I uninstall my IDE. I don't edit a single line of code by hand.
It's just 100% quad code and all this. And you know, I land, you know, like 20 per a day every day. If you look at anthropic overall, it ranges between like 70 to 90%, 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 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 a silly prediction at the time. But really all it is, like you just like trace the exponential. And this is like so deep in the DNA at the end because like three of our founders were co-authors of the scaling one's paper.
They saw this very early. And so this is just like tracing exponential. This is what's going to happen. And yes, that happened.
So continuing to trace exponential, I think what will happen is coding will be generally solved for everyone. And I think today coding is practically solved for me. And I think it will be the case for everyone, regardless of what I mean. I think we're going to start to see the title software engineer go away.
And I think it's just going to be maybe builder, maybe product manager, maybe we'll keep the title as kind of a vestigial thing. But the work that people do, it's not just going to be coding, it's software engineers are also going to be writing specs. They're going to 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 RPMs code, our designers code, our EM codes, our finance codes, like everyone on our team codes, we're going to start to see this everywhere.
So this is sort of this is kind of like the lower bound if we just continue with the trend. The upper bound I think is a lot scarier. And this is something like 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 the model. And so the extreme is that this happens or there's some kind of catastrophic misuse.
Like people are using the model to design viruses, design zero data, 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 version of Triceros outside is basically everyone went away over the holidays and then found out about cool code and it's just been crazy. Is that how it was for you at Intimacy?
We having a nice Christmas break and then getting back to what happened? Well, actually, for all of December, I 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 that was really nice.
And then I also started to use Twitter at the time because I worked on threads back then, way back when. So I've been in threads for a while. So I just tried to see kind of like other platforms where people are. Yeah, I think for a lot of people, they kind of discovered, that was the moment where they discovered this 4.5 icon of a renew.
And the internal week quad code has just been on this exponential terror for many, many months now. So that just became even more steep. That's what we saw. And if you look at quad code now, there was some staff from Mercury that 70% of startups are choosing quad as their model of choice.
There was some other staff from like, Samuel analysis that 4% of all public commits are made by quad code, like of all code written everywhere. All the companies use quad code for the biggest companies to kind of small and startups. It part of the course for perseverance, like the Mars Rover. This is the coolest thing for me.
We even printed posters because the team was like, wow, this is just 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 interaction between a quad code and then co-work? Was it a fork of cloud code? Was it like you had cloud code look at the cloud code code and say, let's make a new spec for non-technical people that keeps all the lessons and then it went off for a couple days and did that? What's the genesis of that?
And where do you think that goes? 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 quad code to monitor his to middle plants.
There was this other person that was using it to recover wedding photos off of a corrupted hard drive. There were people that using it for finance. When we looked internally at anthropic, every designer is using it. The entire finance team 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 they can use this. We knew for a while that we wanted to build something. We're experimenting with a bunch of different ideas.
The thing that took off was a little quad code wrapper in the desktop. That's all it is. It's a quad code under the hood. It's the same agent.
The Felix and the team, he knows that stack really well. He was hacking on various ideas. They built it in 10 days. It was just 100% written by quad code.
It just felt ready to release. There was a lot of stuff that we had to build for non-technical users. It's a little bit different than technical audience. It runs in a virtual machine.
There's a lot of protections for deletion and things like this. There's a lot of permission prompting and other guardrails for users. It was honestly pretty obvious. Thank you so much for making something that is taking away all my sleep.
In return, it's making me feel creator mode again, sort of founder mode again. It's been an exhilarating three weeks. I can't believe I waited that long since November to get into it. Thank you so much for being with us.