From 20a4e7214544e7041e84dbd0e00925ed7ecc6411 Mon Sep 17 00:00:00 2001 From: Shayan Rais Date: Thu, 19 Mar 2026 18:17:32 +0500 Subject: [PATCH] added video transcripts --- !/tags/video.svg | 17 + .../claude-boris-lennys-podcast-19-feb-26.md | 302 ++++++++++++ ...aude-boris-pragmatic-engineer-04-mar-26.md | 332 +++++++++++++ .../claude-boris-ryan-peterman-15-dec-25.md | 178 +++++++ videos/claude-boris-y-combinator-17-feb-26.md | 340 +++++++++++++ videos/claude-cat-every-29-oct-25.md | 462 ++++++++++++++++++ 6 files changed, 1631 insertions(+) create mode 100644 !/tags/video.svg create mode 100644 videos/claude-boris-lennys-podcast-19-feb-26.md create mode 100644 videos/claude-boris-pragmatic-engineer-04-mar-26.md create mode 100644 videos/claude-boris-ryan-peterman-15-dec-25.md create mode 100644 videos/claude-boris-y-combinator-17-feb-26.md create mode 100644 videos/claude-cat-every-29-oct-25.md diff --git a/!/tags/video.svg b/!/tags/video.svg new file mode 100644 index 0000000..f93cc52 --- /dev/null +++ b/!/tags/video.svg @@ -0,0 +1,17 @@ + + Video + + + + + + + + + + + + + Video + + diff --git a/videos/claude-boris-lennys-podcast-19-feb-26.md b/videos/claude-boris-lennys-podcast-19-feb-26.md new file mode 100644 index 0000000..b354003 --- /dev/null +++ b/videos/claude-boris-lennys-podcast-19-feb-26.md @@ -0,0 +1,302 @@ +# Head of Claude Code: What Happens After Coding Is Solved — Lenny's Podcast + +Transcript of the interview with Boris Cherny ([@bcherny](https://x.com/bcherny)), creator of Claude Code, on Lenny's Podcast, published February 19, 2026. + + + + + + +
← Back to Claude Code Best PracticeClaude
+ +--- + +## Video Details + +- **Guest:** Boris Cherny (Creator of Claude Code) +- **Host:** Lenny Rachitsky (Lenny's Podcast) +- **Published:** February 19, 2026 +- **YouTube:** [Watch on YouTube](https://youtu.be/We7BZVKbCVw) + +--- + +## Transcript + +[`0:02`](https://youtu.be/We7BZVKbCVw?t=2) 100% of my code is written by quad code. I have not edited a single line by hand since November. Every day I ship 10, 20, 30 p requests. So at the moment I have like five [music] agents running while we're recording this. + +[`0:13`](https://youtu.be/We7BZVKbCVw?t=13) Yeah. Yeah. Do you miss writing code? + +[`0:15`](https://youtu.be/We7BZVKbCVw?t=15) I have never enjoyed coding as much as I do today because I don't have to deal with all the minutia. Productivity per engineer has increased 200%. + +[`0:22`](https://youtu.be/We7BZVKbCVw?t=22) There's always this question, should I learn to code? In a year or two, it's not [music] going to matter. Coding is largely solved. I imagine a world where everyone is able to program. Anyone can just build software anytime. What's the next big shift [music] to how software is written? + +[`0:33`](https://youtu.be/We7BZVKbCVw?t=33) Quad is starting to come up with ideas. It's looking through feedback. It's looking at bug reports. It's looking at telemetry for bug fixes and things to ship a little more like a co-orker or something like that. + +[`0:42`](https://youtu.be/We7BZVKbCVw?t=42) A lot of people listening to this are product managers and they're probably sweating. I think by the end of the year, everyone's going to be a product manager and everyone codes. The title software engineer is going to start [music] to go away. It's just going to be replaced by builder and it's going to Today my guest is Boris Churnney, head of Claude Code at Anthropic. It is hard to describe the impact that Claude Code has had on the [music] world. Around the time this episode comes out will be the one-year anniversary of Claude Code. And in that short time, it has completely transformed the job of a software engineer and it is now starting to transform the jobs of many other functions in tech which we talk about. Cloud code itself is also a massive driver of anthropic overall growth over the past year. They just raised a round at over [music] $350 billion. And as Boris mentions, the growth of Claude Code itself is still accelerating. Just in the past month, their daily active users has doubled. Boris is also just a really interesting, thoughtful, deepinking human. And during this conversation, we discover we were born in the same city in Ukraine. That is so funny. I had no idea. A huge thank you to Ben Man, Jenny Wen, and Mike Griger for suggesting topics for this conversation. Don't forget to check out lennisprodpass.com for an incredible set of deals available exclusively to Lenny's newsletter subscribers. Let's get into it after a short word from our wonderful sponsors. Today's episode is brought to you by DX, the developer intelligence platform designed by leading researchers. To thrive in the AI era, organizations need to adapt quickly. But many organization leaders struggle to answer pressing questions like [music] which tools are working? How are they being used? What's actually driving value? DX provides the data and insights that leaders need to navigate this shift. With DX, companies like Dropbox, Booking.com, Adion, and Intercom get a deep understanding of how AI is providing value to their developers and what impact AI is having on engineering productivity. To learn more, visit DX's website at getdx.com/lenny. Applications break in all kinds of ways. Crashes, slowdowns, regressions, and the stuff that you only see once real users show up. Sentry catches it all. See what happened where, and why, [music] down to the commit that introduced the error, the developer who shipped it, and the exact line [music] of code all in one connected view. I've definitely tried the five tabs [music] and Slack thread approach to debugging. This is better. Sentry shows you how the request moved, what ran, what slowed down, and what users saw. Seir, Sentry's AI debugging agent, takes it from there. It uses all of that Sentry context to tell you the root cause, suggest a fix, and even opens a PR for you. It also reviews your PR and [music] flags any breaking changes with fixes ready to go. Try Sentry and SER [music] for free at centry.io/lenny and use code Lenny for $100 in Sentry Boris, thank you so much for being here and welcome to the podcast. [music] + +[`3:55`](https://youtu.be/We7BZVKbCVw?t=235) Yeah, thanks for having me on. + +[`3:58`](https://youtu.be/We7BZVKbCVw?t=238) I want to start with a a spicy question. About 6 months ago, I don't know if people even remember this, you actually left Anthropic. You joined Curser and then two weeks later, you went back to Anthropic. What happened there? I don't think I've ever heard the actual story. + +[`4:12`](https://youtu.be/We7BZVKbCVw?t=252) [laughter] + +[`4:13`](https://youtu.be/We7BZVKbCVw?t=253) It's the fastest job change that I've Um, I joined Cursor because I'm a big fan of the product and honestly I met the team and I was just really impressed. Uh, they're an awesome team. Uh, I still I still think they're awesome and they're just building really cool stuff and kind of they they saw where AI coding was going I think before a lot of people did. So the idea of building good product was just very exciting for me. I think as soon as I got there, what I started to realize is what I really missed about Ant was the mission. And that's actually what originally drove me to Ant also cuz uh but before I joined Anthropic, I was, you know, I was working in big tech and then I was at some point I wanted to work at a at a lab to just help shape the future of this crazy thing that that we're building in some way. And the thing that drew me to anthropic was the mission. And it was, you know, it's all about safety. And when you talk to people at Enthropic, just like find someone in the hallway, if you ask them why they're here, the answer is always going to be safety. Um, and so this kind of like missiondrivenness just really really resonated with me. And I just know personally it's something I need in order to be happy. Um, and I that's just a thing that I really missed. And I found that, you know, whatever the work might be, no matter how exciting, even if it's building a really cool product, it's just not really a substitute for that. Um, so for me it was actually u it was pretty obvious that that I was missing that pretty quick. + +[`5:37`](https://youtu.be/We7BZVKbCVw?t=337) Okay. So let me follow the thread of just coming back to anthropic and the work you've done there. This podcast is going to come out around the year anniversary of launching cloud code. So I'm going to spend a little time just reflecting on the impact that you've had. There's um this report that recently came out that I'm sure you saw by semi analysis that showed that 4% of all GitHub commits are authored by cloud code now. and they predicted it'll be a fifth of all code commits on GitHub by the end of the year. The way they put it is while we blinked, AI consumed all software development. The day that we're recording this, Spotify just put out this uh headline that their best developers haven't written a line of code since December thanks to AI. More and more of the most advanced senior engineers, including you, are sharing the fact that you don't write code anymore, that it's all AI generated. and many aren't even looking at code anymore is how far we've gotten in large part thanks to this little project that you started and that your team has scaled over the past year. I'm curious just to hear your reflections on on this past year and the impact that your work has had. These numbers are just totally crazy, right? Like four 4% of all commits in the world is just way more than I imagined and like like you said, it still feels like the starting point. Um these are also just public commits. So we actually think if you look at private repositories, it's quite a bit higher than that. And I I think the craziest thing for me isn't even the number that we're at right now, but the pace at which we're growing because if you look at Quad Code's growth rate kind of across any metric, it's continuing to accelerate. Um so it's not just going up, it's going up faster and faster. When I first started Quad Code, it was just going to be a like it was just supposed to be a little hack. Um you know we we broadly knew at Enthropic that we wanted to get a we wanted to ship some kind of coding product and you know for enthropic for a long time we were building the models in this way that kind of fit our mental model of the way that we build safe hi where the model starts by being really good at coding then it gets really good at tool use then it gets really good at computer use roughly this is like the trajectory uh and you know we've been working on this for a long time and when you look at the team that I started on it was called the anthropic labs team uh and actually Mike Kger and you know Ben man they just kicked this team off again uh for kind of round two the team built some pretty cool stuff so we built quad code we built MCP we built the desktop app so you can kind of see the seeds of this idea you know like it's coding then it's tool use then it's computer use and the reason this matters for anthropic is uh because of safety it's kind of again just back to that AI is getting more and more powerful it's getting more and more capable the thing that's happened in the last year is that for at least For engineers, the AI doesn't just write the code. It it's not just a conversation partner, but it actually uses tools. It acts in the world. Um, and I think now with co-work, we're starting to see the transition for non-technical folks also. Um, for a lot of people that use conversational AI, this might be the first time that they're using the thing that actually acts. It can actually use your Gmail, it can use your Slack, it can do all these things for you and it's quite good at it. Um, and it's only going to get better from here. So I think for anthropic for a long time there was this feeling that we wanted to build something but it wasn't obvious what and so uh when I joined ant I spent one month kind of hacking and you know built a bunch of like weird prototypes most of them didn't ship and you know weren't even close to shipping it was just kind of understanding the boundaries of what the model can do then I spent a month doing post- training um so to understand kind of the research side of it and I think honestly that's just for me as an engineer I find that to do good work you really have to understand the layer under the layer at which you work. And with traditional engineering work, you know, if you're working on product, you want to understand the infrastructure, the runtime, the virtual machine, the language kind of whatever that is, the system that you're building on. But, uh, yeah, if you're like if you're working in AI, you just really have to understand the model to some degree to to do good work. So, I took a little detour to do that and then I came back and just started prototyping what eventually became quad code. Uh, and the very first version of it, I I have like a there's like a video recording of the summer because I recorded this demo and I posted it. It was called QuadCLI back then. And I just kind of showed off how it used a few tools and the shocking thing for me was that I gave it a batch tool and uh it just was able to use that to write code to tell me what music I'm listening to when I asked it like what music am I listening to? And this is the craziest thing, right? cuz it's like there's no we I I didn't instruct the model to say, you know, use, you know, this tool for this or kind of do whatever. The model was given this tool and I figured out how to use it to answer this question that I had that I wasn't even sure if it could answer. What music am I listening to? And so I I I started prototyping this a little bit more. Um I made a post about it and I announced it internally and it got two likes. That's the that was that was the extent of the reaction at the time because I think people internally you know like when you think of coding tools you think of like you think of IDE you think about kind of all these pretty sophisticated environments no one thought that this thing could be terminal based um that's sort of a weird way to design it and that wasn't really the intention but uh you know from the start I built it in a terminal because you know for the first couple months it was just me so it was just the easiest way to build uh and for me this is actually a pretty important product lesson right is like you want to underresource things a little bit at the start. Then we started thinking about what other form factors we should build and we actually decided to stick with the terminal for a while and the biggest reason was the model is improving so quickly. We felt that there wasn't really another form factor that could keep up with it. And honestly this was just me kind of like struggling with kind of like what should we build you know like for the last year quad code has just been all I think about. And so just like late at night, this is just something I was thinking about like, okay, the model is continuing to improve. What do we do? How can we possibly keep up? And the terminal was honestly just the only idea that I had. And uh yeah, it ended up catching on after after I released it pretty quickly. It became a hit at Anthropic and you know, the the daily active users just went vertical. And really early on, actually before I launched it, Ben man uh nudged me to make a DAU chart and I was like, you know, it's like kind of early maybe, you know, should we really do it right now? and he was like, "Yeah." And so the the chart just went vertical pretty immediately. Uh and then in February, we released it externally. Actually, something that people don't really remember is Quad Code was not initially a hit when we released it. It it got a bunch of users. There was a lot of early adopters that got it immediately, but it actually took many months for everyone to really understand what this thing is. Just again, it's like it's just so different. And when I think about it, kind of part of the reason quad code works is this idea of latent demand where we bring the tool to where people are and it makes existing workflows a little bit easier, but also because it's it's in a terminal. It's like a little surprising. It's a little alien in this way. So you have to you have to kind of be open-minded and you had to learn to use it. And of course now you know quad code is available you know in the iOS and Android quad app. It's available in the desktop app. It's available on the website. It's available as IDE extensions in Slack and GitHub. you know all these places where engineers are it's a little more familiar but that wasn't the starting point so yeah I mean at the beginning it was kind of a surprise that this thing was even useful and uh you know as the team grew as the product grew as it started to become more and more useful to people just people around the world from you know small startups to the biggest fang companies started using it and they started giving feedback and I think just reflecting back it's been such a humbling experience cuz we just we keep learning from our users and just the most exciting thing is like you know none of us really know what we're doing. Um and we're just trying to figure out along with everyone else and the single best signal for that is just feedback from users. Um so that's just been the best I' I've been surprised so many times. It's incredible how fast something can change in today's world. You launched this a year ago and it wasn't the first time people could use AI to code but uh in a year the entire profession of software engineering has dramatically changed like there's all these predictions oh AI is going to be written 100% AI's code is going to be written by AI everyone's like no that's crazy what are you talking about now it's like + +[`13:53`](https://youtu.be/We7BZVKbCVw?t=833) of course it's happening exactly as they said it's just so things move so fast and change so fast now + +[`13:59`](https://youtu.be/We7BZVKbCVw?t=839) yeah it's really fast back at uh back at code with quad back in May that was like our first uh you know like developer conference that we did as Enthropic. Um I did a short talk and in the Q&A after the talk people were asking what are your predictions for the end of the year and my prediction back in May of 2025 was by the end of the year you might not need an ID to code anymore and we're going to start to see engineers not doing this and I remember the room like audibly gasped. It was such a crazy prediction but I think like at anthropic like this is just the way the way we think about things is exponentials and this is like very deep in the DNA. Like if you look at our co-founders like three of them were the first three authors on the scaling laws paper. Um so we really just think in exponentials and if you kind of look at the exponential of the percent of code that was written by quad at that point if you just trace the line it's pretty obvious we're going to cross 100% by the end of the year even if it just does not match intuition at all. Um, and so all I did was trace the line and yeah, in November that, you know, that happened for me personally and that's been the case since and we're starting to see that for a lot of different customers too. I thought was really interesting what you just shared there about kind of the journey is this kind of idea of just playing around and seeing what happens. This came up comes up with open claw a lot just like Peter was playing around and just like a thing happen. And it feels like that's a central kind of ingredient to a lot of the biggest innovations in AI is people just sitting around trying stuff to pushing the models further than most other people. + +[`15:23`](https://youtu.be/We7BZVKbCVw?t=923) I mean this the thing about innovation right like you can't uh you can't force it. There's no road map for innovation. Um you just have to give people space. You have to give them maybe the word is like safety. So it's like psychological safety that it's okay to fail. It's okay if 80% of the ideas are bad. Um you also have to hold them accountable a bit. So if the idea is bad, you you know you cut your losses, move on to the next idea instead of investing more. Uh in the early days of quad code, I had no idea that this thing would be useful at all. Cuz even in February when we released it, it was writing maybe I don't know like 20% of my code, not more. And even in May, it was writing maybe 30%. I was still using you know curtzer for most of my code. And it only crossed 100% in November. So it took a while. But even from the earliest day, it just felt like I was on to something. And I was just spending like every night, every weekend hockey on this. And luckily my, you know, my wife was very supportive. Um, but it it just felt like it was on to something. It wasn't obvious what. And and sometimes, you know, you find a thread, you just have to pull on it. + +[`16:19`](https://youtu.be/We7BZVKbCVw?t=979) So at this point, 100% of your code is written by cloud code. Is that is that kind of the current state of your coding? + +[`16:25`](https://youtu.be/We7BZVKbCVw?t=985) Yeah. So 100% of my code is written by cloud code. Um, I am a fairly prolific coder. Um, and this has been the case even when I worked back at Instagram. I was like one of the top few most productive engineers. Um and that's actually that's still the case uh here at Anthropic. + +[`16:41`](https://youtu.be/We7BZVKbCVw?t=1001) Wow. Even as head of head of the team. + +[`16:43`](https://youtu.be/We7BZVKbCVw?t=1003) Yeah. Yeah. Do still do a lot of coding. Um and so every you know every day I ship like 10 20 30 p requests something like that + +[`16:49`](https://youtu.be/We7BZVKbCVw?t=1009) every day. + +[`16:50`](https://youtu.be/We7BZVKbCVw?t=1010) Every day. Yeah. + +[`16:50`](https://youtu.be/We7BZVKbCVw?t=1010) Good god. + +[`16:53`](https://youtu.be/We7BZVKbCVw?t=1013) Uh 100% written by quad code. I have not edited a single line by hand since uh November. And yeah, that that's been it. I do look at the code. So I I don't think we're kind of at the point yet where you can be totally hands-off, especially when there's a lot of people, you know, like running the program. You have to make sure that it's correct. You have to make sure it's safe and so on. Um, and then we also have Quad doing automatic code review for everything. Um, so here at Enthropic, Quad reviews 100% of poll requests. Um, there's still layer of like human review after it, but you kind of like you still do want some of these checkpoints like you still want a human looking at the code. um unless it's like pure prototype code that you know it's not going to run it's not going to run anywhere it's just a prototype. + +[`17:34`](https://youtu.be/We7BZVKbCVw?t=1054) What's kind of the next frontier? So at this point 100% of your code is being written by AI. This is clearly where everyone is going in software engineering. That felt like a crazy milestone. Now it's just like of course this is the world now. What's what's kind of the next big shift to how software is written that either your team's already operating in or you think will head towards? I think something that's happening right now is Quad is starting to come up with ideas. Um so Quad is looking through feedback. It's uh looking at bug reports. It's looking at um you know like telemetry and and things like this and it's starting to come up with ideas for bug fixes and things to ship. So it's just starting to get a little more um you know like a little more like a co-orker or something like that. I think the second thing is we're starting to branch out of coding a little bit. So I think at this point it's safe to say that coding is largely solved. At least for the kind of programming that I do, it's just a solved problem because quad can do it. And so now we're starting to think about okay like what's next? What's beyond this? There's a lot of things that are kind of adjacent to coding. Um and I think this is going to be coming. But also just you know general tasks, you know, like I use co-work every day now to do all sorts of things that are just not related to coding at all and just to do it automatically. Like for example, I had to pay a parking ticket the other day. I just had co-work do it. um all of my project management for the team uh co-work does all of it. It's like syncing stuff between spreadsheets and messaging people on Slack and email and all this kind of stuff. So I think the frontier is something like this and I I don't think it's coding because I think coding is you know it's pretty much solved and over the next few months I think what we're going to see is just across the industry it's going to become increasingly solved you know for every kind of codebase every tech stack that people work on. + +[`19:16`](https://youtu.be/We7BZVKbCVw?t=1156) This idea of helping you come up with what to work on is so interesting. A lot of people listening to this are product managers and they're probably sweating. How do you use Claude for this? Do you just talk to it? Is there anything clever you've come up with to help you use it to come up with what to build? + +[`19:31`](https://youtu.be/We7BZVKbCVw?t=1171) Honestly, the simplest thing is like open quad code or co-work and point it at a Slack thread. Um, you know, like for us, we have this channel that that's all the internal feedback about Quad Code. Since we first released it, even in like 2024 internally, it's just been this fire hose of feedback. Um, and it's the best. And like in the early days, what I would do is anytime that someone sends feedback, I would just go in and I would fix every single thing as fast as I possibly could. So like within a minute, within 5 minutes or whatever. And this just really fast feedback cycle, it encourages people to give more and more feedback. It's just so important cuz it makes them feel heard cuz you know like usually when you use a product, you give feedback, it just goes into a black hole somewhere and then you don't give feedback again. So if you make people feel heard, then they want to contribute and they want to help make the thing better. Um, and so now I kind of do the same thing, but Quad honestly does a lot of the work. So I pointed at the channel and it's like, "Okay, here's a few things that I can do. I just put up a couple PRs. Want to take a look at that one?" I'm like, "Yeah." Have you noticed that it is getting much better at this? Because this is kind of the holy grail, right? Now it's like, "Cool, building solved." Code review became kind of the next bottleneck. All these PRs, who's going to review them all? The next big open question is just like, okay, now we need to now now humans are necessary for figuring out what to build, what to prioritize. And you're saying that that's where claude code is starting to help you. Has it has it gotten a lot better with like say Opus 46 or what's been the trajectory there? + +[`20:52`](https://youtu.be/We7BZVKbCVw?t=1252) Yeah. Yeah, it's improved a lot. Um I think some of it is kind of like training that we do specific to coding. Um so you know obviously you know best coding model in the world and you know it's getting better and better like 4.6 is just incredible but also actually a lot of the training that we do outside of coding translates pretty well too. So there is this kind of like transfer where you teach the model to do you know X and it kind of gets better at Y. Um yeah and the the gains have just been insane like at anthropic over the last year like since we introduced quad code we probably I don't know the exact number we probably like 4x the engineering team or something like this but productivity per engineer has increased 200%. in terms of like pull requests and like this number is just crazy for anyone that actually works in the space and works on deaf productivity because back in a previous life I was at Meta and you know one of my responsibilities was code quality for the company. So this is like the all of our code bases that was my responsibility like Facebook, Instagram, WhatsApp all this stuff. Um and a lot of that was about productivity because if you make the code higher quality then engineers are more productive and things that we saw is you know in a year with hundreds of engineers working on it you would see a gain of like a few percentage points of productivity something like this. Um and so nowadays seeing these gains of just hundreds of percentage points it's is just absolutely insane. What's also insane is just how normalized this has all been like we hear these numbers like of course AI is doing this to us. It's just it's so unprecedented the amount of change that is happening to software development to building products to just this the world of tech. It's just like so easy to get used to it. But it's important to recognize this is crazy. This is something like I have to remind myself once in a while. There's sort of like a downside of this because the model changes so well there's actually like there's many kind of downsides that that we could talk about but I think one of them on a personal level is the model changes so often that I sometimes get stuck in this like old way of of thinking about it and I even find that like new people on the team or even new grads that join do stuff in a more kind of like AGI forward way than I do. So like sometimes for example I I I had this case like a couple months ago where there was a memory leak and so like what this is is you know like quad code the memory usage is going up and at some point it crashes. This is like a very common kind of engineering problem that you know every engineer has debugged a thousand times and traditionally the way that you do it is you take a heap snapshot you put it into a special debugger you kind of figure out what's going on you know use these special tools to see what's happening. Um, and I was doing this and I was kind of like looking through these traces and trying to figure out what was going on. And the engineer that was newer on the team just uh had Quad Code do it and was like, "Hey Quad, it seems like there's a leak. Can you figure it out?" And so like Quad Code did exactly the same thing that I was doing. It it took the heap snapshot. It wrote a little tool for itself so it can kind of like analyze it itself. Um, it was sort of like a just in time program. Uh, and it found the issue and put up a pull request faster than I could. So it's it's something where like for those of us that have been using the model for a long time, you still have to kind of transport yourself to the current moment and not get stuck back in an old model because it's not sonnet 3.5 anymore. The new models are just completely completely different. Uh and just this this mindset shift is is very different. I hear you have these very specific principles that you've codified for your team that when people join you you kind of walk them through them. I believe one of them is what's better than doing something having Claude do it. And it feels like that's exactly what you describe with this memory leak is just like you almost forgot that principle of like okay let me see if Claude can solve this for me. There's this uh there's this interesting thing that happens also when you um when you underfund everything a little bit uh because then people are kind of forced to clify and this is something that we see. So you know for work where sometimes we just put like one engineer on a project and the way that they're able to ship really quickly because they want to ship quickly. This is like an intrinsic motivation that comes from within is just wanting to do a good job. One if you have a good idea you just really want to get it out there. No one has to force you to do that. That comes from you. Um and and so if you have claude, you can just use that to automate a lot of work. Uh and that that's kind of what we see over and over. So I think that's kind of like one principle is underfunding things a little bit. I think another principle is just encouraging people to go faster. So if you can do something today, you should just do it today. And this is something we we really really encourage on the team. Early on it was really important because it was just me and so our only advantage was speed. that's the only way that we could ship a product that would compete in this very crowded coding market. But nowadays, it's still very much a principle we have on the team. And if you want to go faster, a really good way to do that is to just have Claude do more stuff. Um, so he it just very much encourages that. This idea of underfunding, it's so interesting because in general there's this feeling like AI is going to allow you to not have as many employees, not have as many engineers. And so it's not only you can be more productive. What you're saying is that you will actually do better if you underfund. It's not just that AI can make you faster. It's you will get more out of the AI tooling if you have fewer people working on something. Yeah. If you if you hire great engineers, they'll figure out how to do it. And uh especially if you empower them to do it. This is something I actually talk talk a lot about with uh you know with like CTO's and kind of all sorts of companies. My advice generally is don't try to optimize. Don't don't try to cost cut at the beginning. Start by just giving engineers as many tokens as possible. And now now you're starting to see companies like you know at Anthropic we have you know everyone can use a lot of tokens. We're starting to see this come up as like a perk at some companies. Like if you join you get unlimited tokens. This is a thing I very much encourage because um it makes people free to try these ideas that would have been too crazy and then if there's an idea that works then you can figure out how to scale it and that's the point to kind of optimize and to cost cut figure out like you know maybe you can do it with haiku or with sonnet instead of opus or whatever but at the beginning you just want to throw a lot of tokens at it and see if the idea works and give engineers the freedom to do that. So the advice here is uh just be be loose with your tokens with this the cost on on using these models. People hearing this may be like of course he works at Anthropic. He wants us to use as many tokens as possible. But you're what you're saying here is the the most interesting innovative ideas will come out of someone just kind of taking it to the max and seeing what's possible. + +[`27:09`](https://youtu.be/We7BZVKbCVw?t=1629) Yeah. And I and I think the reality is like at small scale like you know you're not going to get like a giant bill or anything like this. Like if it's an individual engineer experimenting, it's the token cost is still probably relatively low relative to their salary or you know other costs of running the business. So it it's actually like not not a huge cost as the thing scales up. So like let's say you know they build something awesome and then it takes a huge amount of tokens and then the cost becomes pretty big. That's the point at which you want to optimize it. But don't don't do that too early. + +[`27:39`](https://youtu.be/We7BZVKbCVw?t=1659) Have you seen companies where their uh token cost is higher than their salary? Is that a trend you think we're going to find and see? + +[`27:45`](https://youtu.be/We7BZVKbCVw?t=1665) You know, at Anthropic, we're starting to see some engineers that are spending, you know, like hundreds of thousands a month in in tokens. Um, so we're starting to see this a little bit. Um, there's some companies that are we're starting to see similar things. Yeah. + +[`28:00`](https://youtu.be/We7BZVKbCVw?t=1680) Going back to coding, do you miss writing code? Is this something you're kind of sad about that this is no longer a thing you will do as a software engineer? It's funny for me, you know, like when when I learned engineering, for me it was very practical. I learned engineering so I could build stuff and for me I was I was selftaught, you know, like I studied economics in school, but um I didn't study CS, but I I taught myself engineering kind of early on. I was programming in like middle school and from the very beginning it was very practical. So I actually like I learned to code so that I can cheat on a math test. That was like the first thing we had these like graphing calculators and you know I just programmed the answer into + +[`28:38`](https://youtu.be/We7BZVKbCVw?t=1718) TI83. + +[`28:41`](https://youtu.be/We7BZVKbCVw?t=1721) T83 plus. Yeah. Yeah. Exactly. [laughter] + +[`28:42`](https://youtu.be/We7BZVKbCVw?t=1722) Plus. Yeah. So like I programmed the answers in and then the next like math test whatever like the next year that it was just like too hard. Like I couldn't program all the answers in because I didn't know what the questions were. And so I had to write like a little solver so that it it was a program that would just like solve these like uh you know these al algebra questions or whatever. And then I figured out you can get a little cable, you can give the program to the rest of the class and then the whole class gets A's. But then we all got caught and the teacher told us to knock it off. But from the very beginning it's it's always just been very practical for me where programming is a way to build a thing. It's not the end in itself. At some point I personally fell into the rabbit hole of kind of like the the beauty of of programming. Um so like I I wrote a book about TypeScript. Um, I started the actually at the time it was the world's biggest uh, TypeScript meetup just because I fell in love with the language itself. Uh, and I kind of got in deep into like functional programming and and all this stuff. I think a lot of coders they get distracted by this. For me, it was always sort of um they there is a beauty to programming and especially to functional programming. There's a beauty to type systems. Um, there there's a certain kind of like this like buzz that you get like when you solve like a really a really complicated uh math problem. It's kind of similar when you kind of balance the types or you know the program is just like really beautiful but it's really not the end of it. Um I think for me coding is very much a tool and it's a way to do things. Uh that said not everyone feels this way. So for example you know like there's one engineer uh on the team Lena who you know was still writing C++ on the weekends by hand because you know for her she just really enjoys writing C++ by hand. And so everyone is different and I think even as this field changes, even as everything changes, there's always space to do this, there's always space to enjoy the art um and to and and to kind of do do things by hand uh if you want. + +[`30:36`](https://youtu.be/We7BZVKbCVw?t=1836) Do you worry about your skills atrophing as an engineer? Is that something you worry about or is it just like, you know, this is just the way it's going to go? + +[`30:42`](https://youtu.be/We7BZVKbCVw?t=1842) I think it's just the way that that it happens. I I don't worry about it too much personally. I think for me like programming is on is on a continuum and you know like way back in the day you know like software actually is like relatively new right like if you look at the way programs are written today like using software that's running on a virtual machine or something this has been the way that we've been writing programs since probably the 1960s so you know it's been you know like 60 years or something like that. Before that it was punch cards. Before that it was switches. Before that it was hardware. And before that it was just you know like literally pen and paper. It was like a room a room full of people that were doing math on on paper. And so, you know, programming has always changed in this way. In some ways, you still want to understand the layer under the layer because it helps you be a better engineer. And I think this will be the case maybe for the next year or so. Um, but I think pretty soon it just won't really matter. It's just going to be kind of like the the assembly code wring running under the programmer or something like this. uh at an emotional level, you know, I I feel like I've always had to learn new things. And as a programmer, it's actually not it doesn't feel that new because there's always new frameworks, there's always new languages. It's just something that we're quite comfortable with in the field. But at the same time, I you know, this isn't true for everyone. And I think for some people, they're going to feel a greater sense of, I don't know, maybe like loss or nostalgia or atrophy or something like this. I don't know if you saw this, but Elon was saying that uh why isn't the AI just writing binary straight to binary? Uh because what's the point of all this, you know, programming abstraction in the end? + +[`32:13`](https://youtu.be/We7BZVKbCVw?t=1933) Yeah, it's a good question. I mean, it totally can do that if you wanted to. + +[`32:18`](https://youtu.be/We7BZVKbCVw?t=1938) Oh, man. So, what I'm hearing here is in terms there's always this question, should I learn to code? Should people in school learn to code? Uh what I heard from you is your take is in like a year or two, you don't really need to. My take is I think for for people that are using um there that are using quad code that are using agents to code today you still have to understand the layer under but yeah in a year or two it's not going to matter. I I was thinking about um what is the right like historical analog for this cuz like like somehow we have to situate this thing in history and and kind of figure out when have we gone through similar transitions. What's the right kind of mental model for this? I think the thing that's come closest for me is the printing press. And so you know if you look at Europe in uh you know like in the in the mid the mid400s literacy was actually very low. Uh there was sub 1% of the population it was scribes that uh you know they were the ones that did all the writing. They they were the ones that did all the reading. They were employed by like lords and kings that often were not literate themselves. And so you know it was their job of this very tiny percent of the population to do this. And at some point the you know Gutenberg and and the printing press came along and there was this crazy stat that in the 50 years after the printing press was uh built there was more printed material created than in the c in the in the thousand years before and so the the volume of printed material just went way up. Uh the cost went way down. It went down something like 100x over the next 50 years. And if you look at literacy, you know, it actually took a while because learning to read and write is, you know, it's quite hard. It takes an education system. It takes free time. You it takes like not having to work on a farm all day so that you actually have time for education and things like this. But over the next 200 years, it went up to like 70% globally. So I think this is the kind of thing that we might see is a similar kind of transition. And there was uh there was actually this interesting um historical document where there was an interview with some like scribe in the 1400s about like how do you feel about the printing press? And they were actually very excited because they were like actually the thing that I don't like doing is copying between books. The thing that I do like doing is drawing the art in books and then doing the book binding. And I'm really glad that now my time is freed up. And it's interesting like as an engineer I sort of felt like a peril with this. It's like this is sort of how I feel where I don't have to do the tedious work anymore of coding because this has always been sort of the detail of it. It's always been the tedious part of it and kind of like messing with like git and kind of using all these different tools. That that was not the fun part. The fun part is figuring out what to build and coming up with this. It's uh it's talking to users. It's thinking about these big systems. It's thinking about the future. It's collaborating with you know other people on the team. And that's what I get to do more of now. And what's amazing is that the tool you're building allows anybody to do this. People that have no technical experience can do exactly what you're describing. Like I'm I've been doing a bunch of random little projects and any it's just like anytime you get stuck just like help me figure this out and you get on block. Like I used to I was an engineer for early in my career for 10 years and I just remember spending so much time on like libraries and dependencies and things and just like oh my god what do I do and then looking on stack overflow and now it's just like help me figure this out and here's step by step one two three four okay we got this. + +[`35:41`](https://youtu.be/We7BZVKbCVw?t=2141) Yeah exactly exactly I was talking to an engineer earlier today they're like they're writing some service and go and you know it's been like a month already and they they built up the service like it's working quite well and then I was like okay so like how do you feel writing it? He was like, you know, like I I still don't really know Go, but [laughter] and I think we're going to start to see more and more of this. It's like if you know that it works correctly and efficiently, then you you don't actually have to know all the details. Clearly, the life of a software engineer has changed dramatically. It's like a whole new job now as of the past year or two. What do you think is the next role that will be most impacted by AI within either within tech like you know product managers, designers or even outside tech just like what do you think where do you think AI is going next? + +[`36:24`](https://youtu.be/We7BZVKbCVw?t=2184) I think it's going to be a lot of the roles that are adjacent to engineering. Um so yeah it could be like product managers, it could be design, could be data science. It is going to expand to pretty much any kind of work that you can do on a computer because the model is just going to get better and better at this. Um, and you know, like this is the co-work product is kind of the first way to get at this, but it's just the first one. And it's the thing that I think brings AI to a agentic AI to people that haven't really used it before, and people are starting just to to to get a sense of it for the first time. When I think back to engineering a year ago, no one really knew what an agent was. No one really used it. But nowadays, it's just the way that, you know, we do we do our work. And then when I look at non-technical work today um so you know like or maybe semi-technical like product work and you know like data science and things like this when you look at the kinds of AI that people are using it's all it's always these like conversational AI it's like a chatbot or whatever but no one really has used an agent before and this word agent just gets thrown around all the time and it's just like so misused it's like lost all meaning but agent actually has like a very specific technical meaning which is it's a it's a AI it's a LM that's able to use tools. So it doesn't just talk, it can actually act and it can interact with your system and you know this means like it can use your Google docs and it can it can send email. It can run commands on your computer and do all this kind of stuff. So I think like any kind of job where you do you use computer tools in this way. I think this is going to be next. This is something we have to kind of figure out as a as a society. This is something we have to figure out as an industry. Um and I think for me also this is one of the reasons it it feels very important and urgent to do this work at anthropic because I think we take this very very seriously. Um and so now you know we have economists we have uh policy folks we have social impact folks this is something we just want to talk about a lot so as society we can kind of figure out what to do because it shouldn't be up to us. + +[`38:21`](https://youtu.be/We7BZVKbCVw?t=2301) So the big question which you're kind of alluding to is jobs and job loss and things like that. There's this concept of Jevans paradox of just as we can do more we hire more and it's not actually as scary as it looks. What have you experienced so far I guess with AI becoming a big part of the engineering job? Just are you hiring more than if you didn't have AI and just thoughts on jobs? + +[`38:43`](https://youtu.be/We7BZVKbCVw?t=2323) Yeah, I mean for our team we're we're hiring. Um so quadco team is hiring. Um if you're interested just check out the jobs page on on anthropic. Personally, it's, you know, all this stuff has just made me enjoy my work more. I have never enjoyed coding as much as I do today because I don't have to deal with all the minutia. So, for me personally, it's been quite exciting. This is something that we hear from a lot of customers where they love the tool, they love Quad Code because it just makes coding delightful again. Uh, and that's just that's just so fun for them. But it's hard to know where this thing is going to go. And I again I just like I have to reach for these historical analoges. Uh and I I think the printing press is just such a good one because what happened is this technology that was locked away to a small set of people like knowing how to read and write became accessible to everyone. It was just inherently democratizing. Everyone started to be able to do this. And if that wasn't the case then something like the Renaissance just could never have happened because a lot of the Renaissance it was about like knowledge spreading. It was about like written records that people used to communicate. Um, you know, cuz there were no phones or anything like this. There was there was no internet at the time. So, it's about like what does this enable next? And I think that's the very optimistic version of it for me. And that's the part that I'm really excited about. It's just unimaginable, you know, like we couldn't be talking today if the printing press hadn't been invented. Like our microphones wouldn't exist. None of the things around us would exist. it just wouldn't be possible to coordinate such a large group of people if that wasn't the case. And so I imagine a world, you know, a few years in the future where everyone is able to program. And what does that unlock? Anyone can just build software anytime. And I have no idea. It's just the same way that, you know, in the 1400s, no one could have predicted this. Um, I think it's the same way. But I do think in the meantime, it's going to be very disruptive and it's going to be painful for a lot of people. Um, and again, as a society, this is a conversation that we have to have and this is a thing that we have to figure out together. + +[`40:45`](https://youtu.be/We7BZVKbCVw?t=2445) So, for folks hearing this that want to succeed and, you know, make it in this crazy turmoil we're entering, any advice? Is it, you know, play with AI tools, get really proficient at the latest stuff? Is there anything else that you recommend to help people uh stay ahead? Yeah, I think that's pretty much it. Uh, experiment with the tools, get to know them, don't be scared of them. um just you know dive in try them be on the bleeding edge beyond the frontier. Maybe the second piece of advice is try to be a generalist more than you have in the past. For example, in school a lot of people that study CS they learn to code and they don't really learn much else. Maybe they learn a little bit of systems architecture or something like this. But some of the most effective engineers that I work with every day and some of the most effective, you know, like product managers and so on, they cross over disciplines. So on the quad code team, everyone codes. You know, our product manager codes, our engineering manager codes, our designer codes, our finance guy codes, our data scientist codes. Like everyone on the team codes. And and then if I look at particular engineers, people often cross different disciplines. So some of the strongest engineers are hybrid product and infrastructure engineers or product engineers with really great design sense and they're able to do design also or an engineer that has a really good sense of the business and can use that to figure out what to do next. or an engineer that also loves talking to users and can just really channel what what users want to figure out what's next. So I think a lot of the people that will be rewarded the most over the next few years, they won't just be AI native and they don't just know how to use these tools really well, but also they're curious and they're generalists and they cross over multiple disciplines and can think about the broader problem they're solving rather than just the engineering part of it. Do you find these three separate disciplines still useful as a way to think about the team? They're, you know, engineering, design, uh, product management. Do you find like those, even though they are now coding and contributing to thinking about what to build, do you feel like those are three roles that will persist long term, at least at this point? I think in the short term it'll persist, but one thing that we're starting to see is there's maybe a 50% overlap in these roles where a lot of people are actually just doing the same thing and some people have specialties. for example, I code a little bit more versus cat RPM does a little bit more, you know, coordination or planning or, you know, forecasting or things like this. + +[`43:05`](https://youtu.be/We7BZVKbCVw?t=2585) Stakeholder alignment. + +[`43:08`](https://youtu.be/We7BZVKbCVw?t=2588) Stakeholder alignment. Exactly. I I do think that there's a future where I think by the end of the year what we're going to start to see is these start to get even murkier murkier where I think in some places the title software engineer is going to start to go away and it's just going to be replaced by builder or maybe it's just everyone's going to be a product manager and everyone codes or something like this. Who says hiring has to be fair? Every founder and hiring manager I've been speaking with these days is feeling the same pressure. Hire the best people as fast as possible. But [music] recruiting is time consuming, alignment is hard, and competition for great talent keeps getting tighter. That's why teams like 11 Labs, Brex, Replet, Deal, and 5,000 [music] other organizations use MetaView, the AI company giving high performance teams a real unfair advantage in hiring. They give you a suite of AI agents that behave like recruiting co-workers. They find candidates for you based on your exact criteria, [music] take interview notes automatically, gather insights across your hiring process, and help you identify the best candidates in your pipeline. AI handles the recruiting toil and gives you a real source of truth. That means hours saved per hire and a team focused on what matters most, winning the right [music] candidates. Don't let your competitors outhire you. Metav customers close roles 30% faster. Try Metaview today for free and [music] get an extra month of sourcing at metaview.ai/lenny. That's me. Lenny. You talked about how you're enjoying coding more. I actually did this little informal survey on Twitter. I don't know if you saw this where I just asked I did three different polls. I asked engineers, are you enjoying your job more or less since adopting AI tools? And then I did a separate one for PMs and one for designers. And both engineers and PMs, 70% of people said they are enjoying their job more and about 10% said they're enjoying their job less. Designers, interestingly, only 55% said they are enjoying their job more and 20% said they're enjoying their job less. Thought that was really interesting. + +[`45:13`](https://youtu.be/We7BZVKbCVw?t=2713) That's super interesting. I' I'd love to talk to these people uh you know, both in the more bucket and the less bucket just to understand. Do did you get to follow up with any of them? They a few people replied and we're actually doing a follow poll that we'll link to in the show notes of going deeper into some of the stuff, but a lot of there's like, you know, the factors that make it more fun and less fun. The designers, they didn't share a lot actually of just like the people that are actually asked just like why are you enjoying your job less? And I didn't hear a lot. So, I'm curious what's going on there. + +[`45:38`](https://youtu.be/We7BZVKbCVw?t=2738) Yeah, I I'm seeing this a little bit with uh at anthropic. I think everyone is fairly technical. This is something that we screen for, you know, when when people join. We have there there's a lot of technical interviews that people go go through even for non-technical functions. Uh and you know our designers largely code. So I think for them this is something that they have enjoyed from what I've seen because now instead of bugging engineers they can just like go in and code. And even some designers that didn't code before have just started to do it and for them it's great cuz they can unblock themselves. But I'd be really interested just to hear more people's experiences cuz I I I bet it's not uniform like that. + +[`46:19`](https://youtu.be/We7BZVKbCVw?t=2779) Yeah. So maybe if you're listening to this, leave a comment if you're finding your jobs less fun and enjoying your job less cuz what you're saying and what I'm hearing from most people, 70% of PMs and engineers are loving their job more. That's like if you're not in that bucket, you could something's going on. + +[`46:34`](https://youtu.be/We7BZVKbCVw?t=2794) Yeah. Yeah. We do see that people use also different tools. So for example, our designers, they use uh the cloud desktop app a lot more to to do their coding. So you just download the desktop app. There's a code tab. Uh it's right next to co-work and it's actually the same exact quad code. So it's like the same agent and everything. We've had this for, you know, for many, many months. Uh and so you can use this to code in a way that you don't have to open a bunch of terminals, but you still get the power of quad code. And the biggest thing is you can just run as many, you know, quad sessions in parallel as you want. We, you know, we call this multi-quading. + +[`47:06`](https://youtu.be/We7BZVKbCVw?t=2826) So this is a it's it's a little more native, I think, for folks that are not engineers. And really, this is back to bringing the product to where the people are. You don't want to make people use a different workflow. You don't want to make them go out of their way to learn a new thing. It's whatever people are doing, if you can make that a little bit easier, then that's just going to be a much better product that people enjoy more. And this is just this principle of latent demand, which I I think is just the the single most important principle in product. + +[`47:30`](https://youtu.be/We7BZVKbCVw?t=2850) Can you talk about that actually because I was going to go there. Explain what this principle is and and and just what happens when you unlock this latent demand. Latent demand is this idea that if you build a product in a way that can be hacked or can be kind of mi [clears throat] misused by people in a way it wasn't really designed for to do kind of something that they want to do then this helps you as the product builder learn where to take the product next. So an example of this is uh Facebook marketplace. So the the manager for the team Fiona she she was actually the founding manager for uh the marketplace team and she talks about this a lot. Facebook Marketplace. It started based on the observation back in uh this must have been like 20 2016 or or something like this that 40% of posts in Facebook groups are buying and selling stuff. So this is crazy. It's like people are abusing the Facebook groups product to buy and sell. And it's not it's not abuse in kind of like a security sense. It's abuse in that no one designed the product for this, but they're kind of figuring it out because it's just so useful for this. And so it was pretty obvious if you build a better product to let people buy and sell, they're going to like it. And it was just very obvious that marketplace would be a hit from this. And so the first thing was buy and sell groups. So kind of special purpose groups to let people do that. And the second product was marketplace. Uh Facebook dating I think started in a pretty similar place. And I think that the observation was if you look at people looking if you look at uh profile views so people looking at each other's profiles on Facebook 60% of profile views were people that are not friends with each other that are opposite gender. And so this is this kind of like you know like traditional kind of dating setup but you know people are just like creeping on each other. So maybe if you can build a product for this it's you know it might work. Um and so this idea of latent demand I think is just so powerful. And for example this is also where co-work came from. We saw that for the last 6 months or so a lot of people using quad code were not using it to code. There was someone on Twitter that was using it to grow tomato plants. There was someone else using it to analyze their genome. Someone was using it to uh recover photos from a corrupted hard drive. It was like uh wedding photos. Uh there was someone that was using it for uh I think like uh they they were using it to analyze a MRI. So there there's just all these different use cases that are not technical at all. And it was just really obvious like people are jumping through hoops to use a terminal to do this thing. Maybe we should just build a product for them. And we saw this actually pretty early back in maybe May of last year. I remember walking into the office and our data scientist Brendan was had a quad code on his uh computer. He just had a terminal up and I was like I was shocked. I was like Brendan what what are you doing? Like you you figured out how to open the terminal which is you know it's a very engineering product. Even a lot of engineers don't want to use a terminal. It's just like a it's like just like the lowest level way to to do your work. Um just really really uh kind of in the weeds of the computer. And so he figured out how to use the terminal. He downloaded Node.js. He downloaded quad code and he was doing SQL analysis in a terminal and it was crazy. And then the next week all the data scientists were doing the same thing. So when you see people abusing the product in this way, using it in a way that it wasn't designed in order to do something that is useful for them, it's just such a strong indicator that you should just build a product and and people are going to like that. It's something that's special purpose for that. I think now there there's also this kind of interesting second dimension to latent demand. This is sort of the traditional framing is look at what people are doing, make that a little bit easier, empower them. The modern framing that I've been seeing in the last 6 months is a little bit different and it's look at what the model is trying to do and make that a little bit easier. And so when we first started building quad code, I think a lot of the way that people approached designing things with LLMs is they kind of put the model in a box and they were like, here's this application that I want to build. Here's the thing that I wanted to do. model, you're going to do this one component of it. Here's the way that you're going to interact with these tools and APIs and whatever. And for cloud code, we inverted that. We said the product is the model. We want to expose it. We want to put the minimal scaffolding around it. Give it the minimal set of tools. So, it can do the things. It can decide which tools to run. It can decide in what order to run them in and so on. And I I think a lot of this was just based on kind of latent demand of what the model wanted to do. And so, in research, we call this being on distribution. Uh you want to see like what the model is trying to do. In product terms, latent demand is just the same exact concept but applied to a model. + +[`51:56`](https://youtu.be/We7BZVKbCVw?t=3116) You talked about co-work something that I saw you talk about when you launched that initially is you your team built that in 10 days. + +[`52:03`](https://youtu.be/We7BZVKbCVw?t=3123) That's insane. Uh I it came out I think it was like you know used by millions of people pretty quickly something like that being built in 10 days. Uh anything there any stories there other than just it was just you know we use cloud code to build it and that's it. + +[`52:16`](https://youtu.be/We7BZVKbCVw?t=3136) Yeah it's funny. Uh cloud code like I said when we released it was not immediately a hit. it became a hit over time and there was a few inflection points. So one was you know like Opus 4 uh it just really really inflected and then in November it inflected and it just keeps inflecting. The growth just keeps getting steeper and steeper and steeper every day. But you know for the first few months it wasn't a hit. Uh people used it but a lot of people couldn't figure out how to use it. They didn't know what it was for. The model still like wasn't very good. Co-work when we released it was just immediately a hit much more so than cloud code was early on. I think a lot of the credit honestly just goes to like Felix and and Sam and the and Jenny and the the team that built this. It's just an incredibly strong team. And again, the the place co came from is just this latent demand. Like we saw people using quad code for these non-technical things and we're trying to figure out what do we do? And so for a few months the team was exploring they were trying all sorts of different options and in the end someone was just like okay what what if we just take quad code and put it in the desktop app and that's essentially the thing that worked. And so over 10 days they just completely use quad code to build it. Uh and you know co-work is actually there's this very sophisticated security system that's that's built in and essentially these guard rails to make sure that the model kind of does the right thing. It doesn't go off the rails. So for example we ship an entire virtual machine with it. And quad code just wrote all of this code. So we just had to think about all right how do we make this a little bit safer a little more self-guided for uh people that are not engineers. It was fully implemented with quad code. took about 10 days. We launched it early. You know, it was still pretty rough and it's still pretty rough around the edges. But this is kind of the way that we learn um both on the product side and on the safety side is we have to release things a little bit earlier than we think so that we can get the feedback so that we can talk to users. We can understand what people want and and that will shape where the product goes in the future. + +[`54:06`](https://youtu.be/We7BZVKbCVw?t=3246) Yeah, I think that point is so interesting and and it's so unique. There's always been this idea release early, learn from users, get feedback, iterate. The fact that it's hard to even know what the AI is capable of and how people will try to use it is like is a unique reason to start releasing things early that'll help you as you exactly describe this idea of what is the latent demand in this thing that we didn't really know. Let's put it out there and see what people do with it. + +[`54:31`](https://youtu.be/We7BZVKbCVw?t=3271) Yeah. And in philanthropic as a safety lab, the other dimension of that is safety because um you know like when you think about model safety, there's a bunch of different ways to study it. Sort of the lowest level is alignment and mechanistic interpretability. So this is when we train the model, we want to make sure that it's safe. We at this point have like pretty sophisticated technology to understand what's happening in the neurons to trace it. And so for example like if there's a neuron related to deception we can start we're starting to get to the point where we can monitor it and understand that it's activating. Um and so this is just this is alignment this is mechanistic interpretability. It's like the lowest layer. The second layer is evolves and this is essentially a laboratory setting. The model is in a petri dish and you study it and you put in a synthetic situation and just say okay like model what do you do and are you doing the right thing? Is it aligned? Is it safe? And then the third layer is seeing how the model behaves in the wild. And as the model gets more sophisticated, this this becomes so important because it might look very good on these first two layers but not great on the third one. We released cloud code really early because we wanted to study safety and we actually used it within anthropic for I think four or 5 months or something before we released it because we weren't really sure like this is the first agent that you know the first big agent that I think folks had released at that point. um it was definitely the first uh you know coding agent that became broadly used and so we weren't sure if it was safe and so we actually had to study it internally for a long time before we felt good about that and even since you know there's a lot that we've learned about alignment there's a lot that we've learned about safety that we've been able to put back into the model back into the product and for co-work it's pretty similar uh the model's in this new setting it's you know doing these tasks that are not engineering tasks it's an agent that's acting on your behalf it looks good on alignment it looks good on evals we try to internally it looks good we it with a few customers, it looks good. Now, we have to make sure it's safe in the real world. And so, that's why we release a little early. That's why we call it a research preview. Um, but yeah, it's just it's constantly improving. Um, and this is really the only way to to make sure that over the long term the model is aligned and it's doing the right things. It's such a wild space that you work in where there's this insane competition and pace. At the same time, there's this fear that if you get some if the the you know the god can escape and cause damage and just finding that balance must be so challenging. What I'm hearing is there's kind of these three layers and I know there's like this could be a whole podcast conversation is how you all think about the safety piece but just what I'm hearing is there's these three layers you work with. Uh there's kind of like observing the model thinking and operating. There's tests eval that tell you this is doing bad things and then releasing it early. I haven't actually heard a ton about that first piece. That is so cool. So you guys can there's an observability tool that can let you peek inside the model's brain and see how it's thinking and where it's heading. Yeah, you should uh you should at some point have Chris Ola on the podcast because uh he he's just the industry expert on this. He he invented this field of uh we call it mechanistic interpretability. Uh and the the idea is uh you know like at its core like what is your brain? Like what are what is it? It's like it's a bunch of neurons that are connected. And so what you can do is like in a human brain or animal brain you can study it at this kind of mechanistic level to understand what the neurons are doing. It turns out surprisingly a lot of this does translate to models also. So model neurons are not the same as animal neurons but they behave similarly in a lot of ways. And so we've been able to learn just a ton about the way these neurons work, about, you know, this layer or this neuron maps to this concept, how particular concepts are encoded, how the model does planning, how it how it thinks ahead, you know, like a long time ago, we weren't sure if the model is just predicting the next token or is doing something a little bit deeper. Now, I think there's actually quite strong evidence that it is doing something a little bit deeper. And then the structures that were to do this are pretty sophisticated now where as the models get bigger, it's not just like a single neuron that corresponds to a concept. A single neuron might correspond to a dozen concepts. And if it's activated together with other neurons, this is called superposition. And uh together it represents this more sophisticated concept. And it's just something we're learning about all the time, you know, and philanthropic as as we think about the way this space evolves, doing this in a way that is safe and good for the world is just this is the reason that we exist and this is the reason that everyone is at anthropic. Uh, everyone that is here, this is the reason why they're here. So, a lot of this work we actually open source. Uh, we publish it a lot. Um and you know we publish very freely to talk about this just so we can inspire other labs that are working on similar things to do it in a way that's safe and this is something that we've been doing for cloud code also we call this the race to the top uh internally and so for cloud code for example we released an open source sandbox and this is a sandbox they can run the the agent in and it just makes sure that there's certain boundaries and it can't access like everything on your system. Uh, and we made that open source and it actually works with any agent, not just quad code because we wanted to make it really easy for others to do the same thing. Um, so this is just the same principle of race to the top. Um, we we want to make sure this thing goes well and this is just the this is the lever that we have. + +[`59:38`](https://youtu.be/We7BZVKbCVw?t=3578) Incredible. Okay, I definitely want to spend more time on that. I I will follow up with this suggestion. Something else that I've been noticing in the in the field across engineers, product managers, others that work with agents is there's this kind of anxiety people feel when their agents aren't working. There's a sense that like, oh man, Nza has a question, I need to answer or it's like blocked on something or it's or I just like I I'm like there's all this productivity I'm losing. I can't like I need to wake up and get it going again. Is that something you feel? Is that something your team feels? Do you feel like this is a a problem we need to track and think about? I always have a bunch of agents running. So like at the moment I have like five agents running and at any moment like you know like I I wake up and I I stored a bunch of agents. Like the first thing I did when I woke up is like oh man I I want I really want to check this thing. So like I opened up my phone quad iOS app code tab uh you know like agent do do blah blah blah cuz I I wrote some code yesterday and I was like wait did did I do this right? I was like kind of double double guessing something and it and it was correct. But now it's just like so easy to do this. So I don't know, there is this little bit of anxiety. Maybe I personally haven't really felt it just cuz I have agents running all the time. Um, and I'm also just like not locked into a terminal anymore. Maybe a third of my code now is in the terminal, but also a third is uh using the desktop app and then a third is the iOS app, which is just so surprising cuz I did not think that this would be the way that I code uh in even in 2026. I love that you describe it as coding still, which is just talking to the to cloud code to code for you essentially. And it's interesting that this is now like this is now coding. Coding now is describing what you want, not writing actual code. + +[`1:01:18`](https://youtu.be/We7BZVKbCVw?t=3678) I I I kind of wonder if uh the people that used to code using punch cards or whatever, if you show them software, what they would have said. Isn't that crazy? And I I remember reading something this was maybe like very early versions of like ACM uh like like magazine or something where people were saying no it's not the same thing like this isn't this isn't really coding uh and you know like they called it programming I think coding is kind of a new word + +[`1:01:40`](https://youtu.be/We7BZVKbCVw?t=3700) but I kind of think about this like in the back in the you know my family is from the Soviet Union I you know I I was born in Ukraine um and my grandpa was actually one of the first programmers in the Soviet Union and he programmed using punch cards And uh you know like he he told my mom uh growing up told these stories of like or she she told these stories that when she was growing up he would bring these punch cards home and there was these like big stacks of punch cards and for her she would like draw all over them with crayons and that was like her childhood memory but for him that was like his experience of programming and he actually never saw the software transition but at some point it did transition to software and I think there's probably this older generation of programmers that just didn't take software very seriously and they would have been like well you know it's not really coding. But I I think this is a field that just has always been changing in this way. + +[`1:02:28`](https://youtu.be/We7BZVKbCVw?t=3748) Uh I don't think you know this, but I was born in Ukraine also. + +[`1:02:32`](https://youtu.be/We7BZVKbCVw?t=3752) Oh, I don't know. Yeah. Which time? + +[`1:02:34`](https://youtu.be/We7BZVKbCVw?t=3754) I'm I'm from Odessa. + +[`1:02:36`](https://youtu.be/We7BZVKbCVw?t=3756) Oh, me too. + +[`1:02:36`](https://youtu.be/We7BZVKbCVw?t=3756) Oh, me too. [laughter] [laughter] + +[`1:02:36`](https://youtu.be/We7BZVKbCVw?t=3756) What? + +[`1:02:39`](https://youtu.be/We7BZVKbCVw?t=3759) Yeah, that's crazy. + +[`1:02:42`](https://youtu.be/We7BZVKbCVw?t=3762) Wow. Incredible. What a moment. Uh maybe related in some small way. + +[`1:02:46`](https://youtu.be/We7BZVKbCVw?t=3766) Uh what year did your home did you leave and your family leave? + +[`1:02:50`](https://youtu.be/We7BZVKbCVw?t=3770) Uh we came in 95. + +[`1:02:52`](https://youtu.be/We7BZVKbCVw?t=3772) Okay. We left in ' 88. a little earlier. + +[`1:02:53`](https://youtu.be/We7BZVKbCVw?t=3773) Oh, yeah. + +[`1:02:54`](https://youtu.be/We7BZVKbCVw?t=3774) What a different life that would have been to not to not leave, huh? + +[`1:02:59`](https://youtu.be/We7BZVKbCVw?t=3779) Yeah. I just I feel I feel so lucky every day that uh get get to grow up here. + +[`1:03:03`](https://youtu.be/We7BZVKbCVw?t=3783) Yeah. My family anytime there's like a toaster or a meal, they're just like to America. It's like, okay, enough about that. But you get it, you know, once you start really thinking about what life could have been. + +[`1:03:14`](https://youtu.be/We7BZVKbCVw?t=3794) Yeah. Yeah. Exactly. Yeah. We do we do the same toast, but it's still vodka. + +[`1:03:19`](https://youtu.be/We7BZVKbCVw?t=3799) It's still vodka. Absolutely. [laughter] Oh, man. Okay. Let me ask you a couple more things here. You shared some really cool tips for how to get the most out of AI, how to build on AI, how to build great products on AI. One tip you shared is give your team as many tokens as they want. Just like let them experiment. You also shared just advice generally of just build towards the model where the model is going, not to where it is today. What other advice do you have for folks that are trying to build AI products? + +[`1:03:44`](https://youtu.be/We7BZVKbCVw?t=3824) I'd probably share a few more things. So, one is don't try to box the model in. Um I I think a lot of people's instinct when they build on the model is they try to make it behave a very particular way. They're like this is a component of a bigger system. I I think some examples of this are people layering like very strict workflows on the model for example you know to say like you must do step one then step two then step three and you have this like very fancy orchestrator doing this. But actually almost always you get better results if you just give the model tools you give it a goal and you let it figure it out. I think a year ago you actually needed a lot of the scaffolding but nowadays you don't really need it. So, you know, I I don't know what to call this principle, but it's like, you know, like ask not what the model can do for you. Maybe maybe it's something like this. Just think about how do you give the model the tools to do things. Don't try to overcurate it. Don't try to put it into a box. Don't try to give it a bunch of context up front. Give it a tool so that it can get the context it needs. You're just going to get better results. I think a second one is um maybe actually like a a more even more general version of this principle is just the bitter lesson. Uh and actually for the quad code team we have a you know hopefully hopefully um listeners have have read this but Rich Sutton had this blog post maybe 10 years ago called the bitter lesson. Uh and it's actually a really simple idea. His idea was that the more general model will always outperform the more specific model and I think for him he was talking about like self-driving cars and other domains like this but actually there's just so many corlaries to the bitter lesson. And for me, the biggest one is just always bet on the more general model and you know over the long term like don't don't try to use tiny models for stuff. Don't try to like fine-tune. Don't try to do any of this stuff. There's like some applications you know there's some reasons to do this but almost always try to bet on the more general model if you can if you have that flexibility. Um and so these workflows are essentially a way that uh you know it's it's not it's not a general model. It's putting the scaffolding around it. And in general what we see is maybe scaffolding can improve performance maybe 10 20% something like this but often these gains just get wiped out with the next model. Uh so it's almost better to just wait for the next one. And I think maybe this is a final principle and something that quad code I think got right in hindsight. From the very beginning, we bet on building for the model six months from now, not for the model of today. And for the very early versions of the product, it just wrote so little of my code cuz I I didn't trust it cuz, you know, it was like sonnet 3.5, then it was like 3.6 or forget 3 3.5 new, whatever whatever whatever name we gave it. Um, these models just weren't very good at coding yet. Um, they were they were getting there, but it was still pretty early. So back then the model did uh you used git for me it automated some things but it it really wasn't doing a huge amount of my coding and so the bet with quad code was at some point the model gets good enough that it can just write a lot of the code and this is a thing that we first started seeing with opus 4 and sonnet 4 and opus 4 was our first kind of ASL3 class model uh that we released back in May and we just saw this inflection because everyone started to use quad code for the first time and that was kind of when our growth really went exponential and like I said it's kind of it stayed there. So I think this is some this is advice that I actually give to to a lot of folks especially people building startups. It's going to be uncomfortable cuz your product market fit won't be very good for the first 6 months but if you build for the model 6 months out when that model comes out you're just going to hit the ground running and the product is going to click and and start to work. And when you say build for the model 6 months out what is what is it that you think people can assume will happen? Is it just generally it will get better at things? Is it just like okay, it's like almost good enough and that's a sign that it'll probably get better at that thing. Is there any advice there? + +[`1:07:31`](https://youtu.be/We7BZVKbCVw?t=4051) I think that's a good way to do it. Like, you know, obviously within an AI lab, we get to see the specific ways that it gets better. [laughter] + +[`1:07:38`](https://youtu.be/We7BZVKbCVw?t=4058) So, it's a it's a little unfair, but we we also we try to talk about this. So, you know, like one of the ways that it's going to get better is it's going to get better and better at using tools and using computers. This is a bet that I would make. Uh, another one is it's going to get better and better for long for running for long periods of time. And this is a place, you know, like there's all sorts of studies about this, but if you just trace the trajectory or, you know, maybe even like for my own experience when I used Sonnet 3.5 back, you know, a year ago, it could run for maybe 15 or 30 seconds before before it started going off the rails and you just really had to hold its hand through any kind of complicated task. But nowadays with Opus 4.6, fix, you know, on average it'll run maybe 10, 30, 20, 30 minutes unattended and I'll just like start another quad and have it do something else. And you know, like I said, I always have a bunch of quads running. Uh, and they can also run for hours or even days at a time. I think there are some examples where they ran for many weeks. And so I think over time this is going to become more and more normal where the models are running for a very very long period of time and you you don't have to sit there and babysit them anymore. + +[`1:08:41`](https://youtu.be/We7BZVKbCVw?t=4121) So we just talked about tips for building AI products. Any tips for someone just using cloud code say for the first time or just someone already using cloud code that wants to get better? What are like a couple pro tips that you could share? + +[`1:08:53`](https://youtu.be/We7BZVKbCVw?t=4133) I will give a caveat which is there's no one right way to use quad code. So I I can share some tips but honestly this is a dev tool. Developers are all different. Developers have different preferences. They have different environments. So there's just so many ways to use these tools. There's no one right way. Um you you sort of have to find your own path. Luckily you can ask Quad Code. Uh it's able to make recommendations. It can edit your settings. It kind of knows about itself. So, it can help it can help with that. A few tips that generally I find pretty useful. So, number one is just use the most capable model. Um, currently that's Opus 4.6. I have maximum effort enabled always. The thing that happens is sometimes people try to use a less expensive model like sonnet or something like this. But because it's less intelligent, it actually takes more tokens in the end to do the same task. Um, and so it's actually not obvious that it's cheaper if you use a less expensive model. often it's actually cheaper and less token intensive if you use the most capable model because it can just do the same thing much faster with less correction, less uh less handholding and so on. So that's the first tip is just use the best model. The second one is use plan mode. I start almost all of my tasks in plan mode, maybe like 80%. And plan mode is actually really simple. All it is is we inject one sentence into the model's prompt to say please don't write any code yet. That's it. like there's there's actually like nothing fancy going on. It's just the simplest thing. + +[`1:10:12`](https://youtu.be/We7BZVKbCVw?t=4212) Um, and so for people that are in the terminal, it's just shift tab twice and that gets you into plan mode. Uh, for people in the desktop app, there's a little button. On web, there's a little button. It's coming pretty soon to mobile also. Uh, and we just launched it for the SWAC integration, too. Uh, so plan mode is the second one. And uh, essentially the model would just go back and forth with you. Once the plan looks good, then you let the model execute. I auto accept edits after that because if the plan looks good, it's just going to oneshot it. It'll get it right the first time almost every time with Opus 4.6. And then maybe the third tip is just play around with different interfaces. I think a lot of people when they think about cloud code, they think about a terminal. Um, and you know, of course, we support every terminal. We support like Mac, Windows, you know, like whatever terminal you might use, it works perfectly. But we actually support a lot of other form factors too like you know, we have like iOS and Android apps. We have a desktop app. There's uh you know the Slack integration. There's all sorts of things that we support. So I would just like play around with these. And again it's like every engineer is different. Everyone that's building is different. Just find the thing that feels right to you and and use that. You don't have to use a terminal. It's the same quad agent running everywhere. + +[`1:11:17`](https://youtu.be/We7BZVKbCVw?t=4277) Amazing. Okay. Just a couple more questions to round things out. What's your take on Codeex? How do you feel about that product? How do you feel about where they're going? Just kind of competing in this very competitive space uh in coding agents. Yeah, I actually haven't really used it, but uh I I think I did use it maybe when it came out. It looked a lot like Quad Code to me, so that was kind of flattering. It's I think it's actually good, you know, to have more competition cuz people should get to choose and hopefully it forces all of us to like do a even better job. Honestly, for our team though, we're just focused on solving the problems that users have. Um so for us, you know, we don't spend a lot of time looking at competing products. We don't really try the other products. I you know you kind of you want to be aware of them. You want to know they exist but for me I just I love talking to users. I love making the product better. Um I I love just acting on on feedback. So it's really just about building a building a good product. + +[`1:12:15`](https://youtu.be/We7BZVKbCVw?t=4335) Maybe a last question. So I talked to Ben man co-founder of Anthropic. What what to talk to you about. He had a bunch of suggestions which I've integrated throughout our chat. One question he had for you is what's your plan post AGI? What do you think you're going to be doing? What's your life like once we hit AGI? whatever that means. + +[`1:12:33`](https://youtu.be/We7BZVKbCVw?t=4353) So before I joined Anthropic, um I was actually living in rural Japan and it was like a totally different lifestyle. Um I was like the only engineer in the town. I was the only English speaker in the town. It was just like a totally different vibe. Like a couple times a week I would like bike to the farmers market. Uh and you know you like bike by like rice patties and stuff. It was just like a totally different speed than just complete opposite of San Francisco. One of the things that I really liked is a way that we got to know our neighbors and we kind of built friendships is by trading like pickles. So in that in the town where we lived, it was actually like everyone made like miso. Everyone made pickles. Uh and so I actually got like decently good at making miso. Um and you know I made a bunch of batches and um this is something that I still make. Uh miso is this interesting thing where it teaches you to think on these longtime skills. That's just very different than engineering cuz like uh you know like a batch of white miso takes like at least three months to make and a red miso is like you know 2 3 4 years. You just have to be very patient. You kind of mix it up and then you just like wet it sit. You have to be very very patient. + +[`1:13:37`](https://youtu.be/We7BZVKbCVw?t=4417) So I the thing that I love about it is just thinking in these longtime skills. Uh, and yeah, I think postGI or if I wasn't at anthropic, I'd probably be making miso. [laughter] + +[`1:13:49`](https://youtu.be/We7BZVKbCVw?t=4429) I love this answer. Uh, Ben asked me to ask you about what's the deal with you and miso and so I love that you answered it. Okay, so the future the future might be just going deep into miso, getting really good at get making miso. Uh, amazing. Uh, Boris, this was incredible. I feel like we're we're brothers now from Ukraine. Uh before we get to a very exciting lightning round, is there anything else that you wanted to share? Is there anything you want to leave listeners with? Anything you want uh you want to double down on? + +[`1:14:19`](https://youtu.be/We7BZVKbCVw?t=4459) Yeah, I I think I would just like underscore, you know, like for for anthropic since the beginning, this idea of like starting at coding, then getting to tool use, then getting to computer use has just been the way that we think about things. And we this is the way that we know the models are going to develop or, you know, the way that we want to build our models. And it's also the way that we get to learn about safety, study it, and improve it the most. So, you know, everything that's happening right now around, you know, just like Quad Code becoming this huge, you know, multi-billion dollar business and, you know, like now all of my friends use Quad Code and they just text me about it all the time. Uh, so just like, you know, this thing getting kind of big and in some ways it's a total surprise because this isn't kind of the we didn't know that it would be this product. We didn't know that it would start in a terminal or anything like this. But in some ways, it's just totally unsurprising because this has been our belief as a company for for a long time. At the same time, it just feels still very early, you know, like most of the world still does not use quad code. Most of the world still does not use AI. So, it just feels like this is 1% done and there's so much more to go. + +[`1:15:23`](https://youtu.be/We7BZVKbCVw?t=4523) Yeah. Man, that's insane to think seeing the numbers that are coming out. You guys just raised a bazillion dollars. Uh I think Cloud Code alone is making$2 billion dollars in revenue. you think Anthropic, I think the number you guys put out, you're making 15 billion in revenue. It's uh insane to just think this is how early it still is and just the numbers we're seeing. + +[`1:15:44`](https://youtu.be/We7BZVKbCVw?t=4544) Yeah. Yeah. Yeah. It's crazy. And and I mean like the the way that Quad Code has kept growing is honestly just the users. Like we so many people use it. They're so passionate about it. They fall in love with the product and then they tell us about stuff that doesn't work, stuff that they want. And so like the only reason that it keeps improving is because everyone is using it. Everyone is talking about it. Everyone keeps giving feedback and this is just the single most important thing and you know for me this is the way that I love to spend my day is just talking to users and making it better for them + +[`1:16:11`](https://youtu.be/We7BZVKbCVw?t=4571) and making me so + +[`1:16:13`](https://youtu.be/We7BZVKbCVw?t=4573) and making me so well the you know the miso is like not super involved it just you just got to wait you just got to wait + +[`1:16:19`](https://youtu.be/We7BZVKbCVw?t=4579) well Boris with that we've reached our very exciting lightning round I've got five questions for you are you ready + +[`1:16:26`](https://youtu.be/We7BZVKbCVw?t=4586) let's do it first question what are two or three books that you find yourself recommending most to other people + +[`1:16:31`](https://youtu.be/We7BZVKbCVw?t=4591) I I'm a greeter. Uh I would start with the technical book one is it it is functional programming in Scola. This is the single best technical book I've ever read. It's very weird because you're probably not going to use Scola and I don't know how much this matters in the future now but there's this just elegance to functional programming and thinking in types and this is just the way that I code and the way that I can't stop thinking about coding. So you know you could think of it as a historical artifact. You could think of it as something that will level you up. + +[`1:16:58`](https://youtu.be/We7BZVKbCVw?t=4618) I love this neverbeforementioned book. My favorite. + +[`1:17:02`](https://youtu.be/We7BZVKbCVw?t=4622) Oh, amazing. Amazing. Uh, okay. Second one is uh Accelerondo by Straws. This is probably, you know, like my my big genre is uh is sci-fi. Uh like probably sci-fi and fiction. Accelerondo is just this incredible book and it it it's just so fast-paced. The pace gets faster and faster and faster. And I just feel like it captures the essence of this moment that we're in more than any other book that I've read. Just the speed of it. And it starts as a liftoff is starting to happen and you know starting to approach the singularity and it ends with like this like collective lobster consciousness orbiting Jupiter. Um and you know this happens over like the span of a few decades or something. So the the pace is just incredible. I I really love it. Maybe I'll I'll do one more book. Uh the wandering earth uh wandering earth by uh sishlu. So he's the guy that did uh three body problem. I think a lot of people know him for that. I actually I think your body problem was awesome, but I actually liked his short stories even more. So, Wandering Earth is one of the short story collections and it just has some really really amazing stories and it it's also just quite interesting to see uh Chinese sci-fi because it has a very different perspective than Western sci-fi and kind of the way that um at least he as a writer thinks about it. So, it's just really really interesting to read and just beautifully written. It's so interesting how sci-fi has prepared us to think about where things are going. Just like it creates these mounts to models of like okay I see I've read about this sort of world. Yeah. I think I think for me this is like the reason that I joined anthropic actually cuz uh you know like like I said I was living in this rural place. I was thinking these longtime skills because everything is just so slow out there at least compared to SF. Um and just like all the things that you do are based around the seasons and it's based around this food that takes many many months. That's the way that kind of like social events are organized. That's the way you kind of organize your time. You like you go to the farmers market and it's like it's pimmen season and you know that because there's like 20 pimmen vendors and then the next week the season is done and it's like grape season and you kind of see this. So it's like these kind of longtime skills and I was also reading a bunch of sci-fi at the time and just like being in this moment I was like you know just thinking about these long time scales. I know how this thing can go and I just I felt like I had to contribute to it going a little bit better and that's actually why I ended up at Ant and Ben man was also a big part of that too. + +[`1:19:18`](https://youtu.be/We7BZVKbCVw?t=4758) I feel like I want to do a whole podcast just talking about your time in Japan and the journey of Boris through Japan to anthropic but we'll keep it we'll keep it short. Uh I'll quickly recommend a sci-fi book to you if you haven't read it. Have you read Fire Upon the Deep? + +[`1:19:33`](https://youtu.be/We7BZVKbCVw?t=4773) Uh this is Ving, right? Yeah. It's great. + +[`1:19:36`](https://youtu.be/We7BZVKbCVw?t=4776) Yes. Okay. That one's like it's like so interesting from a AI AGI perspective. Uh so few people have read that so um I myself + +[`1:19:46`](https://youtu.be/We7BZVKbCVw?t=4786) Yeah. It's like a lot. + +[`1:19:47`](https://youtu.be/We7BZVKbCVw?t=4787) Yeah. Yeah. Yeah. I like Deepness in the Sky also. I think those sequels, right? Or + +[`1:19:50`](https://youtu.be/We7BZVKbCVw?t=4790) Yeah. + +[`1:19:51`](https://youtu.be/We7BZVKbCVw?t=4791) Yeah. Yeah. Yeah. I think so. + +[`1:19:53`](https://youtu.be/We7BZVKbCVw?t=4793) Yeah. It's very long and like complex to get into but so good. Okay. We'll keep going through a lightning round. Uh do you have a favorite recent movie or TV show you really enjoyed? + +[`1:20:01`](https://youtu.be/We7BZVKbCVw?t=4801) So, I actually don't really watch TV or movies. I just don't really have time these days. Um, I did watch I I I'm going to bring up another sishloo, but the three body problem series on Netflix I I really loved. Um, I thought that was like a great rendition of the book series. + +[`1:20:14`](https://youtu.be/We7BZVKbCVw?t=4814) So, the common pattern across uh AI leaders is no time to watch TV or movies, which I completely understand. Uh, is there a favorite product you've recently discovered that you really love? + +[`1:20:24`](https://youtu.be/We7BZVKbCVw?t=4824) I'm going to like chill a little bit and just say co-work cuz this is legitimately the the one product that's been pretty life-changing for me. uh just because I I have it running all the time and uh the the Chrome integration in particular is just really excellent. Uh so it's been like it paid a traffic fine for me. It like canceled a couple subscriptions for me. Uh just like the amount of like tedious work it gets out of the way is awesome. I I also don't know if it's a product, but maybe I'll I'll uh also another podcast that I really love obviously besides uh besides Venny is + +[`1:20:52`](https://youtu.be/We7BZVKbCVw?t=4852) obviously + +[`1:20:55`](https://youtu.be/We7BZVKbCVw?t=4855) Yeah, it's uh it's the acquired uh podcast by Ben Ben and David. + +[`1:20:59`](https://youtu.be/We7BZVKbCVw?t=4859) Uh it's it's just like super it's super awesome. Um, I feel like the way that they get into like business history and bring it alive is is really really good. And I would start with a Nintendo episode if uh if you haven't listened to it. + +[`1:21:11`](https://youtu.be/We7BZVKbCVw?t=4871) Great tip uh with co-work just so people understand if they haven't tried this like basically you type something you want to get done and it can launch Chrome and just do things for you. I saw one of the someone went on pat leave from anthropic and he had it fill out these like medical forms for him. these like really annoying PDFs where it just like loads up the browser, logs in, fills them out, and bits them. + +[`1:21:31`](https://youtu.be/We7BZVKbCVw?t=4891) Yeah, exactly. Exactly. And and it actually just kind of works. Like we tried this experiment like a year ago and it didn't really work cuz the model wasn't ready, but now now it actually just works. And it's amazing. I think a lot of people just don't really understand what this is because they haven't used agent before. And it it just feels very very similar to me to quad code a year ago. Um but like I said, it's just growing much faster than quad code did in the early days. So, I think it's starting to it's starting to break through a bit. + +[`1:21:56`](https://youtu.be/We7BZVKbCVw?t=4916) And there's also this Chrome extension that you mentioned that you could just use stand alone that sits in Chrome and you could just talk to Claude uh looking at your screen at your browser and have it do stuff, have it tell you about what you're looking at, summarize what you're looking at, things like that. + +[`1:22:10`](https://youtu.be/We7BZVKbCVw?t=4930) Exactly. Exactly. For for people that are like just starting to use co-work, the thing I recommend is so you download the Quad Desktop app, you go to the co-work tab. It's right next to the code tab. Um the thing that I recommend doing is like start by having it use a tool. So like clean up your desktop or like summarize your email or something like this or you know like respond to the top three emails like it actually just responds to emails for me now too. The second thing is connect tools. So like if you connect like if you say look at my top emails and then send slack messages or you know like put them in a spreadsheet or something or for example like I use it for all my project management. So we have a single spreadsheet for the whole team. there's like a row per engineer. Every week everyone fills out a status and every Monday co-work just goes through and it messages every engineer on Slack that hasn't filled out their status and so I don't have to do this anymore. And this is just one prompt. It'll do everything. And then the third thing is just run a bunch of quads in parallel. So we can co-work you can have as many tasks running as you want. So it's like start one task, you know, I have this project management thing running, then I'll have it do something else, then something else and I'll kick these off and then I just go get a coffee while it runs. There's a post I'll link to that shares a bunch of ways people use uh what was previously cloud code and now just you could do through code work because a lot of this is just like oh wow I hadn't thought I could use it for that and once you see like these examples I think are what people need to hear of just like oh wow I didn't know I could do that + +[`1:23:26`](https://youtu.be/We7BZVKbCVw?t=5006) so + +[`1:23:28`](https://youtu.be/We7BZVKbCVw?t=5008) yeah I think a lot of this was also + +[`1:23:30`](https://youtu.be/We7BZVKbCVw?t=5010) some of this was also inspired by you any + +[`1:23:32`](https://youtu.be/We7BZVKbCVw?t=5012) you you had this post about uh it was like 50 non-technical use cases for quote or something like this + +[`1:23:37`](https://youtu.be/We7BZVKbCVw?t=5017) so we actually one of our PMs used that as a way to evaluate co-work before we released it. Um, and I think at the point where we hit where Coowork was able to do like 48 out of the 50, they were like, "Okay, it's pretty good." + +[`1:23:48`](https://youtu.be/We7BZVKbCVw?t=5028) Wow. I did not know that. That [laughter] is awesome. Uh, it's I've become an eval. + +[`1:23:55`](https://youtu.be/We7BZVKbCVw?t=5035) Yeah. How does that feel? + +[`1:23:57`](https://youtu.be/We7BZVKbCVw?t=5037) Amazing. I feel like I'm valuable to the future of AI. + +[`1:24:03`](https://youtu.be/We7BZVKbCVw?t=5043) This is like reverse breaking through. [laughter] + +[`1:24:06`](https://youtu.be/We7BZVKbCVw?t=5046) Wow, that is so cool. Wow. Okay. I wonder what those last two are. Anyway, okay, two more questions. Um, do you have a favorite life motto that you often come back to in work or in life? + +[`1:24:16`](https://youtu.be/We7BZVKbCVw?t=5056) Use common sense. I think a lot of the failures that I see in especially in a work environment is people just failing to use common sense. Like they follow a process without thinking about it. Um, they just do a thing without thinking about it or they're working on a product that's like not a good product or not a good idea and they're just following the momentum and not thinking about it. I think the best results that I see are people thinking from first principles and just developing their own common sense. Like if something smells weird, then you know it's probably not a good idea. So I think I think just this this is the single advice that I give, you know, to co-workers more more than anything too. And + +[`1:24:48`](https://youtu.be/We7BZVKbCVw?t=5088) I feel like that alone could be its own podcast conversation. What is common sense? How do you build? But we'll keep this short. Uh final question. Uh so you've been got more active on Twitterx. I'm curious just uh why and just what's your experience been with with Twitter, the world of Twitter? Uh because you get a lot of engagement on on Twitterx. + +[`1:25:08`](https://youtu.be/We7BZVKbCVw?t=5108) So for a long time I used Threads exclusively because I actually helped build threads a little bit back in the day. Um and I also just like the design. It's like a very clean product. I I just really like that. + +[`1:25:18`](https://youtu.be/We7BZVKbCVw?t=5118) I started using Threads cuz actually I was bored. Um so in in December I was in Europe. + +[`1:25:23`](https://youtu.be/We7BZVKbCVw?t=5123) You started using Twitter, you mean? + +[`1:25:24`](https://youtu.be/We7BZVKbCVw?t=5124) Oh yeah. Yeah. Yeah. I started I started using uh Twitter because I was bored. So my my wife and I were uh we were traveling around in in Europe for December. We're just kind of nomading around. We went to like Copenhagen, went to like a few different countries. Um and for me it was just like a coding vacation. So every day I was coding and that's like my favorite kind of vacation just to just like code all day. It's the best. And at some point I just kind of got bored and like I ran out of ideas for you know like a few hours. I was like okay what do I want to do next? And so I opened Twitter. I saw some people like tweeting about quad code and then I just started responding and then I was like okay maybe actually I think I should do is just like look for people look for bugs that people have maybe people have like bugs or kind of feedback they have and so kind of introduce myself ask for if people had a bunch of bugs and feedback and I think they were kind of surprised by like the pace at which we're able to address feedback nowadays. Um, for me it's just like so normal like if someone has a bug like I can probably fix it within a few minutes because I just sort of quad and as long as the description is good it'll just go and do it and then I'll I'll go do something else and answer the next thing. But I think for a lot of people was pretty surprising. So that was really cool and yeah the experience on Twitter has been pretty great. It's it's been awesome just engaging with people and seeing what people want uh hearing hearing about bugs, hearing about features. I saw complaints to Nikita Beer the other day on Twitter of just you they're like posting many threads and it was breaking and just like oh man what's going on here. + +[`1:26:47`](https://youtu.be/We7BZVKbCVw?t=5207) Yeah. Yeah. Yeah. There there was a bug. I hope it's fixed now. Amazing. Oh man, Boris, I could chat with you for hours. Uh I'll let you go. Thank you so much for doing this. Uh you're wonderful. Um where can folks find you online? How can listeners be useful to you? + +[`1:27:03`](https://youtu.be/We7BZVKbCVw?t=5223) Yeah, find me on threads or on Twitter. That's the that's the easiest place. And please just tag me on stuff. Um, send bugs, send feature requests, what's missing, what can we do to make the products better? What do you like? What do you want? Um, I I love love hearing it. + +[`1:27:17`](https://youtu.be/We7BZVKbCVw?t=5237) Amazing. Boris, thank you so much for being here. + +[`1:27:20`](https://youtu.be/We7BZVKbCVw?t=5240) Cool. Thanks, Funny. + +[`1:27:21`](https://youtu.be/We7BZVKbCVw?t=5241) Bye, everyone. + +[`1:27:23`](https://youtu.be/We7BZVKbCVw?t=5243) Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennispodcast.com. + +--- + +## Sources + +- [Head of Claude Code: What Happens After Coding Is Solved — Lenny's Podcast — YouTube](https://youtu.be/We7BZVKbCVw) +- [Lenny's Podcast](https://www.lennyspodcast.com/) diff --git a/videos/claude-boris-pragmatic-engineer-04-mar-26.md b/videos/claude-boris-pragmatic-engineer-04-mar-26.md new file mode 100644 index 0000000..f4582e9 --- /dev/null +++ b/videos/claude-boris-pragmatic-engineer-04-mar-26.md @@ -0,0 +1,332 @@ +# Building Claude Code with Boris Cherny — The Pragmatic Engineer + +Transcript of the interview with Boris Cherny ([@bcherny](https://x.com/bcherny)), creator of Claude Code, on The Pragmatic Engineer podcast, published March 4, 2026. + + + + + + +
← Back to Claude Code Best PracticeClaude
+ +--- + +## Video Details + +- **Guest:** Boris Cherny (Creator of Claude Code) +- **Host:** Gergely Orosz (The Pragmatic Engineer) +- **Published:** March 4, 2026 +- **YouTube:** [Watch on YouTube](https://youtu.be/julbw1JuAz0) + +--- + +## Transcript + +[`0:01`](https://youtu.be/julbw1JuAz0?t=1) You were the first ever TypeScript book with O'Reilly. + +[`0:04`](https://youtu.be/julbw1JuAz0?t=4) Yeah, I found that book translated in Japanese in this little town in Japan. That was just the coolest moment. And then I realized I don't remember TypeScript at all. Now we're at the point where Quad Code writes, I think something like 80% of the code had Enthropic on average. I wrote maybe 10 20 p requests every day. Opus 4.5 and Quad Code wrote 100% of every single one. I didn't edit a single line manually. + +[`0:22`](https://youtu.be/julbw1JuAz0?t=22) Andre Carpet posted that he's never felt as much behind as a programmer as he is now. + +[`0:26`](https://youtu.be/julbw1JuAz0?t=26) This is something I really struggle with. The model is improving so quickly that the ideas that worked with the old model might not work with the new model. One metaphor I have for this moment in time is the printing press in the 1400s because there was a group of scribes that knew how to write. + +[`0:42`](https://youtu.be/julbw1JuAz0?t=42) Some of the kings were illiterate who are employing the scribes. + +[`0:45`](https://youtu.be/julbw1JuAz0?t=45) And if you think about what happened to the scribes, they ceased to become scribes, but now there's a category of writers and authors. These people now exist. And the reason they exist is because the market for literature just What happens when you join one of the top AI labs in the world and your first poll request gets rejected? Not because the code was bad, but because you wrote it by hand. This is exactly what happened to Boris Churnney when he joined Antrophic. Boris is the creator and engineering lead behind Claude code. Before joining Androphic, he spent 7 years at Meta where he led code quality across Instagram, Facebook, WhatsApp, and Messenger, and was one of the most prolific code authors and code reviewers at the company. In today's episode, we cover how Cloud Code went from a side project to one of the fastest growing developer tools and the internal debate at Entrophic whether to release it at all. Boris's daily workflow of shipping 20 30 poll requests a day with zero handwritten code and how code review works when AI writes everything. Why Boris believes we're living through a time as transformative as a printing press and which engineering skills matter more now and which ones do not. If you want to understand how one of the people closest to AI coding agents actually builds software today and what that means for the rest of us engineers, this episode is for you. This episode is presented by Statsig, the unified platform for flags, analytics, experiments, and more. Check out the show notes to learn more about them and our other season sponsors, Sonar and Work OS. How did you get into tech, software engineering, and and coding in general? + +[`2:14`](https://youtu.be/julbw1JuAz0?t=134) It starts a while back. I think there was kind of like two parallel paths that crossed. So, when I was maybe 13 or something like this, I started selling my old Pokemon cards on eBay. And I realized that on on eBay, you can actually like write HTML. And I was looking at other people's Pokemon card listings and I realized like some of them have like big colors and fonts and stuff like this. And then I discovered the blink tag and I named Blink Tag. + +[`2:41`](https://youtu.be/julbw1JuAz0?t=161) And if I put the blink tag on it, I could sell my card, you know, for like 99 cents instead of 49 cents or whatever. So I kind of learned about HTML this way. Then I got an HTML book and kind of learned about HTML. And then uh the second thing was this was also I think sometime in middle school. We had these old TI83 uh graphing calculators and we use them for math. And what I realized is I can get a better answer on the math test if I just program the answers to the math test into my calculator. And so I wrote these little programs to just program the answers and then the test got harder. first then I had to program solvers instead of the actual questions cuz I didn't know what what you know the coefficients and stuff would be ahead of time and then the math got more advanced like the next year and so I had to drop down from basic to assembly to just make the program run a little bit faster. + +[`3:28`](https://youtu.be/julbw1JuAz0?t=208) Oh wow. So like in high school you dropped down to assembly. + +[`3:30`](https://youtu.be/julbw1JuAz0?t=210) I think this is like middle school or high school maybe like 8th or 9th grade or something like this. Then then the thing I realized is uh everyone in my class was starting to realize that I had the solver and they got kind of jealous and so I bought this little serial cable. so I can give it to them too. And then the next math test, everyone on the class just got A's. And the teacher was like, what's going on? And then eventually she realized it. She was like, okay, you get away with it once and and uh knock it off. But for me, it it was very practical. So, you know, in school I studied economics. Um I actually dropped out to to startups and I never thought that coding would be a career at all. It was always very practical to me. Coding is a means to build things and to to make useful things. this startup. Um, the first one was I think it's like my friends and I were trying to get weed and so we started this like weed review startup. We made like a website. We called kind of different uh dispensaries I I think and then we just tried to get kind of like weed samples so we could like review it for them. And it actually kind of blew up. Um, and then I actually got more interested in uh at the time no one was like testing this stuff and so I got into kind of the like chemical testing kind of chemical analysis and then after this I kind of did a bunch of other startups and then I joined YC actually pretty early uh and I was the first hire of uh this YC startup up in up in Palo Alto after. + +[`4:54`](https://youtu.be/julbw1JuAz0?t=294) How did you decide to go go to one startup after the other? + +[`4:57`](https://youtu.be/julbw1JuAz0?t=297) Kind of vibes vibes I'd say cuz you know you know like you know startups it's it's never a linear path. You always kind of pivot pivot pivot. You have to figure out what the market wants and what users want. And it's never the thing that you think. You you always try a thing, but the the idea is always a hypothesis and then almost always you have to pivot once, twice, three times. You know, at at this uh at this medical software company, this is called Agile Diagnosis. This was kind of an early YC company. This was back in maybe 2011, 2012, something like that. It was medical software for doctors. And the idea was there's these like clinical decision protocols. They vary a lot hospital to hospital. And our idea was there was one hospital in Chicago that had a really great protocol specifically for cardiac symptoms. And so we're like, wouldn't outcomes be great if every hospital in the US would use the same protocol? And so we tried to standardize it. And we made this like decision tree software for doctors to use. And I wrote, you know, some of the software. The team was like it it was it was just a few of us. It was a pretty small team. And I wrote the software. It was in a web browser. And I remember this was back in the like the Internet Explorer 6 days. that's what hospitals were using + +[`6:06`](https://youtu.be/julbw1JuAz0?t=366) and I wrote this like SVG renderer uh because it was this visual decision tree and we launched it and then we had a DAU chart and the DUS were flat and couldn't figure it out and we were piloting it with a few hospitals at the time and at the time we were based in PaloAlto we were piloting it with uh you know a few hospitals including UCSF and I rode a motorcycle at the time so I rode my motorcycle up to you know UCSF and I shadowed doctors for a couple days just to see how how do they actually use And I realized that actually doctors don't have time to sit down and use a computer because you're seeing a patient + +[`6:42`](https://youtu.be/julbw1JuAz0?t=402) then you have maybe 5 minutes until the next patient and in those 5 minutes you have to walk down the hall you have to go to the computer station you have to open up this totally legacy computer. By the time it boots up that's like 3 minutes. Then you open up Inner Explorer 6 that takes like 30 seconds. Then you have to open up this like app that we built. You have to sign in and your 5 minutes are up. you don't even have time to use it. And so we rewrote everything to run on Android and they still weren't using it. And the thing we realized is doctors are walking around with a bunch of residents behind them. In this kind of situation, it's like a social situation, right? Like the thing that matters is they're seen as an authority. They don't want to be seen on their phones. And then we pivoted again. So at that point, we were like, okay, so maybe the doctor isn't the target user. Actually, we wanted to be used by maybe nurses or X-ray technicians or something like this. At that point, I left because I was like, "This is actually pretty far off from kind of what I wanted to do." This is like the most fun thing for me is finding this this product market fit because it's always surprising. You can't have one big idea because the idea is probably going to be wrong. So, you kind of form hypothesis, you you follow it down and and you see what's right. Also, I find it so interesting how you're telling us this story because I feel behind a lot of startup success stories, we hear the success story. We hear the path of how it went. But first of all, a lot of startups are like this. And second of all, what struck me is you you were hired as a software engineer, right? And this was back before product engineers or anything was a thing which we're now talking about. But you just like you rode your motorbike and you went there and you shadowed the people and you understood how they're using it, why they're not using it. getting getting ideas. I I feel, you know, this this is what makes a great software engineer back then and and even today, right? You you weren't doesn't seem to me that you were focused on a technology. You were focused on the outcome, though. + +[`8:31`](https://youtu.be/julbw1JuAz0?t=511) Yeah. I mean, look, there there's different kinds of engineers and there's different ways to do it. And you know, I even even on our team right now, I look at an engineer like Jared Sumar and he's just incredible technical mind. He understands systems better than anyone I've met. And you know you need you need people like this. You need people with this kind of depth. For me engineering has always been a practical thing. Uh and you know for me I've always been a generalist and like it doesn't matter if I'm doing you know like design or you know if I'm doing engineering or user research or whatever. The investment thesis for AI and software engineering is straightforward. As AI writes more code more code needs to be verified. But there's a catch. AI generated code is on average harder to verify than human written code. This is why there's Sonar, the makers of Sonar Cube. As a critical verification layer for the AI enabled world, Sonar ensures that speed and volume with AI does not compromise your codebase. Sonar's competitive position is built on 17 years of specialized expertise that no foundational model can replicate. We're talking about deep analysis engines like symbolic execution and cross- repository data flow tracking that simulate how code actually behaves, not just what it says. To bridge the divide between AI productivity and code quality, Sonar has released the Sonar Cube MCP server. This tool acts as a universal translator between AI applications and the Sonar Cube platform. By using the modal context protocol, it gives AI tools like cloud code, GitHub copilot, and cursor direct access to sonar cubes analysis capabilities. Instead of context switching, your AI agent becomes a full-fledged code review and quality assurance copilot capable of analyzing code snips for issues, filtering bugs by severity, and even checking your project's quality gate status before you ever commit code. Whether you're working with coding assistants or scaling up with full agogentic workflows, Sonar provides the automated verification that 75% of the Fortune 100 rely on. It's about giving your developers the freedom to innovate without the fear of breaking the code base. Head to sonarsource.com/pragmatic to learn more about how Sonar enables the confidence to develop at the speed of AI. With this, let's get back to Boris's career and what he learned working at startups. My first job I ever had, I was like, I think I was 16 and I just wanted to buy an electric guitar. And so what I did was I I started uh I just started freelancing. And so I was like, "Okay, I guess I'll make websites." And I think Fiverr was not a thing back then. So there were some other freelancing websites. So I just started like I put up a website. I started bidding on stuff. And my first paycheck, I just spent the entire thing on an electric guitar. But it but it was very practical, right? Right? Cuz it's like when you're in this kind of setup, you have to you have to do the engineering, you have to do kind of the accounting, you have to do the the design, you have to talk to customers. It's just always been like that for me. After a couple of these startups, you ended up at Facebook now now called Meta. And there you spent seven years there. Can you just talk us through what you've worked there, what you've learned there? You've also had a very remarkable career growth in terms of four promotions over over over seven years. And what did you take away from that that experience? + +[`11:39`](https://youtu.be/julbw1JuAz0?t=699) Yeah, so I started on Facebook groups. That was the first time I worked on uh Vlad Klesnikov uh hired me. I think I think he's actually still at Facebook. Um I think he's on some other team now. And it was cool actually. There there's a big group of people that I worked with that were these kind of early JavaScript people too. And you know, like I I did a bunch of JavaScript stuff. And it's funny like I kept crossing paths with these people. And so Vlad, he worked on Bolt.js, JS which was the software it was the framework that powered ads manager which later became ReactJS. I I kept crossing paths with these people and later on for yeah later on there there was a bunch more people like this but anyway so I I was working on Facebook groups um I was really excited about it because the because of this mission of connecting people to their community. This is the thing that drew me in. And at the time I was a big Reddit user. I became a Reddit user back when I was a teenager because I didn't know anyone else that coded. Even in college, I didn't really know anyone that coded. + +[`12:37`](https://youtu.be/julbw1JuAz0?t=757) And honestly, I was always kind of embarrassed about it cuz I thought it was this nerdy thing. And I thought it was kind of this this thing that I knew how to do, but I wanted, you know, I wanted to be like a cool kid and, you know, like I I couldn't like tell people that I coded. It was like it was very nerdy. Um, and and at some point I discovered it was some like programming community on Reddit and I was I was just shocked like there's other people that are into this thing. It's like such a weird hobby. It's so niche and it was just so exciting to find like-minded people like this and get this connection and so I just wanted to work on this. I wanted to kind of contribute to this in in some way. So I worked on Facebook groups for a while. Um, and then you know there there's a bunch of different projects have to to kind of get get into details for any of these. Eventually I became the the tech lead for for Facebook groups and kind of grew grew into this and the org grew the work really changed. It changed from kind of building to a lot of like dock writing and coordination and kind of delegating to others. The culture was changing at the time. So you know this early Facebook culture was disappearing. The docs were coming in. The you know alignment meetings were coming in. uh there was a lot of a lot more work around this kind of foundational stuff like privacy, security, things like this that I think honestly early on a lot of corners were cut in order to grow. But at some point you just have to pay that debt and that was the time when that happened. Then I spent a few years at Instagram after um and that was also a funny story. My wife got a got a job offer and she was just really excited about it and she came to me and was like, "Hey, like I got this offer but we're going to have to move. Is that okay?" And I was like, "Yeah, that's fine." You know, like I work in tech. we can work remotely anywhere. Where's the job? And she was like, it's a N. And I was like, where where's that? And uh N is like rural Japan. And this was uh + +[`14:17`](https://youtu.be/julbw1JuAz0?t=857) different time zone as well. + +[`14:19`](https://youtu.be/julbw1JuAz0?t=859) Different time zone. Yeah. This was + +[`14:20`](https://youtu.be/julbw1JuAz0?t=860) 12 hours or something different or something like that. + +[`14:22`](https://youtu.be/julbw1JuAz0?t=862) Something like that. Yeah. It was like 2021. + +[`14:24`](https://youtu.be/julbw1JuAz0?t=864) Wow. + +[`14:25`](https://youtu.be/julbw1JuAz0?t=865) Um and then I I tried to kind of find a team that would sponsor me cuz there was there were these kind of arcane HR rules about like the time zone you have to be in and the team you have to be collocated with and so on. And so uh there was a little kind of naent team uh for Instagram in Tokyo and Will Bailey was running this team. He was also the guy that made Instagram stories and uh so he was my manager for a while and so we decided to grow that team together and I worked remotely from NA and then most of the team was in Tokyo and uh during this time I I started hacking on Instagram and the stack was just insane like Facebook was the single best web serving stack in the world. the the way that HH everything is optimized like from from the hack language to the HHVM runtime to the to GraphQL as the transport layer to like the client libraries like relay and and all the stuff it was just and in React it was just amazing there there's no other devstack in the world that was this good and it's just fully optimized and then I went to Instagram and it's like you know Python where the type checker didn't work and click to definition didn't work and it was this like kind of hack together Django and then like a work of uh you know the Syon runtime and just nothing really worked and so I came to Instagram I joined the labs team uh you know in in Japan and the idea was to find the next big thing for Instagram. We tried some stuff but what I very quickly realized is that I was just not effective at working on the stack because it was such a terrible stack and so I just went and started working on Dev Infra because uh we we needed to fix it and there there's a few projects that we worked on. So one was migrating from Python to the big Facebook monolith. Another one was migrating from Rest to GraphQL. And uh these projects, they're they're actually in progress, you know, like these are things that involve it takes hundreds of engineers many years to do this. It's a big code base. It's a big migration. Um now it's it's much faster. + +[`16:16`](https://youtu.be/julbw1JuAz0?t=976) Yeah. With with with these tools that we have, the AI AI tools and migrations are a pretty good use case for them though. + +[`16:21`](https://youtu.be/julbw1JuAz0?t=981) Yeah. It's like the it's the perfect use case for it. And then I I just started getting kind of deeper into this. And by the end, by the time I left Instagram, so I was working on this on dev and kind of leading a bunch of these migrations. That's also where I intersected with Fiona Fun who is now the manager for the quad code team. I just worked with her and she was just such an amazing leader, this incredible depth and kind of history in tech. And I just thought like there's no better there's no better manager for this team. And then I I also started working on code quality. And so the the work on Instagram kind of expanded a bit. And um by the time I left, I was leading code quality for all of Meta. And so I was responsible for the quality of the code bases across Instagram, Facebook, Messenger, WhatsApp, Reality Labs, kind of all these code bases. At Meta, it it was this program called Better Engineering. And the idea was I think it's sort of like 2016 or 2018 or something, but Zuck mandated that every engineer at the company 20% of their time has to be spent fixing tech debt. + +[`17:17`](https://youtu.be/julbw1JuAz0?t=1037) Oh, interesting. + +[`17:19`](https://youtu.be/julbw1JuAz0?t=1039) And we called this better engineering. + +[`17:22`](https://youtu.be/julbw1JuAz0?t=1042) Mhm. And the some of this is kind of bottom up where you know a team knows best the tech debt that they have to fix and then some of it is top down where you need to do you know very big migrations you need to migrate to new language features new frameworks things like this and at Facebook scale you know there was tens of thousands of these migrations every year. Um and so I I just started leading all this and I realized very quick that it just needed a little bit more order to it. There was no goals. No one knew kind of like what the outcomes were there. there wasn't any tracking. Um, and so we developed a bunch of stuff. Uh, one of the ideas was a centralized way to prioritize the different kind of code quality efforts. The second thing was figuring out the impact of code quality on engineering productivity which turned out to be significant. + +[`18:04`](https://youtu.be/julbw1JuAz0?t=1084) How how did you measure what did you find there? + +[`18:06`](https://youtu.be/julbw1JuAz0?t=1086) There was a bunch of stuff. I think some of this has been published. I don't know if all of it has, but essentially you try to do like causal analysis and causal inference. This is the methodology. You try to figure out like what what are the factors that make it so engineers are more productive. Some of it is code quality, some of it is outside of code quality. So for example, meta went back to uh you know return to office instead of work from home. That was partially driven by this because we just found some you know fairly strong correlations that we thought were causal. + +[`18:30`](https://youtu.be/julbw1JuAz0?t=1110) Yeah. + +[`18:32`](https://youtu.be/julbw1JuAz0?t=1112) Um about this but quality actually contributes like you know double digit percent to to productivity. It turns out even even at the biggest scale. It's it's kind of comforting to hear because I I think it's it's rare to have a place where you actually measure this, but I think we feel it like when you have a clean code base in modular or it can get easier to work with and I I think you know reasoning could it also be easier for LM to to work with it and my hint would be yes it should be right but I I think there's just very little data but that's a feeling that I I would have. Yeah, I think a lot of the big companies have published about this. Like I think Facebook published something. Uh Microsoft publishes a bunch about this, Google does, but yeah, totally. If if if every time that you build a feature, you have to think about do I use framework X or Y or Z. These are all options that you can consider because the codebase is in a partially migrated state where all of these are around the code somewhere. As an engineer, you're going to have a bad time. As a new hire, you're going to have a bad time. As a model, you might just pick the wrong thing and then, you know, like the user has to course correct you. So actually you know the better thing to do is just always have you know a clean code base always make sure that when you when you start a migration you finish the migration and this is great for engineers and nowadays it's it's great for models too and then you joined entropic and I've heard this story which you can confirm or give more color to it that your first poll request was rejected by Adam Wolf. + +[`19:55`](https://youtu.be/julbw1JuAz0?t=1195) He was my rampa buddy. So I joined Enthropic. I was trying to figure out kind of like what to do next and you know I I met a bunch of people at all the different labs and anthropic was just the obvious choice for me because of the mission. This is the thing that personally I know that I need the most. Um and also just kind of seeing all this change that's happening. It's important to have some sort of framework to think about this and to think about our role in it. I'm also a really big sci-fi reader. Like that that's definitely my genre. Um I'm I'm a big reader. I have like, you know, giant bookshelf at home and stuff and I just know how bad this thing can go and I just felt like this is a place that has serious thinkers. People are taking this very seriously and thinking about what what what can we do to make this thing go better. So when I joined Anthropic, I did a bunch of ramp up projects uh just you know various stuff that that I was hacking on and I wrote my first pull request by hand because I thought that's how you write code. + +[`20:44`](https://youtu.be/julbw1JuAz0?t=1244) That used to be how you write code. + +[`20:46`](https://youtu.be/julbw1JuAz0?t=1246) That used to be how you write code. But even at the time at Enthropic, there was this thing called Clyde and it was the it was the predecessor to quad code. It was it was super janky. It was like it was Python, you know, it took like 40 seconds to start up. It was research code. It was not agentic. But if you prompt it very carefully and hold the tool just right, it can write code for you. And so Adam rejected my PR and he was like, "Actually, you should use this Clyde thing for it instead." And I was like, "Okay, cool." It took me like half a day to figure out how to use this tool because you have to like pass in a bunch of flags and like use it correctly. Um, but then it it sped out a working PR. It just one-shotted it. + +[`21:23`](https://youtu.be/julbw1JuAz0?t=1283) Oh, + +[`21:26`](https://youtu.be/julbw1JuAz0?t=1286) and this was like 2024. This like September 2024, August, something like that. And I think for me, this was my first fuel hi moment at Anthropic cuz I I was just, oh my god, like I didn't know the model could do this. Like I I was used to these like kind of tab completions, line level completions in an IDE. I had no idea that it could just make a working pull request for me. Boris just talked about how he had a true wow moment at work using their AI model. A very different wow moment is when you use a tool at work that makes things so much easier than before. And this leads us nicely to our presenting sponsor, Statsig. Statsig offers engineering teams the tooling for experimentation and feature flagging that used to require years of internal work to build. It's the kind of tool that was so complex to build that only large companies like Meta or Uber had their own custom advanced tooling for it. Here's what satic looked like in practice. You ship a change behind a feature gate and roll it out gradually, say to 1% or 10% of users at first. You watch what happens. Not just did it crash, but what did it do to the metrics you care about? Conversion, retention, error rates, latency. If something looks off, you turn it off quickly. If it's trending the right way, you keep it rolling forward. And the key is that measurement is part of the workflow. You're not switching between three tools and trying to match up segments and dashboards after the fact. Feature flags, experiments, and analytics are all in one place using the same underlying user assignments and data. This is why teams at companies like Notion, Brex, and Atlastian use Statsig. Statsic has a generous free tier to get started, and pro pricricing for teams starts at $150 per month. To learn more and get a 30-day enterprise trial, go to stats.com/pragmatic. And with this, let's get back to Boris and the origin story of Claude Code. + +[`23:10`](https://youtu.be/julbw1JuAz0?t=1390) Yeah. And and then when you when you joined Entrophic, we we've covered this in in a deep dive, but we could recap briefly on how Claude Code came to be out of out of what seemed like a side project or just a cool hack. So yeah, I I I started hacking on a bunch of different stuff. Um I was working on some things in product. Um I worked on reinforcement learning for a little bit just to kind of understand the layer under the layer which I was building. This is still advice that I give to a lot of engineers is always understand the layer under. It's really important because that just gives you the depth and you kind of like you have a little bit more levers to to work at the layer that you actually work at. This was the advice 10 years ago. It's still the advice today. Um but the layer under is a little bit different now. You know, before it was like understand, you know, the Java if you're writing JavaScript, understand the JavaScript VM and frameworks and stuff. + +[`23:56`](https://youtu.be/julbw1JuAz0?t=1436) Now it's like understand the model. So I was hacking on a bunch of different stuff. Uh something shipped, some things uh didn't ship. And at some point I I just wanted to understand the public anthropic API because I'd never used it before. Um and I didn't want to build a UI. I just wanted to, you know, hack something up quite quickly cuz we didn't have quad code back then. We're still writing code by hand. And I wrote this little batch tool that um all all it did was it hit the anthropic API and it it was essentially like a chatbased application um but just in the terminal because that's what AI used to be. And you know, I I still think about it like engineers are the first adopters. And so when we started to move out of conversational AI to agentic AI, it took a little bit, but engineers understood it pretty quick. And I I think now when you ask non-engineers about like what is AI, they would say it's this conversational AI, it's like a chatbot or something. And that's why I'm actually very excited for, you know, co-work this new product that we launched because it's going to bring the same thing that engineer saw very early to everyone else. But when I think about, you know, co-work, I I think back to this moment that we're talking about like very early on, quad code originally wasn't quad code. It was a chatbot because that's what I thought AI was. Um, but we had to kind of figure out kind of what is the next thing. And so I at at the time I I built this chatbot. It was somewhat useful, but it was just a chatbot. And the next thing that I tried was I I wanted it to use tools because tool use just came out and I didn't know what it was and I was like let's experiment and and I I gave it a single tool which was the bash tool and I didn't know what to do with the bash tool and so I asked it you know like I I actually didn't know if it could even do this but I asked it like what music am I listening to and uh it just wrote a little Apple script program using like said or or whatever to uh open up my music player and then like query it to see what music it's listening to and just one shot at this with sonnet 3.5. This is actually my second a field AI moment very quickly after the first one + +[`26:01`](https://youtu.be/julbw1JuAz0?t=1561) and the model just wants to use tools that though that's that's just what I realized like this thing like if you give it a tool it will figure out how to use it to get the thing done and I think at the time when when I think about the way that people were approaching AI and coding everyone essentially had this mental model of you take the model and you put it in a box and you figure out like what is the interface like what how how do want to interact with this model? What do you need it to do? Essentially, it's like if if you have a program, you you stub out some module, stub out some function, and you say, "Okay, this is now AI." But otherwise, the rest of the program is just a program. And so, this is just not the way to think about the model. The way to think about it is the model is its own thing. You give it tools. You give it programs that it can run. You let it run programs. You let it write programs, but you don't make it a component of this larger system in this way. And I think there's just like, you know, this is a version of the bitter lesson. There's the bitter lesson is a very specific framing, but there's many corollaries to it. This is one of the corollaries is just let the model do it do its thing. Don't try to put it in a box. Don't try to force it to behave a particular way. + +[`27:06`](https://youtu.be/julbw1JuAz0?t=1626) One of the first ways you saw it was giving it tools, giving it access to the bash and then later to the file system and then to more tools. Right. + +[`27:14`](https://youtu.be/julbw1JuAz0?t=1634) That's right. Yeah, we we give it uh we give it bash then uh I say we it it was just me the first three months but then the team grew. So it it was bash, it was uh and and file edit that was the second one. + +[`27:24`](https://youtu.be/julbw1JuAz0?t=1644) And one of the interesting thing we talked about uh last time for the deep dive is when you built it and it started to actually write code with with the tool tools that you had. You've had an internal debate inside entrophic should we just keep it to ourselves because it's making suddenly it spread across engineering and it was making all of you a lot more productive right. Yeah, that's right. In the end, the decision was to release so that we can study safety in the wild. Because when you think about safety and you know, I keep talking about the word safety. The reason anthropic exists as a lab is safety. This is the reason it was founded. This is the reason it exists. If you ask anyone at anthropic why they chose it, it's because of safety. And so if you think about model safety, you know, there's different layers at which to think about it. There's kind of alignment and mechanistic interpretability. This is at the model layer. Then there's evals and this is kind of like a it's kind of putting the model in a petri dish and synthetically studying it in this way. Um and then you can study it in the wild and you can see how it actually behaves. You can see how users talk about it. You can you can see like what are the risks in the wild and you actually learn a lot this way. And by doing this we we've been able to make the model much safer. So in in hindsight it was it was totally the right decision. It's amusing to hear about it from your perspective because from the outside what what I saw and what a lot of engineers saw is like oh entropic release cloth code oh wow this you know for the first release with uh I I believe it was with sonet 4 release was was did it come out with sonet 4 originally or sonet 4.5 + +[`28:53`](https://youtu.be/julbw1JuAz0?t=1733) I think it was it was for that that was the general availability in February but I think it was research preview before that + +[`28:59`](https://youtu.be/julbw1JuAz0?t=1739) yeah but when it came out my infiltration was like oh this thing can write code pretty well and over time it became a lot more capable. So from from our perspective it was like this really capable coding tool that we just started to adopt and use and use for all sorts of increasingly product productive parts and it has become I believe one of the fastest growing developer tools and I'm always surprised to hear the story that it actually comes from research and the goal to understand how people use the model because at the other hand like some startups have been trying to build developer tools deliberately to to get adoption and yet this research tool is getting a lot more adoption. + +[`29:38`](https://youtu.be/julbw1JuAz0?t=1778) I mean this is a you know anthropic we're we're a research lab we're a safety lab and you know product is this kind of thing tacked on to the side product exists so that we can serve research better and so we can make the model safer and this is kind of how we think about everything there there was this there's also this funny moment early on when uh we we had this launch review and we were deciding whether to launch it. I remember this moment cuz we were in the room. I think it there was like there was Mike Creger, there was Daario, there were some other folks in the room and we were deciding what should we do. We were looking at the internal adoption chart which was just vertical said it was just insane. It was you know like nowadays + +[`30:13`](https://youtu.be/julbw1JuAz0?t=1813) vertical is 100% right + +[`30:15`](https://youtu.be/julbw1JuAz0?t=1815) just just 100% like nowadays everyone at an every technical employee at anthropic uses quad code every day is pretty much 100%. For nontechnical employees it's also like it's actually getting quite close to 100%. It's it's increasing very quickly like you know like half the sales team uses quad code um and I think that's increasing it's just it's crazy. Dario had this question about like how how did it grow this fast? Are you like forcing people to use it? And I was like no we offer this tool people vote with their feet and you know just like let people use the tool that they prefer. + +[`30:45`](https://youtu.be/julbw1JuAz0?t=1845) Yeah they chose it. + +[`30:47`](https://youtu.be/julbw1JuAz0?t=1847) You don't seem like the person who's act exactly forcing people to use your tool. + +[`30:51`](https://youtu.be/julbw1JuAz0?t=1851) Yeah. Yeah. I mean the the way we did it, we just we launched the thing and then we just like listened to the users and we talked to people, we saw how they use it, we followed up, we made it better and yeah, I mean now now we're at the point where Quad Code writes I think something like 80% of the code in at Enthropic on average and you know it writes all of my code for sure. + +[`31:09`](https://youtu.be/julbw1JuAz0?t=1869) Yeah. And this started for you it started the first time you mentioned I think it was in November when it started to write all of your code. When did that switch come and what what happened to made you trust it to to write your code or how much you trusted? How much you review that code for example? + +[`31:25`](https://youtu.be/julbw1JuAz0?t=1885) So the switch was instant when we started using Opus 4.5. This was before before it came out, you know, we we were dogfooting it for a little bit and it it was just right away. Um it's such a more capable model. I just found that I didn't have to open my ID anymore. I just uninstalled my ID cuz cuz I just didn't need it at that point. I actually did that like a month later because I I I just didn't even realize that I wasn't using it anymore. + +[`31:49`](https://youtu.be/julbw1JuAz0?t=1909) Yeah, a lot of us had similar experiences once Opus 4.5 was out in the public and especially over the winter break. I I had a similar experience. I just realized that this thing it actually writes, if I'm being honest with myself, as good code as I would have written in the stack that I'm very familiar with and my code base, my side projects where I know it and just a lot better than what I could for code base that I'm not as familiar or technologies I'm not as familiar with. Yeah. I'll be honest, he writes better code than I do. + +[`32:17`](https://youtu.be/julbw1JuAz0?t=1937) I I I don't want to go there. I I still like to keep my pride, but probably true. + +[`32:21`](https://youtu.be/julbw1JuAz0?t=1941) Yeah. Yeah. I I realized this because also in December, I was traveling a little bit. I was like on a I was on a coding vacation. We we're talking about this before, but I I went to Europe. We were just in a different time zone kind of nomading around. And it was so fun cuz I was just coding all day every day, which is my favorite thing to do. And uh I wrote maybe, you know, like 10 20 p requests every day, something like that. Opus 4.5 and quad code wrote 100% of every single one. I didn't edit a single line manually and I realized uh at the end of that month Opus introduced maybe two bugs whereas if I had written that by hand that would have been you know like 20 bucks or or something like that. Can we talk about your development workflow? You have written threads about this which is awesome. It's on it's on social media on threads and on on X. But can you tell us how you use today uh cloud code in terms of you know parallelism and and tips and tricks that you and the team have kind of learned and share across the across the team? + +[`33:15`](https://youtu.be/julbw1JuAz0?t=1995) Yeah, I mean look there's no one right way to use quad code. So I I can share some tips and things but I I think the wrong conclusion to draw would be to just copy copy these and and use it. The way we build cloud code is we build it to be hackable because we know every engineer's workflow is different. There's no one way to do things. There's no two engineers that have the same workflow. It's just every every engineer is + +[`33:39`](https://youtu.be/julbw1JuAz0?t=2019) same with workstation setup, right? Like keyboards, monitor placement, all that. Everyone has it differently. + +[`33:42`](https://youtu.be/julbw1JuAz0?t=2022) Yeah. It's like we're like crafts people, right? Like you choose you choose your tools. Like we care deeply about it. So there's no one right way to do it. So for me, the way that I do it generally is I have five terminal tabs. Each one of them has a checkout of their repository. So it's five parallel checkouts. Um and usually I'll kind of roundroin and start cloud code in each one. Almost every time I start in plane mode. So that's like shift tab twice in the terminal. And uh I also overflow uh as I run out of tabs cuz there's only so many terminal tabs. I used to use web a lot for this. So like quad.ai/code, that's the place that I overflow to. Nowadays I actually use the desktop app. Um it's more convenient. So Quad Code, you know, it's been in our desktop app for, you know, for many months. It's just a code tab in in the Cloud app. Um, and I actually really like it because it has built-in uh work tree support. So that's existed for a while. Um, and that that's quite nice for parallelism. So you have multiple, you don't need multiple checkouts. You just have one and then we automatically set up Git work trees for you. So you get this kind of environment isolation. The reason I do that is I actually just really hate fiddling with git work trees on the command line cuz it it's kind of fiddly. like you need to know the CD get work tree for those of who are not as familiar with it. It's it's when you can check out instead of having a separate local folder, it's almost like checks out separate branch, right? And then you can work on it separately but not have the comp have the complex only at like merge time. + +[`35:07`](https://youtu.be/julbw1JuAz0?t=2107) That's right. Imagine that you you have a folder but you have maybe like git makes five copies of that folder in a way that's very cheap um and kind of easy to throw away. So you get this kind of isolation. it can work in parallel and the quads don't interfere. + +[`35:20`](https://youtu.be/julbw1JuAz0?t=2120) Yeah. So, you now have support for this which I I think you recently added like native support but like for for your workflow you just stuck with the old one of checking out on separate f folders, right? + +[`35:30`](https://youtu.be/julbw1JuAz0?t=2130) Yeah, exactly. I I actually find over time I'm using the desktop app more and more for this. + +[`35:34`](https://youtu.be/julbw1JuAz0?t=2134) Um just cuz I don't need these separate checkouts and you know I I just have a bunch of quads running in parallel and I don't have to think about it. The other surprise hit is the iOS app for me. Every day I start like I wake up and I just start a few agents on my phone. Oh, the the native one. Yeah, + +[`35:47`](https://youtu.be/julbw1JuAz0?t=2147) the native one. Yeah, it's just like it's the quad app. It's the code tab in the in the quad app and it's the same exact quad code. + +[`35:53`](https://youtu.be/julbw1JuAz0?t=2153) Yeah, except it it runs in the cloud, right? + +[`35:55`](https://youtu.be/julbw1JuAz0?t=2155) It runs in the cloud. Yeah. So, you have to kind of configure the environment. Luckily, our environment is pretty simple. So, you know, um and it we just use hooks for it. So, you just use the session start hook and configure it. This is kind of one of the benefits of making quad code really hackable is it's very easy to do to do this kind of configuration. And this is something honestly I would never have predicted because you know like I I I code on a computer. If you told me six months ago I'd be writing I don't know a third I haven't pulled the data maybe like a third half something like this of my code on a phone. That's crazy. But that's that's what I'm doing today. + +[`36:29`](https://youtu.be/julbw1JuAz0?t=2189) And you're using parallel agents. At what point did you start using them? And how has it changed your work? Cuz one thing that I notice on myself, I don't really use that many parallel agents. I maybe like two at a time, but I'm someone who well I I like to be in charge and especially with Claude. Claude is is is a a tool that you can follow it along. It tells you what it's doing. It you can also have for example learn mode which this was shipped a lot earlier where where you can actually follow along. It gives you tasks. I I feel that like staying in one tab and following along the model is pretty fast as well. I can kind of keep in touch. I'm assuming at some point you must have done this but then what happened when you changed to parallel and are do you feel you're losing any control or it doesn't really matter that much? + +[`37:14`](https://youtu.be/julbw1JuAz0?t=2234) Yeah, I I I think there's kind of like two modes to think about or kind of like two two uh two kind of workflows to think about. So when you're new to a codebase, highly re learn mode is awesome. Highly recommend it for people that are onboarding to the quad code team, people that onboard to enthropic. Um the thing that we recommend is so you do for people that haven't tried it you do slashconfig in quad code you pick the output style and you can do learn or explanatory. We usually recommend explanatory cuz that tends to be better for new code bases um that you kind of haven't been in before. For me once you're familiar with the codebase you just want to be productive right like you just want to ship as much as you can and you want to kind of be effective doing that. Um so the role really switches. I don't really go deep into tasks anymore. I start a quad in plan mode. I'll have it kick something off. With Opus 4 4.5, I think it got there. With 4.6, it just really really does it. Once there is a good plan, it just it will oneshot the implementation almost every time. + +[`38:10`](https://youtu.be/julbw1JuAz0?t=2290) So, the most important thing is to go back and forth a little bit to get the plan right. So, what I do is I I start one, I enter plan mode, I give it a prompt. As it's chugging along, I'll go to my second tap and I'll start the second quad also in plan mode. Get it chugging along. Then go to the third tab, go to the fourth one. Then maybe I'll go back to the first one when I get notified that it's done. Uh, and then I'll kind of + +[`38:30`](https://youtu.be/julbw1JuAz0?t=2310) Do you have notifications on or do you turn them off? + +[`38:33`](https://youtu.be/julbw1JuAz0?t=2313) I actually operate in both modes. Um, sometimes I do like, you know, focus mode on the Mac. Um, so I just have it off, but also sometimes I use the system notifications. + +[`38:42`](https://youtu.be/julbw1JuAz0?t=2322) And you're very very productive with with PRs. I mean, I I think it was very visible. Even around the holiday breaks uh on social media, you actually were responding to I think someone reported a bug or or a feature request. I'm not sure which one it was. And then an hour or two later it was done cuz cuz you did it. You've also talked about like number of poll requests you've done on a day not to like show up but just as context. What what does a poll request typically involve in terms of complexity? Are these like are some some super trivial or some actually like larger pieces of work as well? + +[`39:15`](https://youtu.be/julbw1JuAz0?t=2355) Yeah, pull request each one varies a lot. Um sometimes it's a few lines, sometimes it's a few hundred or a few thousand lines. They're all just very very different. It's changed so much. Like back when I was at Instagram, I think I was one of the uh top two maybe top three most productive engineers at Instagram just by volume of code written. Oh wow. Um so I've always, you know, for me I've I've always just coded a lot. Like this is uh coding is like a way that I can express myself and it's just like it's a way that my brain thinks also. And so now I just get to do it. But I I think with quad code the the the kind of code that you write if you are very productive it it tends to be even it's just the number of PR sort of underelves what what's happening because I I think people that used to be very productive in the old days before AI assistance a lot of the code maybe was like code migrations or something like this so like people that shipped you know 20 30 PRs every day a lot of it was like pretty you know like a oneliner or kind of migrating A to B or whatever. Nowadays I ship you know 20 30 PRs every day but every PR is just completely different. Some of them are thousands of lines, some of them are hundreds, some of them are dozen, some of them are oneliners. It's none of these are kind of code migrations cuz actually Claude just does those and I I don't need to be part of that. + +[`40:27`](https://youtu.be/julbw1JuAz0?t=2427) Shipping this much code or this much productive. The obvious question that comes up for any I guess software professional is well the review. What the way teams used to work and I'm not sure if Instagram did this but a lot of other companies did this is you make a pull request you put it up there there's a mandatory human reviewer at Google there's actually two cuz there's one on code quality as as well how has this workflow changed how does the hot code team think about code review and how has it changed over time yeah I'll start by thinking I I'll start by talking about how code review used to work for me so the the way that I used to do it is uh every time I I also used to be one of the most prolific code reviewers. + +[`41:04`](https://youtu.be/julbw1JuAz0?t=2464) Oh, okay. So, both. + +[`41:05`](https://youtu.be/julbw1JuAz0?t=2465) I I met Yeah. Yeah. + +[`41:06`](https://youtu.be/julbw1JuAz0?t=2466) Right. Or is it code reviewers? + +[`41:08`](https://youtu.be/julbw1JuAz0?t=2468) That's actually and that's one of the benefits of being in a different time zone. Like I'm not super human. I just didn't have any meetings. And the the way that I approach code review is every time that I would have to comment about something, I would drop it in a spreadsheet and I I would like describe the issue. So, let's say, you know, like someone named a parameter, you know, in a function badly, I would like put that in a spreadsheet. If someone did some bad React pattern or something, I would I would put that in a spreadsheet. And then over time I would just kind of tally up the spreadsheet and anytime that a particular row had more than three or four instances I would write a lint rule for it. + +[`41:39`](https://youtu.be/julbw1JuAz0?t=2499) So just automate it with kind of an op. And so that's what it used to look like for me. I've always tried to automate myself away um because there's just so many things to do. Um and this is one of our superpowers as engineers + +[`41:50`](https://youtu.be/julbw1JuAz0?t=2510) is we were able to automate all of the tedious work. There's very few other fields where you're able to do this thing. This is a thing uniquely that we're able to do. Um, and this is a thing that I I've just always enjoyed because it gives me more free time and uh I get to do the work I actually enjoy. And so today the way this looks is a little different, but it it mirrors this a little bit. So when cloud code writes code, it generally it will run tests locally. And this is something cloud just often decides to do when it's relevant or it'll write new tests. So you kind of do this this kind of verification. When we make changes to cloud code, cloud will also test itself. So it'll launch itself kind of in a subprocess. It'll verify itself and it'll test itself end to end. + +[`42:30`](https://youtu.be/julbw1JuAz0?t=2550) This is for the the your internal cloud code implementation. So you have like this test suite so they can test itself. + +[`42:35`](https://youtu.be/julbw1JuAz0?t=2555) Yeah, that's right. That's right. But it'll literally launch itself just in a bash process and kind of just see like hey do I still work. + +[`42:42`](https://youtu.be/julbw1JuAz0?t=2562) Wow. Okay. So it'll do this and this is something that we we just didn't code in like it just with Opus 4 4.5 especially it just sort of spontaneously doing this. It just wants to kind of check. So so we do this and then we also run claudep. So this is the quad agent SDK in uh CI. So every pull request at Enthropic is code reviewed by quad code. Uh and that actually catches maybe like 80% of bugs something like this. Um and it's the first round of kind of code review. Cloud will automatically address some of these. Some of them some of them it'll leave to a human cuz it's not sure what to do. There's always an engineer that does the second pass of code review. Um and you know there there always has to be a person in the loop approving the change. + +[`43:23`](https://youtu.be/julbw1JuAz0?t=2603) Mhm. So on on on the team before anything goes into production if you will an engineer does look at it. Yes. As you're thinking of code review would you do this for every type of project or this is specifically because you now know that this actually has real world impact people depend on it. You know there's a lot of users let me put it the other way around like can you see places where you would just not have an engineer review uh code. What situations would that be in? + +[`43:47`](https://youtu.be/julbw1JuAz0?t=2627) I think it depends how how how it's used. Yeah I'd agree with that. But you know if you're building some personal side project like you can just yolo straight to main you know like + +[`43:56`](https://youtu.be/julbw1JuAz0?t=2636) it's even even before AI you would have not reviewed you just trust yourself or you know just ship to production or SSH into production and do some changes that kind of stuff right + +[`44:06`](https://youtu.be/julbw1JuAz0?t=2646) exactly exactly um the very first versions of quad code that were internal like you know I committed straight to main but then you know as soon as you have users and you know for enthropic our main customer base is enterprises this is what we care about the most for us for safety reasons security is really important privacy is important. These are these are all related. It's also very important for our customers. And so because this is an enterprise product, it has to be secure. It has to be we have to make sure that it meets a certain bar. So we definitely use a lot of automation, but at least for now, there has to be a human in the loop just to make sure. + +[`44:38`](https://youtu.be/julbw1JuAz0?t=2678) One thing that is just known about LM is they're nondeterministic. And by putting the element as a reviewer claude doing a review like it it will give good feedback but how do you deal with the fact that you can be sure if it's always giving the feedback you cannot be sure that even if it's capable of catching an issue that it will necessarily catch that. Are you doing anything in in this loop to do deterministic thing? For example, linting is very deterministic as you will very well know. Like have you thought of marrying some of these ideas or are you using for example are using llinters on the codebase or you found no need to for it? Yeah, absolutely. Absolutely. Yeah, you + +[`45:14`](https://youtu.be/julbw1JuAz0?t=2714) this is just a Yeah. + +[`45:15`](https://youtu.be/julbw1JuAz0?t=2715) Yeah, we we have type checkers, we have llinters, we run the build. Claude is actually so good at writing lint rolls. So, actually what I do now, I used to tally stuff up in a spreadsheet. Now, what I do is when a coworker puts up a pull request and I'm like, this is lintable. I'll just be at Claude, please write a lint roll for this in that PR on their PR. And we have, you know, you just run like slash I think it's like setup GitHub or or something like this. You can do this in cloud code and it'll install the GitHub app which then makes it so you can tag add Claude on any pull request, any issue. I use this every single day. Um, so very very useful. So you want these deterministic steps. Also though there are there are ways to get cloud to be a little bit more deterministic. So for example, you can do best event. You can have it do multiple passes + +[`46:00`](https://youtu.be/julbw1JuAz0?t=2760) and and this is actually quite easy to do. So you know for example the coderview skill that we use internally it's open source um and it's available in the quad code repo and so all we do is you know we launch parallel agents to do stuff and then we launch parallel dduping agents to check for false positives but essentially best of end the way you implement it is is all you say is claude start three agents to do this and that's it. or just talked about building that enterprise infrastructure layer, the O, the permissions, the security that has to all work before you can ship to real customers. This makes it a great time to speak about our season sponsor work OS. If you're building any SAS, especially an AI product one, then authentication, permissions, security, and enterprise identity can quietly turn into a long-term investment. SL edge cases, directory sync, audit logs, and all the things enterprise customers expect. It's a lot of work to build these mission critical parts and then some more to maintain them. But you don't have to. Work provides these building blocks as infrastructure so your team can stay focused on what actually makes your product unique. That's why companies like Antrophic, OpenAI, and Cursor already run on Work OS. Great engineers know what not to build. If identity is one of those things for you, visit work.com. And with this, let's get back to building cloud code with Boris. How does cloud code work in terms of ar architecture? So as as an engineer, how can I imagine it's setup? It's uh we we covered some of this in the the deep dive and I think you told me that you had some pretty complex ideas when you started and you just simplified a lot of it. + +[`47:33`](https://youtu.be/julbw1JuAz0?t=2853) Yeah. Yeah. It's very simple like you know there there's not much to it. There's like there's a core query loop. Uh there's a few tools that it use that it uses. We we delete these tools all the time. We add new tools all the time. We're just always experimenting with it. So there's kind of this core kind of agent part of it. Then there's the the 2E part of it. Uh and then there's there's actually a ton of different pieces around security. Um and making sure that everything that QuadCode does is safe and that there's a human in the loop for when it happens. + +[`48:06`](https://youtu.be/julbw1JuAz0?t=2886) And by safety, do you mean as as a user when it's doing stuff on my computer or also as entropic monitoring use cases that that could be deemed unsafe? Yeah, there's kind of a couple versions of this. You safety, there's just many, many layers and for things like safety and security, there's no one perfect answer. So, you know, it's always a Swiss cheese model. You just need a bunch of layers and with enough layers, the probability of catching anything goes up. And so, you just have to kind of count the number of nines in that probability and pick the threshold that you want. And so, for something like prompt injection for example, we do this generally at three different layers. So, let's think about something like web fetch. So cloud fetches a URL and uh it reads the contents of of of that web page and then it does something in in quad code. So one of the risks for something like this is prompt injection. Maybe there's an instruction on that website to be like hey quad delete all the folders or something like that. + +[`48:55`](https://youtu.be/julbw1JuAz0?t=2935) So we think about this in a number of ways. The the most basic way is it's an alignment problem. And so opus 4.6 is the most aligned model we've ever released because we've taught the model how to be more resistant to prompt injection. And so you can read about this on the model card and I think it was part of the release. The second part is that we have classifiers at runtime where if there is a request that seems to be prompt injected, we block it um and we just make the model try again. And then the third layer is for something like web fetch, we actually summarize the results in using a sub agent and then we return that summary back to the main agent. So again, this kind of reduces the probability of prompt injection. And so you can kind of see how this isn't just one mechanism. It's it's a layer and by by having a bunch of these different layers, it just reduces the probability a lot. + +[`49:42`](https://youtu.be/julbw1JuAz0?t=2982) One interesting technical choice that you've also mentioned is is using rag or not rag retrie retrieval augmented generation and you mentioned how in the earlier version of cloud code you use a local vector database to to get some to to speed up search and you layer threw this away. Can you talk about how this one because this was another example where I guess did the model get better? + +[`50:04`](https://youtu.be/julbw1JuAz0?t=3004) Yeah, I mean this is one of those things where we try so many different things. We try so many different tools and just statistically most of them we throw away. + +[`50:13`](https://youtu.be/julbw1JuAz0?t=3013) Even something like the spinner in quad code I think it's gone through like a hundred iterations + +[`50:17`](https://youtu.be/julbw1JuAz0?t=3017) I want to say. Oh + +[`50:20`](https://youtu.be/julbw1JuAz0?t=3020) just the spinner and you know out of those we've landed maybe like 10 or 20 in production and like 80 of them I probably just threw away cuz it didn't feel good enough. So just statistically almost all the code we write we throw away because it's just so easy to write this code and try stuff and see what feels good. So for something like rag we tried a bunch of different approaches early on. So the the first one was rag for retrieval cuz I think this I was just like reading up like how people were doing retrieval and it seemed like all the papers were talking about rag. Um and so the way I did it was it was like a local vector database. I think it was like written in Typescript and it just lived on the user machine. Uh and then I was using some like embedding uh model that was in in the cloud to compute the embeddings before storing it. Um and that that worked like pretty good, but there's a lot of issues with rag. Um so for example, I was finding that the code drifted out of sync. Like if I make a local function, it's not yet indexed and so rag isn't going to find it. There's also this question of like how exactly is the index permissioned? So who can access it? I can access it. Um but then how do we like encode that in kind of permission policies? How do we make sure no one else can access it? How do we make sure that like if there's a rogue IT person within the company, they can't access someone else's data? This is really really important that we think about this. + +[`51:32`](https://youtu.be/julbw1JuAz0?t=3092) Yeah. + +[`51:35`](https://youtu.be/julbw1JuAz0?t=3095) Um and so we just decided like it was sort of working, but it was it also has a lot of downsides. And so we tried a bunch of other stuff. Uh one of them was just using the model to uh kind of index everything recursively. Um that was kind of a cool idea. There was another version where um we just tried glob and gp. We tried a bunch of different stuff. It it turned out that agentic search just outperformed everything + +[`51:56`](https://youtu.be/julbw1JuAz0?t=3116) and and when I say agentic search, this is a fancy word for glob and grap. That's all it is. + +[`52:02`](https://youtu.be/julbw1JuAz0?t=3122) Nice. So So the model both got good enough and you realize that it can use these tools pretty efficiently. + +[`52:07`](https://youtu.be/julbw1JuAz0?t=3127) Yeah. And this was uh it was partially inspired honestly by my experience at Instagram because at at Instagram click to definition didn't work because the the dev stack was just borked like half the time and I think now it's better. And so what engineers weren't to do instead is let's say you're looking for the definition of the function fu instead of click to definition what you would do is you would use the global index which is quite good at meta and then you would search for fu per opening parenthesy and this worked pretty well and it it's funny because like this works for the model pretty well too interesting how one one idea from one area can come to the other one of the more advanced parts of cloud code that we've also previously talked about is the permission system. Can you talk about what was complex about it? And also you recently open source sandboxing, right? Permissioning is really complex. Um there's like everything else that has to do with security. It's a Swiss cheese model. There are a number of classifiers that run to make sure the command is safe. Um and there's also static analysis that we do to make sure the command is safe. As a user, you can also allow list particular patterns that you know to be safe. So, for example, um some standard Unix utilities we preow because we know they're readon because we know they can't expilt your data or anything like this. So, we we just won't prompt you for permission. But actually quite few tools fall into this category because even something like the find command, there's actually a way to execute arbitrary code as part of that command because there's there's like system flags that you can use for this. or even something like the said command. There's ways to use this. So there's just like all this like arcania about these various Unix utilities where it's actually not as safe as you think. + +[`53:53`](https://youtu.be/julbw1JuAz0?t=3233) And so we want to be by default fairly conservative about what we allow by default. As a user though you can configure an allow list. So you can say for example like the these patterns are allowed the these patterns are not allowed. Uh and so we we let you define that and we also check this allow list to to make sure that it's safe. + +[`54:09`](https://youtu.be/julbw1JuAz0?t=3249) Yeah. And then you you have this like neat permission system where every time you run a command that needs permission, you can decide to run it once or run it for either this session or whatever it makes sense or just globally allowed going forward. Right. That's right. This is a funny artifact. This was actually in the very very first version of quad code. This is the way permissions worked. This is the very first release. This was like September 2024, the first internal release. I remember at the time we weren't sure whether agentic safety could be even be solved. And so there was actually a lot of push back internally from safety teams because they were like okay like you can't just run let the model run bash commands like that's unsafe. So like what do you do like this is not a solvable problem so like we can't launch this. I I brainstormed with Ben man and Ben was he started the labs team. He's one of the founders at Enthropic. Um he's actually he's the the person that hired me to Anthropic. We just came up with permission prompts as the way to do this. You you put the if you're not sure just ask the human and and they can decide. + +[`55:07`](https://youtu.be/julbw1JuAz0?t=3307) Yeah. I wanted to ask you about how software engineering is done in general in terms of Antrophic and one of the first questions which is a I guess a more formal one but or from the outside is titles or lack of them. Everyone at Antroic has the same title member of technical staff. Why did this happen and what does this result in this kind of like everyone there basically no titles right except for one? I think it's kind of an acknowledgement that um everyone just is figuring stuff out. And um if if you kind of squint and look at the work people are doing, it's all quite similar and it's it's kind of quite generalist and if you talk to the average software engineer, they might not just be doing coding. They might also be doing a little design. They might also be talking to users. They might be writing their own product requirements. They might be writing software and also uh you know doing research. They might be writing product code and also infrastructure code. At anthropic there's a lot of generalists. This is also you know from my background. This is one of the reasons that I gravitated towards it. And I I I think member of technical staff just kind of encodes this in in the way that people talk to each other even if they don't know each other. Without this title the default would have been I see your name on Slack and under your name it says software engineer. And then I'm like well okay I guess you're like you're the coding person then. So I'm I'm not going to ask you like product questions, but when everyone's title is member of technical staff, by default, you assume everyone does everything. And so it kind of inverts this this relationship between people even if you don't know each other well yet. In in a way, it's kind of this like optimism built into the built into the structure. Um I think it's also a glimpse of the future because I I think this is where software engineering is going. I think this is where every discipline is going is more of this generalist model. It definitely feels like it in in software engineing. And I I heard this funny uh comment by Mark Andre uh how we said that there's this Mexican standoff happening in the tech world where the the designers are are saying that they're actually now doing like PM and engineering work. The engineering are saying we're doing design and and like everyone thinks they're doing the work of the others and they're kind of standing there like I'm doing your work as well. when the reality is everyone's role is expanding most of it thanks to AI because it makes easier for an engineer to do product work or for a product person to engineer work and so on. So just what what you've said + +[`57:29`](https://youtu.be/julbw1JuAz0?t=3449) I I remember back in the back in June or July of last year I I walked into the office and the data there's a row of uh data scientists that sit right next to the quad code team at least at least at the time and I walked in and our data scientist for the quad code team had quad code up on on his monitor and um he he was using it and I was like this is interesting cuz you're you're a data scientist did you have like why are you using a terminal like you didn't have NodeJS installed cuz we depended on Node.js JS back then. I I was like, "Are you are you dog fooding it? Like are you just like trying to like figure out how this thing works or something?" He's like, "No, no, I'm like I'm using it to run queries." He was just like using it to run SQL and it had like little like ASKI visualizations uh in the terminal. Uh and then the next week the entire row of data scientists had quad code running on their computers and and this expanded and so if you look at the team today on the quad code team everyone codes the engineers code our engineering manager codes designers code uh data scientists code uh our finance guy codes everyone on the team codes and I think part of it is quad code just makes it so easy so you don't really have to understand the codebase. You can just like dive in and and kind of make small changes quite easily. But I think another thing is people are able to use cloud code to do their jobs more whether it's you know financial forecast or you know data science or whatever and by doing this it's actually quite an easy crossover to just use it to write a little bit of code also. So it's just a way to dip your toe in the water. One other interesting thing about how you work is Cat Woo was talking about she is I guess you the title is the same but people might gravitate for role a bit more. I understand she's a little bit more on a product role but you said that PRDs are just not really written inside entropy and PRD's product requirement document. It's a well-known artifact across big tech and increasingly over larger startups where you write a spec and the idea is that you write down your thoughts, people align, you send it over and now you know what to build. But apparently you're not doing much of this or at all. + +[`59:30`](https://youtu.be/julbw1JuAz0?t=3570) Some of this I think is because Anthropic is still, you know, it's still a startup. So you you don't actually have to align with that many people usually. You can just kind of talk about it or do it in Slack or whatever. Um but yeah, also part of it is, you know, like Cat used to be an engineering manager. She's she's extremely technical and I think this is this is the way that you know our product team thinks about it too is you know better send a PR. + +[`59:51`](https://youtu.be/julbw1JuAz0?t=3591) You're you're doing a lot of prototyping instead. So like that that's also something where when we talked about how you were building cloud code early on you were showing actually you had a whole thread about the number I think you did like 15 or 20 prototypes for the the to-do list and all of them interactive working and what surprised me compared to my past tech experience and you said that well you did this in like a day and a half all all 20 tried it out got a feeling for it which incomprehensible for me it would have taken a week or two weeks and people would have not done 20 they would have done three. Yeah. + +[`1:00:23`](https://youtu.be/julbw1JuAz0?t=3623) So like are are you seeing this? Is there an increase in in prototyping and and building and showing instead of you know writing things? + +[`1:00:30`](https://youtu.be/julbw1JuAz0?t=3630) Yeah. Absolutely. I mean on our team the culture is we don't really write stuff. We just we show. It's a little hard to to reflect back on the time before cuz I I think now just prototyping everything is so baked into the way that we build. Just everything is prototype multiple times. Like uh you know we launched agent teams earlier this week. This is our implementation of swarms. It it's very exciting because uh it just lets Claude do more work for longer, more autonomously. You have a bunch of different uh uncorrelated context windows and you have this kind of communication between agents. They can just do more. This is something that uh Daisy and Suzanne and other folks on the team uh and and Karen, they they prototyped this for months and they tried all in all probably hundreds of versions of this before they got a user experience that felt really good. um it was just really really hard to get right. There's just no way we could have shipped this if if we started with, you know, like static mocks in Figma or if we started with a PRD or something like this. It's a thing that you have to build and you have to feel and you have to see how it feels. And to me, one of the big takeaways even from there was like we probably should prototype more and just be more daring or just release your priors of how long it took to build a prototype or who needed to build. Back then it was always an engineer that needed to build, but it's probably not true anymore. Yeah, that's right. I mean, we're in this world right now also where we just we don't know what the right answer is. You know, like I I think back in the old way of building you the cost of building was high and so you had to actually spend a lot of effort to aim very carefully before you take your shot because after you take your shot um it it's very hard to course correct. You can only take so few shots. But now it's changed. The cost of building is very low. Um but also we don't know where we're aiming. So we just have to like we have to try and we have to see what feels good. And it's just very very exploratory. And I think also a big part of it is humility where you know personally I'm wrong like half the time I'd say like most of my ideas are bad. At least half of them are bad. And I don't know which half until I try it. + +[`1:02:28`](https://youtu.be/julbw1JuAz0?t=3748) And I get feedback from others as well sometimes. + +[`1:02:30`](https://youtu.be/julbw1JuAz0?t=3750) That's right. It's like I I have to try it myself and then I have to see what others think cuz you know my intuition does not always match others. When you were showing these prototypes of just how the the tasks were built, you were telling me that you built the prototypes and then your process was always you first like looked at it, you tried it out, you got a feel for it and then for the ones that you felt were good, you showed it to others and sometimes they give you feedback like nah this doesn't work and then sometimes when it felt good then you shared it even broader. So I feel like you know like it's a mix right where like sometimes you can decide already and then sometimes you get feedback and then eventually some good ideas come out of it. Yeah, and there's a lot of examples of this like uh we we launched this kind of condensed view for file reads and file search just because the the model is just so agentic now like I felt like half the screen is these like file reads and I actually don't care like I you know I read a thing I don't really care what it is and so we condensed this down to make the output a little bit more readable. I really liked it after probably 30 prototypes or something like this. It took it took so much effort to make that feel really good and clean. We rolled it out to employees at Enthropic for about a month and we had everyone dog fooded and I fixed another probably dozen dozen bugs, dozen tweaks based on all this feedback. We launched it externally and you know almost all users liked it but there were a few users that didn't because they want more expanded output. Um and so on the GitHub issue I was just going back and forth with people to be like you know what like what don't you like and people gave a lot of feedback. I shipped another version. Then some people liked it, some people didn't. And so I iterated again and kind of made it good. And it it's actually I think almost there where people can configure it the way that they want, but still the default is really good. But this is just the process. You know, we we get it right some of the time. We have to learn from our users. We want to hear from people so we can get it right. + +[`1:04:12`](https://youtu.be/julbw1JuAz0?t=3852) Do you use ticketing systems for your work where you know where where you capture like, all right, here's the work I I want to or do you just pretty much do the work as as it comes in? + +[`1:04:21`](https://youtu.be/julbw1JuAz0?t=3861) So at Anthropic, we leave it up to teams on the quad code team. and we leave it up to every person. Uh different people use uh use this differently. For example, I don't use a ticketing system. Some people like to use a sauna or notes or something like this. One of the coolest things that I saw, this was maybe like 3 months ago or something. We launched plugins and the way we launched that is uh Daisy for a weekend, she had a very early version of swarms and she let the swarm run and she told that your job is to build plugins. You have to come up with a spec. Then you have to make a asauna board and split up into tasks. And then all the different agents have to build it. And uh she set up a container and she set up a quad in dangerous mode. And she let it run for the entire weekend. It spawned a couple hundred agents. They made 100 tasks on the sauna board. Uh and then they implemented it. And that's pretty much the version of plugins that we shipped. These kind of coordination systems that used to be for humans, but um I think nowadays it's just as much for models. Let's let's talk about cloud co-work. Uh it's one of the very impressing things about this. It looks great. So I tried it out. It's inside cloud. You have the co-work tab there and and you can I I feel it's a lot more visual way of of running agents interacting with them. One of the surprising thing I heard that it was built in 10 days. Can can you take us through like what it took to build it and what does actually mean? Was it from the idea or like from the decision of of building it? And how big was the team building it? + +[`1:05:45`](https://youtu.be/julbw1JuAz0?t=3945) The team was really small. It was just a few people for a long time. We felt that there is some product to be built for non-engineers. The reason we felt this is for a long time people that were using cloud code are non-engineers. Um and so you know in the product world when you see latent demand you see people jumping through hoops to use a product that was not designed for them. That's a really good sign it's time to build another product that is built just for them. There's all these people on Twitter that there's this one guy that was using uh quadco to like monitor his tomato plants. I just I love this. It was like he had like a webcam set up and quad was like, "Oh my god, I'm so happy that our plant is budding." And because it was it had like a webcam and just like every day was like monitoring it and it it was so happy that the tomatoes were growing. There was someone that was using quad code to, you know, recover photos off of a corrupted hard drive and it was like his wedding photos. + +[`1:06:36`](https://youtu.be/julbw1JuAz0?t=3996) Wow. + +[`1:06:38`](https://youtu.be/julbw1JuAz0?t=3998) Um you know, like I said, our entire finance team at Anthropic uses quad code. Our sales team uses quad code. So there there's just all these people that are non-engineers that were using it. And at that point quad code it's available in a lot of form factors right like we started in a terminal then we expanded and we added support for ideides. So we have extensions for you know every VS code based ID every Jet Brains based IDE there's also iOS and Android apps there's the desktop app uh there's web. So uh then then there's like Slack and GitHub apps. So we kind of expanded to all these places to make cloud code easier for engineers. But ultimately none of these are built still for non-engineers. And so cloud code evolved a lot, but it still felt like there's a there's kind of a gap and there's a product that could make this even easier for people. And so for the last couple months, the team was kind of hacking around and just saying like what is the right product? And at some point someone came up with this idea of like what if we just take quad code, add some guardrails. So for example, co-works with a virtual machine. This is one of the many ways that we make sure it's really safe. Um, especially for nontechnical users that don't want to read like bash commands to figure out what it what it's doing. And they were hacking on this. I think it was something like 10 days end to end or something. It was just fully built with quad code. Uh, and then we shipped it. + +[`1:07:55`](https://youtu.be/julbw1JuAz0?t=4075) And can you give us a sense of like the complexity behind an app like this? And if if we can walk through like what parts needed to be built because from the outside it's a little bit hard to tell like is this just a nice UI wrapper that's you know like I don't know like a few hundred lines of code. I'm just being obviously I'm I'm provocative here or behind the scenes it's actually really complex piece of software. And the reason I ask is like Uber is a great example where people look at the app it looks really simple. I've worked there and I know it's it's really really complex because you don't see a lot of the complexity. There's a a lot of regional things. There's a lot of backend things that are all hidden. So from just from looking at it, claude coowork, it's it's hard to tell how much of this is is additional business logic that needed to be carefully thought out versus it's actually just a nice little thin wrapper on top of the the model. In some places, I think there's less complexity than you would think. In some places, there's more complexity. So on the product side, it's quite simple um cuz it's just the quad desktop app. So you know, you download the Quad app. It's it's a single desktop app. It has a tab for co-work, it has a tab for code, it has a tab for chat. So it is just one app and we were able to inherit a lot of that product logic. There's some UI rendering code under the hood. You know it's just the same quad code running. It's the same quad agent SDK that powers quad code. A lot of the complexity actually is about safety because we know like I said we know the user is nontechnical and so we just want to make sure they have a good experience and so for example if someone launches the app and then you know like they delete a bunch of family photos that's really not good and so we wanted to make sure that we protect against this so you can't accidentally do that. And so that's where a lot of the guardrails came from. So there's a bunch of classifiers running on the back end. This is for safety and again extra mitigations for things like prompt injection and you know risks like this around security. On the front end there's an entire virtual machine that we ship. There's a bunch of operating system system level integrations to make sure people don't accidentally delete things. So just around safety there there's a lot there. And then we also had to rethink the permission system because we inherit the permission system from quad code. Um but also for co-work actually a big part of the value is not just running locally but it's using all of your tools the way that quad code uses it. But the thing is for nontechnical users your tools aren't really available as CLIs. Some of them are available over MCP. Many of them are available in a browser. And so co-work is really really good when you pair it with a Chrome extension. And this is the way that I usually use it. So, you know, for example, I use it every week to do uh project management for the team. We have like we have a spreadsheet that tracks kind of at a really high level what everyone's working on. And this is kind of my personal way of project managing. You know, other people, like I said, use ASA, other people use notes or whatever. For my own test, I don't use anything, but kind of for the team overall, I have the spreadsheet and I have co-work kind of check-in and I I just ask co-work every week, hey, can you look at the rows for any status that has not been filled out? Can you just ping the engineer on Slack? And so it'll open one tab in Chrome for the spreadsheet. It'll open another tab with Slack and then it'll just start messaging engineers in Slack and it just oneshots it. There's like one engineer's name for some reason it can't autocomplete. Um but every everything else it just gets. And so this is actually like from a safety point of view, we also thought pretty deeply about this Chrome extension and how this works and how the permissioning model should interact with this local permissioning model. So there's also a bunch of code to kind of make sure that that's that feels smooth. And what's the tech side behind this? I assume a lot of will be similar to the the cloud app, but is it is it electron, typescript, those kind of things or or something else? + +[`1:11:23`](https://youtu.be/julbw1JuAz0?t=4283) Yeah. Yeah, just electron and typescript. Actually, some of the people working on it are early electron folks. So, uh Felix who's uh you know the creator of of co-worker on electron. He helped build it. + +[`1:11:37`](https://youtu.be/julbw1JuAz0?t=4297) Oh, amazing. And co-work launched Mac OS only. uh what was the reason for both for choosing this platform first and for now only choosing this platform? + +[`1:11:47`](https://youtu.be/julbw1JuAz0?t=4307) Yeah, so Windows coming soon. Um I think probably by the time this podcast comes out we will have Windows support. Uh we just wanted to start early and start learning you know like everything we do at Enthropic it's kind of like the way that I told my own story the one of the things I like about anthropic is it just really really matches the way that people here think about it. you know, back to this point where like we don't have high certainty about the things that we build and our intuition is often wrong and so we just have to like learn from users and figure out what people actually want and just spend a lot of time listening to people and understanding the feedback deeply. This is the way that we build product and so we always launch a little bit before it's ready. Um we did this for quad code when we launched quad code initially it didn't even support Windows also it didn't support you know like a lot of different stacks and then over the coming weeks we added support for every stack. Now quad code supports every single stack. Um you know like Windows whatever weird Linux dro use Mac OS we support everything and so for core work also we just wanted to launch early we wanted to start with Mac as that was just the starting point but um yeah it's it's going to support everything. One thing you mentioned is is getting feedback. I'm curious both for cloud code and for cloud co-work. How do you go about things like observability monitoring when you're rolling out? Do you use any feature flags? And I'm I'm more interested in like did you build custom tools for this or did you decide to use certain vendors because es especially for observability I'm sure that this is this is both important but it also sounds like pretty high scale in terms of the the number of users that we can derive or this will not be a small operation. Yeah there's there's some off-the-shelf vendors that we use there's some custom code that we use. So um it's actually it's a mix of both. There's nothing too surprising about it. There's one thing about Enthropic that's kind of interesting is because we're an enterprise company and we care a lot about privacy and security, we can't see people's data. Um, and so, you know, like if someone reports a bug, like I actually can't pull up your logs to kind of see what's going on. A lot of work goes into kind of figuring out how to log events and things like this in a privacy preserving way. Um, this is just very important to the way that we operate + +[`1:13:50`](https://youtu.be/julbw1JuAz0?t=4430) for co-work. What kind of learnings have you had so far? It's it's it's been out for I think a few weeks now. Did you see something unexpected? uh are you shaping the product based on feedback that you're getting? + +[`1:14:03`](https://youtu.be/julbw1JuAz0?t=4443) Yeah. Uh every day the team is landing so many fixes. The most surprising thing is just how much people are loving it. To be honest, when Quad Code first came out, it actually wasn't an overnight hit. This is something people think it was, but it was sort of a slow take off at the beginning. And I think the first big inflection was in May when we released Opus 4 and Sonnet 4. That's when it really clicked and that's when our growth became exponential. But at the beginning, it was sort of a research preview. people didn't really know how to use it. Some people got it immediately, but most people didn't. It took it took a little while. For co-work, it's a much steeper growth trajectory than quad code was at the beginning. So, it it's just been an instant hit. And that that's actually been very surprising. I I didn't really expect that. One of your new releases, which came out just very recently, it was I think yesterday or the day before when we're recording this podcast, was agent teams. And I as I understand the idea with what agent teams agents forms instead of single agent you can have a lead agent and it can delegate to its different teammates. How did you start experimenting with this and how did you decide to ship it? Now we're always doing experiments right there's uh there's there's all sorts of ways uh to get more mileage out of out of quad code. Um one way you can do it is by extending context. Another way is autoco compacting context. So it's essentially infinite context and that's what we have right now. Another way is using sub agents. So you have multiple agents kind of working together. Um there's just like a lot of different approaches to get a little bit more mileage out of the context window. There's this one idea called uncorrelated context windows. That's what we call it. And the the idea is you have multiple context windows. Um but they essentially start fresh. So they don't know about each other. And so an example of this is like a correlated context window is if you have one if you have the model and it does a task and then you have it just do a second task in that same context window. Um and in this case the the second task knows about the first one cuz it's in the same window. But for something like a sub aent it's uncorrelated because the main agent prompts the sub aent but the sub aents context window is fresh. Besides that prompt it doesn't know what's in the parent context window. And you can see this actually a little bit in uh for example like sub agents versus uh skills because when you run a skill uh you know or slash command it sees the parent context window versus for a sub agent it doesn't. So it's uncorrelated. There's some cases where you want that context. There's some cases when you don't. Um and there's this kind of interesting thing where uncorrelated context windows and just throwing more context at the problem and throwing more tokens at it when the windows are uncorrelated gives you better results. Um, it's actually a form of test time compute to do this. And for something like teams, we've been experimenting with this for a while. I think since maybe like October or September or something like this, and it really just felt like with Opus 4.6, it clicked where the model figured out really how to use this. And sometimes you see these kind of cute exchanges where the agents are talking to each other and they're like discussing something and it's just very cool to see. It's very like humanistic in a way. But there's other times where you just get very good results. And so we had a bunch of internal evaluations for example where we have quad build something very very complex, something more complex than what a single quad would build. And we saw the results just really really improved with Opus 4.6 with teams. And that's why we felt it's the right time to release it. We also wanted to be careful. Um, and the reason you have to opt into it, the reason it's a research preview is it uses a ton of tokens cuz it's just a bunch of quads that are running. Um, not everyone wants this all the time. So just excited to see how people use it and uh you know to to hear the feedback. It's it's something you want for fairly complex tasks. You don't probably want this for every task. The main quad decides the rules for the sub quads. We don't have a kind of a regimented way to do this. It's context specific. I wouldn't say there's one right way to do it. I think actually a lot of the magic of this comes out of this idea of uncorrelated context windows. It's less about the specific configuration of the agents. But you know it's something that people should experiment with. I don't think there's a one-sizefits-all. + +[`1:18:03`](https://youtu.be/julbw1JuAz0?t=4683) Have you seen use cases even in even I I know it's it's still research, but have you seen use cases where it could look it looks promising this approach, the swarm approach? + +[`1:18:10`](https://youtu.be/julbw1JuAz0?t=4690) Well, you know, like I said before, plugins were fully built with swarms. There there's a bunch of other feature since that were built in this way. So yeah, I I think for anything where you see a single cloud struggling, swarms can help. It's it's an interesting to look at. Talking about change in in general with Andrew Carpathy, you had a really interesting exchange back in December where when he posted that he's never felt as much behind as as a programmer as he is now because of the progress with AI. And then you shared the story about how you started to debug a memory leak the oldfashioned way and then Claude just one shot at it. I think it was a reflection of like how everyone is feeling that things are changing so fast and in the in the holiday break I started to feel that things have have really shifted. How did you I guess come to terms with this or or start to embrace this change? This is something I really struggle with. The model is improving so quickly that the ideas that worked with the old model might not work with a new model. the things that didn't work with the new model might work or with the old model might work with a new model. And it's weird because there's just not a lot a lot of other technologies like this. So I I just don't really have a lot of experience to draw on to figure out how I should approach this. And it's been this new skill that I've had to learn. In a way, it's like you just always have to bring this beginner mindset. Honestly, like I'm using the word humility a lot, but you always just have to bring this kind of intellectual humility because just all these ideas that were bad before are now good and and and the inverse. I I think that's honestly it it's something I I constantly have to remind myself about. And back in the It's funny back in the old world when someone tries an idea again and we've tried it in the past and it didn't work, usually the feedback is like, why are you doing this again? + +[`1:20:00`](https://youtu.be/julbw1JuAz0?t=4800) Yeah. Yeah. You should learn. This used I mean we used to call a bit of a gatekeeping but it was somewhat valid where I know with architecture someone came and said like why don't we do microser and someone said we tried it and it didn't work and if you tried it a year or two or 3 years ago it was kind of valid right cuz not much has changed. Yeah, that's right. That's right. And something with Microsoft, it's it's funny because it's like every 10 years it goes in and out of in and out of style. But yeah, now now it's I think the first time ever where it's actually not crazy to just try the same idea every few months because the model improves and it just works. And I I actually see this with engineers on the team. Like new people that are newer to the team, people that are newer to engineering sometimes do things in a better way than than I do. Um and I just have to like look at them and I have to learn and I have to adjust my expectations. you know, like an an example of this is, you know, when when we release features, sometimes I'll like screenshot myself using them on, you know, on X or on threads or whatever just to kind of talk about it. Um, but recently, Tar, our um, you know, our devro guy, he actually codes a lot. Um, he's amazing and he just started automating this. So, he's having like quad code generate its own videos for for its launches and he just started doing this and, you know, this is something like I thought would be, you know, maybe it's possible. It's not something I would have tried because I wouldn't have thought the model was ready, but he just he just did it and it just kind of worked. + +[`1:21:18`](https://youtu.be/julbw1JuAz0?t=4878) One thing that I've I felt like just a bit like odd about and I think a lot of developers can relate is I've come to terms with this starting from Opus 4.5 the and and also similar models like I think GPT 5.2 gave me similar vibes as well. the models have been just really good at writing code and I I realize that I don't think I will handr write the code when I'm get I when I want to get stuff done if if I actually want to you know get the pleasure of writing I can still do it but one thing I reflected on is it's just been so much effort to get good at coding I I remember when I when I was learning when I I started from like kind of hacking around to go into university to learning C and C++ and it it was just bloody hard and actually you know going through my my first few jobs where I started to become better at it. I became better at debugging and there's a point where like a lot of my identity was tied to being good at coding. That's how we used to get jobs or higher paying jobs. When I was an engineering manager when we designed the interview loop at Uber, we we had talk with managers of what we need to screen for and we we talk like well what do developers do most of their time? About 50% of the time they code. Therefore, we placed about 50% of the signal was all about coding. So there was a lot of things tied into coding because it it is just hard. I think we all know that it takes grit. It takes some level of intelligence to get good at it. And there's a sense of loss of like well I I think it's great on one end that the model can do it. But it feels that something really quickly got taken away that I don't think I personally thought it would happen this quickly. And I'm I think a lot of other people are feeling like some people move on a bit easier, but there's definitely this sense of of grief. How did you think about it? Because again, you're you're an example of you you wrote so much code at at Facebook also outside of it. I know it was just a tool of doing it, but not many people could do what what you did. And now the models can also work as good as you have or if not better. + +[`1:23:16`](https://youtu.be/julbw1JuAz0?t=4996) That's the challenge. Yeah. I think it's it's something that used to be a thing that we do as software engineers. It's becoming a thing that everyone is able to do. There was a moment, you know, like when I started coding, it was a very practical thing and it was a way to get things done. And at some point I just fell in love with the art of coding and like languages and kind of the the the tools themselves. And at some point I I kind of fell down this rabbit hole. I wrote this like I wrote I wrote a book about, you know, a programming language. + +[`1:23:44`](https://youtu.be/julbw1JuAz0?t=5024) Typescript. You wrote the first ever TypeScript uh book at with O'Reilly. + +[`1:23:50`](https://youtu.be/julbw1JuAz0?t=5030) Yeah. Yeah. Yeah. That's right. Um it it was funny actually. There there was this like there was this amazing moment for me in my little town in Japan. I went to the bookstore and I I found that book translated in Japanese. + +[`1:23:58`](https://youtu.be/julbw1JuAz0?t=5038) No. + +[`1:24:00`](https://youtu.be/julbw1JuAz0?t=5040) In this tiny town and that was just like the coolest moment. And then I actually realized I I don't remember Typescript at all cuz I was only writing Python for a couple years at that point. Yeah. And like at some point I started the the first the the biggest TypeScript meetup in the world. That was in that was in SF. And I got to meet kind of a lot of my heroes. There was like Chris Cowell who wrote like general theory of reactivity. There was Ryan Doll the guy that made Node. one of the first times that I I went really deep into this this community and um just the language itself and the the tools themselves and for something like TypeScript there's this beauty in the type in the type system cuz Hilesburg is just like he he he's just brilliant like the idea of like conditional types and just like anything can be a literal type and there there's these very deep ideas that even the most hardcore functional languages do not have like even in something like Haskell like it doesn't go this far and H Anders just took it and he pushed it much further than than it had had been pushed and you know like Joe Pamer and a bunch of other folks kind of explored a lot of these ideas and thought of this and I think for them it was also very practical right because they had these large untyped JavaScript code bases how do you gradually migrated to something typed and you have to come up with these very beautiful ideas to to do this for me is Scala was another kind of rabbit hole that I fell into in kind of like this functional programming world And still when I write code and when the model writes code I always think in the types first that that's what matters is what what is the type signature that matters more than the code itself and getting that right. So there is this beauty to it. There's a there's an art to it for sure. But in the end it's a practical thing and in the end this is a thing that we use to to build things and you know it's a means it's a means to an end. It's not an it's not an end to itself. I I think one metaphor I have for kind of the this moment in time that we're in is the the printing press in, you know, like the the 1400s or whatever + +[`1:25:57`](https://youtu.be/julbw1JuAz0?t=5157) because at that moment it it was actually quite similar, right? Like there was a group of scribes that you know knew how to write + +[`1:26:03`](https://youtu.be/julbw1JuAz0?t=5163) and it it it was as I understand of course we never lived there but as as I imagine it was it was a art process to learn. You needed to learn you needed to get the equipment. You probably needed some sponsorship or being selected practicing because you needed to produce the same thing over and over again and few people could do that and I assume it was either high prestige or highly paid or who knows let's assume it was + +[`1:26:24`](https://youtu.be/julbw1JuAz0?t=5184) but then the printed press came along. + +[`1:26:27`](https://youtu.be/julbw1JuAz0?t=5187) Yeah. Yeah. And at least in Europe like you had to like a lord or a king or something had to had to employ you and then you had to go through you know years of training and there was this class of scribes that knew how to write. They were employed by someone like this. often the king themselves like or you know the queen was was not literate. So it was this very very niche skill and it was like less than 1% of the population was literate in Europe you know back then and then the printing press came out and what happened so the cost of printed material went down something like 100x over the next I think 30 years 50 years or something the quantity of printed materials went up like 10,000x in the next 50 100 years this was the first effect literacy it took a little while for it to catch up so I think global literacy it went up to something like 70%. But that took like another 200 years, 300 years because learning learning to read is just very hard. Learning to write is hard. It takes a lot of effort. It takes uh education system. It takes you know infrastructure to have paper and ink uh and the free time to do this instead of working on a farm. So it kind of it took early stage of of of industrialization to actually get there. But I but I think this effect of making it so this thing that was locked away in ivory tower and now it's accessible to everyone. This is just, you know, like none of the things around us would exist today without this. Like if if we weren't literate, if the people that built, you know, this microphone weren't weren't literate, it would have just been very hard to have a modern economy. None of these things would exist. And I I just kind of think about back then if people had to predict what would happen when the printing press came out, no one would have predicted that the microphone would become a thing. So, I I just feel like this is uh this is the best the best uh analog for for the moment that we're in right now. + +[`1:28:13`](https://youtu.be/julbw1JuAz0?t=5293) Yeah, it's interesting that you say that some of the kings were illiterate who are employing the scribes because if we're being honest with ourselves, we have business owners who know what they want to build and there are employing software engineers because they themselves cannot write code. And I think we we like to mock the CEOs who are coming there coming to the team. They they might even have a drawn prototype or whiteboard and saying this should be easy but of course they don't understand how difficult it is. There seems to be a bit of analogy where where there's a person who wants what they want but until now they needed to hire a software a specialist who can build that and there's always that disconnect between the idea and the person and just like with the printing press like what would happen if they could actually express and like the king could actually read or write their own letters they wouldn't need that middleman and it things become more efficient. But I mean of course for the scribe it's not the best news necessarily but I mean smart scribes can also do so someone needs to like write the books run the press etc. Yeah, exactly. And and if you think about what happened to the scribes, right? Like they cease to become scribes, but now there's a category of writers and and authors like the these people now exist. And uh the reason they exist is because the market for literature just expanded a ton. + +[`1:29:30`](https://youtu.be/julbw1JuAz0?t=5370) And I guess also if we think about like back then a scrib's work was read by a few people and with the printing press and author there's a lot more authors and some of them are not really read but some of them have wider reach than than they could imagine. There's new careers that that exist because of that. + +[`1:29:44`](https://youtu.be/julbw1JuAz0?t=5384) Yeah, + +[`1:29:45`](https://youtu.be/julbw1JuAz0?t=5385) I love the analogy. + +[`1:29:47`](https://youtu.be/julbw1JuAz0?t=5387) And the most exciting thing for me is it's just so impossible to say today what will happen after this happens and after this transition happens just you know the the economy as we know it would not have existed without it. So what's next? like what what is the thing that we can't even predict today that will exist because anyone can do this? + +[`1:30:13`](https://youtu.be/julbw1JuAz0?t=5413) Well, we cannot predict but I think we can look at what is working right now. If you look around in your environment, may that be the team across entropic who are software engineers or or builders or members of technical staff, however we call them, who to you are stand out. What are they doing? What skills have they built up? And and how have they changed the way they they work? It's hard to name individuals because honestly this is just the strongest the these are the strongest people I've ever worked with in my career. There's all sorts of different archetypes. There's some people that are really amazing prototypers. Um so take something from zero to.5. Just you know figure out like what are some cool ideas? What is the technology on walk? There's other people that are amazing at finding product market fit. So kind of 0.5 to one or maybe 0ero to one. There's other people that span different disciplines and I I'm just seeing more and more of these people like I said like people that span uh product engineering and infrastructure engineering or you know product and design or design and engineering. I I think I'm just seeing a lot more of these of these hybrids. + +[`1:31:15`](https://youtu.be/julbw1JuAz0?t=5475) What's a belief that changed from last year to this year? Something that you know like you either believed or or a conviction that you had that you've either revised or completely threw away. I think one thing I wasn't sure about is how big a problem is safety to be totally honest. Um I jo I joined Anthropic because like I said I read a lot of sci-fi and I kind of I know how bad this thing can go if it goes bad. It wasn't something I was sure about. Um but seeing it from the inside and then seeing how the new risks that have arisen in the last year, it just makes me much much more worried about it. Um so I I think it's it was kind of an important thing for me. Now it's just the most important thing for me is how do we make sure this thing goes well. + +[`1:31:59`](https://youtu.be/julbw1JuAz0?t=5519) I think it's safe to say you you were a really great software engineer even before all all the AI things started and you seem to be a very productive engineer of course part of a team as well but but also individually. What are some skills of like you know before being a software engineer that are are still as valuable or maybe even more valuable than before and what are ones that are maybe just not as much and and they're best left behind probably. Okay, so the stuff that's left behind is uh best left behind is maybe like very strong opinions about like code style and languages and things like this. Like I I can't wait to get past like these endless language debates and framework debates and all the stuff because the model can just like you know use whatever language and framework and if you don't like it it can just rewrite it for you. So it just doesn't matter anymore. I think something that still matters a lot today is things it's being methodical and hypothesis driven. This matters both in product design in this world where everything is being disrupted and we need to figure out what to build next and this is something everyone is thinking about. Um, but it also matters for engineering day-to-day, you know, like something like debugging. You just have to be very methodical about it. And the model can can do this and it can help a lot. Um, but I think still we're in this transition point where you still need to have the skill. I don't know if you you're you're still going to need to have it in 6 months. Other skills that I think are more valuable are being curious and being open to doing things beyond your swim lane. So, you know, if you're working on engineering, but you really understand the business side, you can just build really awesome products. And I and I think the next, you know, billion dollar product, you know, like after quad code, whatever the next startup is that, you know, becomes the next trillion dollar startup, it might just be like one person that has some cool idea and their brain just is able to think across, you know, engineering and product and business or, you know, like design and finance and something else. It's like it's people are going to become more and more multi-disipline and this will become more and more rewarded. So in in some ways I think this will be the year of the generalist. I think the other skill that's actually been been rewarded of it is uh having a short attention span. + +[`1:34:11`](https://youtu.be/julbw1JuAz0?t=5651) I was being rewarded now. Oh yeah. It's uh you know like people you know like teenagers are using you know like like Tik Tok and and all this stuff and I think in some ways it's kind of dangerous for society um because like you want people that can think deeply and can contemplate ideas and uh aren't just moving on to the next idea very quick but in some ways I think this year is kind of the year that is going to reward uh it's like the year of ADHD because the work for me has become jumping between quads. has become managing clouds and so it's not so much about deep work it's about how good am I about context switching and you know jumping across multiple different contexts very quickly + +[`1:34:52`](https://youtu.be/julbw1JuAz0?t=5692) could I add that from what I unders what all you said maybe we could add one thing which is adaptability because you're saying of course that ADHD and and you can jump across but of course earlier you are very good at focusing deeply on one thing as well and what strikes me about you and maybe this is true for other people as well you you're just kind of very open to adapt ting your working style and seeing what works well for this stage, especially when things are changing. I think the one certain thing we can be sure is whenever the next model comes out, it'll change again. And you need to be curious and open to adapting how you work, right? + +[`1:35:25`](https://youtu.be/julbw1JuAz0?t=5725) Yeah. And as closing, what's a book or books that that you would recommend? I've gone down a rabbit hole. Um, so he's the threebody problem guy, but he actually has like a lot of other really great books. I really love his uh short stories. Um, he has a couple books of short stories. I'm a big fan. For people that are new to sci-fi and you want like a little bit like harder sci-fi, um I really love Accelerondo by St. This is a book I would totally recommend. It's like essentially the product roadmap for the next 50 years. Um it it it starts with takeoff kind of starting to happen and kind of AI singularity and then it ends up with like uh this kind of like group lobster consciousnesses orbiting Jupiter and it's just like amazing. And the thing that I think it really captures is just the pace this like quickening quickening quickening pace of how this feels. It really matches the feeling right now. And then on the technical side, I would strongly recommend functional programming in Scola. Even if language choice just doesn't matter as much anymore, I think there is this art to functional programming that just teaches you how to code better. Um, and it'll just teach you how to think in types. If you read this book, I think what's really important is to do the exercises also. And I've gone through and I've done all of them probably like three times over and it's just amazing. It it really just like knocks this idea of functional types into your head and it's just a thing you can't stop thinking about. + +[`1:36:45`](https://youtu.be/julbw1JuAz0?t=5805) Boris, thank you so much. This was awesome. + +[`1:36:48`](https://youtu.be/julbw1JuAz0?t=5808) Yeah, thanks Kirk. This was a really interesting conversation and the thing that I keep coming back to is to Boris's prickic press analogy. The idea that medieval scribes were this tiny elite who could write employed by kings who themselves were often illiterate and that we soft rangers might be in a similar position today. We are the scribes. We spent years mastering this craft. And now the printer press is arriving. But what Boris told me is that the scribes did not disappear. They became writers and authors and the entire market for written work expanded beyond anything anyone could have predicted. I do find this hopeful and also appreciate that Boris didn't sugarcoat it. The other thing that struck with me is just how differently the Cloud Code team built software. No PRDS, no mandatory ticketing system, designers and data scientists and finance people all writing code and building dozens or hundreds of prototypes before shipping a feature. And Boris is shipping 20 to 30 pore requests a day without editing a single line by hand. And there are different verification systems in place. Claw code reviewing its code, automated lint rules, best of end passes, and human code review. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show. Thanks and + +--- + +## Sources + +- [Building Claude Code with Boris Cherny — The Pragmatic Engineer — YouTube](https://youtu.be/julbw1JuAz0) +- [The Pragmatic Engineer](https://newsletter.pragmaticengineer.com/) diff --git a/videos/claude-boris-ryan-peterman-15-dec-25.md b/videos/claude-boris-ryan-peterman-15-dec-25.md new file mode 100644 index 0000000..c7b7687 --- /dev/null +++ b/videos/claude-boris-ryan-peterman-15-dec-25.md @@ -0,0 +1,178 @@ +# Boris Cherny (Creator of Claude Code) On What Grew His Career — Ryan Peterman + +Transcript of the interview with Boris Cherny ([@bcherny](https://x.com/bcherny)), creator of Claude Code, on Ryan Peterman's channel, published December 15, 2025. + + + + + + +
← Back to Claude Code Best PracticeClaude
+ +--- + +## Video Details + +- **Guest:** Boris Cherny (Creator of Claude Code) +- **Host:** Ryan Peterman +- **Published:** December 15, 2025 +- **YouTube:** [Watch on YouTube](https://youtu.be/AmdLVWMdjOk) + +--- + +## Transcript + +[`0:02`](https://youtu.be/AmdLVWMdjOk?t=2) The models are moving so quickly. If you ask me this question in 3 months or 6 months, my answer will be totally different. This is Boris Chney. He's the creator of Claude Code and former meta principal engineer. And we talked about everything that shaped his career. Can you explain latent demand? + +[`0:17`](https://youtu.be/AmdLVWMdjOk?t=17) Latent demand I think is the [music] single most important principle in product. + +[`0:22`](https://youtu.be/AmdLVWMdjOk?t=22) You said that there were some clear cultural differences and that was difficult. + +[`0:26`](https://youtu.be/AmdLVWMdjOk?t=26) Oh my god, difficult is such an understatement. It was a nightmare. We also talked about quad code and what's actually [music] happening in enthropic right now. Even though enthropic has tripled, productivity per engineer has grown like almost 70% [music] because of quad code. Don't build for the model of today. Build for the model 6 months from now. The one technical book I would recommend to everyone that has [music] had the greatest impact on me as an engineer is what are your thoughts on the competition with codeex and openai? I want to start at the beginning of your story with you getting promoted to senior engineer at Meta. What's the story behind the projects that got you promoted and where were you at the time? If I remember right, the project was chats and groups and this was a project to bring uh Messenger and Facebook a little bit closer together. And I actually the first few projects that I worked on at Meta, it was about Messenger and Facebook. And I think the first one was like Zach had this idea about like syncing Messenger chats and Facebook groups. Um, but there's a few of these projects just trying to bring like uh Messenger and Facebook closer together. And I think the motivation was there was this feeling that this kind of public space social product was disappearing and that things were moving a little bit more into chat and these kind of more casual realtime spaces. And so we tried a few versions of the product and chats and groups is the one that worked. I think it was like number three or number four at the time and I I was in the Facebook groups or in um Facebook at the time and I was working a lot with messenger that was like organizationally very distant. And this is a idea that I think Steve who was a PM at the time he sort of had this idea this is a thing we should build and I just picked up on that and I was like yeah hell yeah let's let's do this. Uh and so I started hacking on it. Uh and then pretty soon there were some signs of life. So I asked for more engineers and uh there were three engineers that joined. There was uh Shatambri, uh Crystal and Chaang. They were like the first three engineers that joined this and then we got some uh we got some data science support, some design support. Um and it started just on web. Then we also moved to mobile a little bit and uh yeah, I think we just kind of proved out this idea that you can have chats inside of Facebook groups and this kind of product can work. And there's just like a lot of stuff honestly that didn't work at all about it. Um it was like a super jank experience I think by modern product standards. Like back in the day everyone was building on web and all sorts of bugs were totally okay. Nowadays, I think the standard honestly like the visual standard like quality standard is a lot higher and yeah so like the the product grew and we were such a small team like everyone had to do everything and I remember like we didn't have a user researcher so I would go to the cafeteria during lunch and we would have a new feature and we would show the cafeteria workers the feature and be like hey can you figure out how to open a chat and you know like sometimes they would find it sometimes they wouldn't be able to and this is just like an observational user research study So you kind of see how people like in a particular situation can do a task and you don't prompt them that much. So you you don't want to give too much away and you kind of see where they struggle. You see what they get. Um and so we we did this and then like I I kind of taught the team how to do this. So then pretty soon we would all go to the cafeteria at lunch and start like bugging cafeteria workers to you know as just kind of like representative users to be like you know does this make sense or not? It's interesting how the early Facebook culture that you were operating in let engineers do so much outside of just like the code. For instance, you're doing UXR. It sounds like in some of it I remember in your story you did some design as well and you were coaching people to do design. So I think that's pretty interesting unique thing in Facebook's culture. I think this is so important and I think to this day, you know, on the quad code team and this is the team that I'm on right now. We really prioritize generalists. So I love working with generalists. If you're an engineer that codes, but you can also do product work. You can also do design. You have product sense. You go, you want to go talk to your users. Like I love this kind of engineer to work with. And this is actually how we recruit for all functions now. So like our product managers code, our data scientists code, um our you know user researcher codes a little bit. So like I just love these generalists and I think this is really like the way that I grew up like from the beginning when I was running you know my first startup when I was like 18 I had to do everything and uh up until Facebook I worked at smaller companies where you had to do everything and I kind of feel like at big companies you get forced into this you know particular swim lane but it's just sort of official cuz like what is engineering? It's like it's a very narrow skill set, but really the thing that you're doing is you're building product or you're building infra and there's just so much more that goes into doing that end to end besides just writing code. It it was just really cool being at a place that um I think Facebook uniquely kind of rewarded that at that time. And I I think actually at the end of that half I got promoted and then I think the half after every single one of the engineers got promoted too. In those early products, there was this concept um latent demand that you mentioned a few times, which uh it sounds like was the impetus for a lot of those product directions. Can you explain latent demand? + +[`5:42`](https://youtu.be/AmdLVWMdjOk?t=342) Latent demand I think is the single most important principle in product and I think if you look at especially at Facebook successful products, every single one has an element of latent demand. So for example, a marketplace, it came from this observation that if you looked at Facebook groups at the time, 40% of the posts were buying and selling stuff. And so Facebook groups were not designed for commerce, but that's what people were using it for. And so it's kind of cool like you design this product in a way that can be hacked. It can be abused by users a little bit, and then you look at the data, you see how they're abusing it, and then you build a product around it. And so you know like there was Facebook groups and then there were buy sell groups and then that succeeded obviously because people already wanted to buy and sell and do commerce on Facebook groups and then marketplace was next. It was just a natural extension of the same intent that people had. Um I think Facebook dating was pretty similar. I think the observation was something like 60% of profile views were people of the opposite gender that were not friends with each other. Um, so you know this kind of like traditional like kind of like creeping on each other like and and I think for like um like Nate and like FMS at the time like this this was evidence that this would work. And I I think the the principle in product is you can never get people to do something they do not yet do. The thing you can do is you can find the intent that they have and then you can steer it to let them better kind of capitalize on that intent um and kind of do the thing the thing that they want more easily. I think also at this part of your story, you mentioned that you worked across orgs. You worked because you were bridging the gaps between messenger and a lot of the group's um engineering work. I'm curious, you said that there were some clear cultural differences and that was difficult. Uh do you have any advice for working across uh very different culture orgs? + +[`7:30`](https://youtu.be/AmdLVWMdjOk?t=450) Oh my god, difficult is such an understatement. It was a nightmare. Like for Facebook at the time, we wanted to ship like we just wanted to go fast and ship awesome product as fast as we could. And then Messenger was all about reliability and performance. That's all they cared about. It was just polar opposite values. Um and this isn't just cultural. It's not just like an engineer to engineer thing. It's like the engineers on that team were suspicious of us because we would affect their performance metrics. And organizationally, their or was set up in a way to ship slowly without regressing the metrics and we were set up to ship quickly. So it's like and then the goals were totally different you know like they had SOA up times and for us it was just about daily active users and engagement. So I think for me the running was these kind of cultural values go super deep. It's not just a thing people talk about but you can actually see this in like in org design and in in goal design and in every part of everything. And honestly, I think one of the reasons that project uh failed was uh and eventually it evolved actually into something successful, but that version of the project failed was because of this difference in values. So I think that fundamentally if you want to get companies with really different values to succeed and kind of work together, you have to find some kind of shared goal or kind of shared interest, shared belief, some kind of hypothesis that they want to test together that would be really interesting for both of them if it worked. Um, and I think this like chats and groups thing fundamentally was really cool for Facebook, but it's not that cool for Messenger for a lot of reasons. So, knowing what you know now, how would you change things going back to that kind of project? + +[`9:10`](https://youtu.be/AmdLVWMdjOk?t=550) I think I probably would have gone to Zuck and just been like, if you're really serious about this thing, we we should move Messenger into the Facebook or and I think this has since happened and it's actually happened like a few times like Messenger was in the or then it moved out and then it moved in then moved out. It's a big company like this happens. But I think fundamentally for this kind of thing to succeed, the the common report can't be, you know, the common manager can't be like Chris Cox. It has to be like a little bit lower down. And so you can structure the orgs to be a little bit more collaborative. + +[`9:39`](https://youtu.be/AmdLVWMdjOk?t=579) I see. To align the incentives so you don't get that kind of constant struggle. + +[`9:44`](https://youtu.be/AmdLVWMdjOk?t=584) Yeah. Exactly. at this point in your career, I saw there were a bunch of really interesting side projects that you had and I'm kind of curious like what what's the butterfly effect of those kinds of projects? So, for instance, um even before you got to meta, you worked on Undux, the state management framework for React. Um I'm curious like how did that impact your career if at all? + +[`10:07`](https://youtu.be/AmdLVWMdjOk?t=607) Yeah, I mean for me side quests are so important and for me like when I hire engineers this is definitely something I look for. I want people with side quests, like cool weekend projects, cool side projects, like even someone that's like, you know, just really into like making kombucha or something. Like you want people that are generally curious and interested in stuff outside of their main work. These are kind of well-rounded people. These are the kinds of people I enjoy working with. I think for me, this is where a lot of my growth came from is um working on these kind of side projects. So something like Unex honestly where it came from is uh React state management is honestly unnecessarily complicated and at the time the state-of-the-art was there there was like flux and then there was this other thing called Redux and I just couldn't wrap my head around Redux. I was just you know I I consider myself kind of average engineer like I build product. I'm like I'm not one of these like incredible systems engineers. And so for me like Redux at the time I had these concepts of like you know like reducers and this kind of like just like this like very complicated flow you had to go to to just like update a little state and I just couldn't wrap my head around it. So I I built a simpler thing that seemed to work. I used that um I was volunteering at a nonprofit at the time and uh they started using it and their engineers liked it. And then when I joined Facebook, I saw a lot of kind of frustration around Redux usage because there was a internal group for people that use Redux and there were all these questions where people were asking the same questions I did. Um, you know, like when you as an engineer or, you know, as a product person are running into a problem, sometimes it's just you. Often it's other people too. And I think it's important to build the spidey sense for like when this problem might be shared by others. And so this is a problem that definitely was shared by others. And I could kind of see this in support posts and by the difficulty my team had using Redux. And so I launched uh Unux internally and Unex is like it's fine. It's like not that great of a product, but at least it's better than Redux. And um at Facebook I didn't actually know how to get adoption. So I kind of posted about it. A few people started to use it. Um I remember there was like Jeff Case on the notifications team was a big early adopter and we spent some late nights debugging some like gnarly like notification related bugs due to it. And um I wanted to get more adoption. And so what I did was I wrote a little script and I scraped the group of uh people reporting issues and I just tallied them by team. And then I reached out just over chat to the tech lead and the manager for every team and I scheduled uh like a tech talk just for that team. And I think overall I did maybe 20 30 40 tech talks something like that over the course of like a few weeks. Yeah. + +[`12:45`](https://youtu.be/AmdLVWMdjOk?t=765) And I I remember just like biking around the meta campus and kind of doing these talks and it was so fun cuz people were so engaged and they were just so excited that someone cares about solving this problem that they they really have and I think at some point on was like the most popular state management framework at Facebook and then I think it got pretty quickly replaced by recoil and kind of more modern alternatives and nowadays it's like relay and and things like that. Does that kind of side project appear in your like performance review or is it like help you in some way? So I think it was in my performance review. I think by meta standards it's kind of a cherry on top. It wasn't really you know something that kind of gets you to the next level in itself. Um but I had a lot of other side quests around uh around that time too. Like at some point I got really into TypeScript actually and this was like at the previous company I was at. We were using it. There weren't a lot of good resources. And so I just like started writing a book about it cuz I was like someone like someone should do this. It's crazy it doesn't exist. This language is just like magnificent. It's it's just this like really really shockingly shockingly good design. It has all these ideas that no other language had at the time. Um you know things like eventually like at the time there were no conditional types but like conditional types like literal types for everything. Uh map types these are just like absolutely insane things. like even the like the gnarliest Haskeller is going to be impressed by this kind of language feature, but no one was writing about this stuff and so I just got like super into it and like wrote this book and it it just sort of like ate up like a year of my life. [laughter] Would not recommend it. Um but it was really fun to go really deep on it and then I also started I think like the world's biggest TypeScript meetup at the time in in San Francisco and that was a really cool chance to meet uh there was like Ryan Doll who created Node.js. there was um just like all all these like famous JavaScript celebrities and it just sort of made me realize like all these people are just people and um you know like everyone just like builds cool stuff and some of it's cool some of it's cool at a particular time but it's all just people and anyone can do this stuff. + +[`14:47`](https://youtu.be/AmdLVWMdjOk?t=887) Did you end up using TypeScript or that technical depth later in your time at Meta or or maybe even in anthropic? Yeah, I think there was, you know, it's funny. I actually like I used to not care about languages and then at some point, this was maybe like 10 years ago, I used to ride a motorcycle and I got in a pretty bad accident actually. I broke my arms. + +[`15:05`](https://youtu.be/AmdLVWMdjOk?t=905) Oh my god. + +[`15:05`](https://youtu.be/AmdLVWMdjOk?t=905) Both of them. + +[`15:06`](https://youtu.be/AmdLVWMdjOk?t=906) Both of them. Yeah. I had like two slings on. + +[`15:08`](https://youtu.be/AmdLVWMdjOk?t=908) Oh my god. How'd you code? + +[`15:10`](https://youtu.be/AmdLVWMdjOk?t=910) Um, so that was the hard part. So like I actually like couldn't code for like a month and then you know my hands like still kind of hurt and so like I couldn't write JavaScript which is what I used to write at the time. And so I actually had to branch out and learn other languages because they literally used less keystrokes. And so I started with like coffees script because there was like less parenthesis and stuff. I don't I don't think that language even exists. No one uses it nowadays. Um but that's also how I got into Haskell and kind of functional programming. Um cuz it was kind of you can do the same thing with fewer keystrokes and that that was like literally the motivation at the time. And then at some point I was working in uh at a hedge fund and this was like before uh before Facebook and I had a co-orker Rick who was really into Scola and I really didn't understand Scola and uh he he kind of really got me into it and he got me into this like functional programming side of the house and this is still like the one technical book I would recommend to everyone that has had the greatest impact on me as an engineer is this book called functional programming in Scola and you're probably never going to use schol today, but the way it teaches you to think about coding problems is just such a change from the way that most people were encoding either practically or in school is just it's incredible. it's going to completely change the way that you code. And so for me it was it was kind of like Scola was like there was kind of like Haskell and kind of coffecript these kind of few key languages that was like a first step then Scola and then Typescript and I think this kind of this changed the way I think because now I think in types when I code the thing that matters in your code the most is the type signatures. This is more important than the code itself. And so like getting this right leads to very clean code. And so even at Facebook where I was writing mostly kind of flow and and hack and then later at Instagram Python um it it was very helpful here at anthropic I mostly write typescript and python um so it's actually quite relevant but I but I think the the bigger lesson is just think in think in types + +[`17:07`](https://youtu.be/AmdLVWMdjOk?t=1027) at this point in your career uh you mentioned that you came in underleveled you came in as a mid-level engineer even though you had a lot of experience and you said um in hindsight you were lucky to be underleveled and I'm curious is what's the the thinking behind that? + +[`17:23`](https://youtu.be/AmdLVWMdjOk?t=1043) Just lower expectations. Um yeah, I feel I feel like at a big company there's all these kind of um you know like at every level there's certain expectations in terms of kind of the project impact and people impact and all this kind of stuff and the the specific criteria are kind of different across companies. Um but there's um I think a lot of it is about either project impact or kind of checking a bunch of check boxes and all this just takes a lot of time. Um and so I think coming in under level it just gave me the space to explore and uh just like build cool stuff for the sake of building cool stuff. Definitely. And I wonder if it also helps with building momentum. Like what I mean is if you came in as a mid-level or E4 and then you you crushing it. Everyone's saying Boris is amazing. What this is crazy as opposed to you came in at your whatever I don't know expectations and you did good. I think there can be this uh effect when you come in and you really wow everyone. you have such a strong um you know first impression I think can be helpful for building a good reputation that gives you more credibility more projects and stuff like that in the future. + +[`18:42`](https://youtu.be/AmdLVWMdjOk?t=1122) Yeah, I think that's totally true and I I think actually this is probably good advice for any company is like I think a lot of times engineers switch jobs and they really push you know like I want to go to a different company and I want like a level plus one or whatever [snorts] and actually there's a lot of downsides to that like you said. Going on to the thing that got you promoted to staff or E6 at Meta, I'm curious the story behind um you know where you were at the time and what got you promoted into more of that leadership position. So what was happening was chats and groups that was launched and that that was going and there was kind of a team working on this. Um, and uh, I actually had a I I'd done a lot of JavaScript before I joined, but at Facebook, I'd never actually written JavaScript cuz it was all PHP. + +[`19:28`](https://youtu.be/AmdLVWMdjOk?t=1168) And so I really just wanted to write JavaScript. And we had this like web interface. And for Facebook groups in particular, a lot of people use web as opposed to mobile because, for example, for like being a group admin or whatever, it's just easier to do on a big computer with a with a keyboard and stuff. And at the time the site was really janky. It was like a static site. It was all PHP. There's these little bits of JavaScript that are injected a little bit in different places. There's all sorts of inconsistent state like all these problems that come out of it. It's just it doesn't feel like a good UX. And so I wanted to rewrite it in JavaScript and I got a lot of push back from the or at the time. And I think the big reason was that the info just wasn't really ready for it. Luckily, at the same time, Comet was starting and Comet was like the rewrite of facebook.com on desktop. And this is like Tomcino, who's who's now at Versel, this was Jing Chen. Um, there there's a bunch of these kind of core people that that were working on this. And I just really wanted to be involved. So, I reached out and asked how I can help. And I offered Facebook groups as the guinea pig for it. And I didn't ask anyone. Just [laughter] kind of just kind of did it. And then uh later I kind of went to my leadership in Facebook groups and I was like, "Hey, comments's coming. It's going to be a bunch of work. We can get ahead of it." Kind of set the standard for everyone, build relationships with these other teams. And I still got a bunch of push back that was like, "Hey, you know, you can't put 20 engineers on this." And uh after a bunch of reviews and kind of haggling for engineers, I think we put we got like 12 engineers or something like that cuz it was a pretty big migration. You know, it's going to take like a year. groups is the single biggest product surface in all Facebook, which is actually kind of surprising. Um, yeah, and the the migration kind of worked and and I think something that was pretty fun about it besides just like building relationships and friendships with this infra team I never would have worked with otherwise, which was in itself so rewarding and so fun. Um, I think a lot of it was we got to influence the direction of Comet. And it's kind of weird because for an info project, a product team often cannot influence the direction. and they're more seen as a customer of it. But what happened here was because we helped co-build it, we built a lot of the abstractions that were then used by other teams that were also building on Comet. Um, and you know, for example, a particular one I remember was like relay mutations. So like you send API requests and you need some sort of consistency. Um, but there's actually this bug where like let's say there's like a button and you press the button. Every time you press it, you send a post request. And uh every time you press the button, it toggles the state of that button. For really nice UX, what you want is as soon as you press the button, the state should toggle, which means you need an optimistic update. But also, uh when the network request comes back, you need to also update the local cache to make sure it's consistent. And if you're just like mashing that button, what can happen is that the responses come in out of order and you might end up with a different state than what was in the UI. Um and so I wrote a system to kind of queue up mutations. So it was like consistency at the cost of reliability and this was kind of the right trade-off at the time. Uh and everyone ended up using this and this is how I met like Joseona and a bunch of the relay team that was working on the the data stores. Um, and it was just really fun. And this is something that since then and before then and you know whenever I work with engineers, I just love when people go a layer deeper and uh, you know, just try to figure out like what's going on and like just because you're a product engineer doesn't mean you can't build infra. Just because you're an infra engineer doesn't mean you can't go talk to users like just be curious about these other parts of the stack. + +[`22:56`](https://youtu.be/AmdLVWMdjOk?t=1376) Definitely. and in your agency and getting ahead of comet or this big JavaScript rewrite. You mentioned in your in your writing that you know getting ahead of that actually gave you a lot more control and also dibs on opportunities. So when you talk about opportunities there is is this what you're kind of talking about like building these fundamental pieces of prod infra that are impactful for everyone that's going to take on the new platform? + +[`23:21`](https://youtu.be/AmdLVWMdjOk?t=1401) Yeah. Yeah, that's an example of it. Um, and then maybe you know like a different kind of example is Comet was a lot higher quality than the thing that came before because it, you know, it's like a single page web app. Um, so it can just feel a lot more polished. But we hadn't yet figured out like what exactly quality means on the product side. And so I wrote a bunch of notes trying to define that and then did a bunch of tech talks trying to just like teach people on other teams like here's what we learned about quality. Um, and just kind of like setting up the conversation about that. you mentioned a big headcount ask for I guess this migration to comment you know I feel like I'd be curious what that would look like in today with these new tools like cloud codeex etc. I'd be curious like knowing what you know now about cloud code and you let's say you were in charge of doing that same scoping for that same job. How many engineers do you think it'd take to do that 12 engineer job? + +[`24:17`](https://youtu.be/AmdLVWMdjOk?t=1457) Yeah. So I think overall to move Facebook groups it it started with 12 engineers but I think at the end it was maybe like 20 or 30 engineers or something for about two years. So it turned out to be a pretty big project. Um I think nowadays it would be maybe I don't know like five engineers for six months something something like that. + +[`24:37`](https://youtu.be/AmdLVWMdjOk?t=1477) So a fourth of the fourth of the time and um like more than a third or less than a third of the engineers as well. + +[`24:44`](https://youtu.be/AmdLVWMdjOk?t=1484) Yeah. Yeah. cuz you just like everyone would just have a bunch of quads running in parallel and you know just like let it cook for a couple hours and then it comes back with a PR and then you give it like puppeteer or something so it can kind of see the UI and and adjust and I I think that's pretty much all it would be and then I you know nowadays the world we're in is so different from a coding point of view because the models are moving so quickly that you know if you ask me this question in 3 months or 6 months my answer will be totally different in 6 months the answer might be this is actually one engineer um it's just moving so quickly now it's really hard to to do these estimates or to predict how they're going to change in the future. + +[`25:22`](https://youtu.be/AmdLVWMdjOk?t=1522) At this point in your career you you had mentioned something maybe it was tongue-in-cheek I'm not sure. You said this was when I learned to always present three options in VP reviews since 80% of the time they'll just pick the middle option and then it says you your VP picked the middle option in frenies. Um what's the thinking behind that? Yeah, this is this is very much tongue andcheek. Um, but maybe this is actually kind of true at Meta at the time. [laughter] Um, I think like decision makers that are far away from the work want to know that you did the due diligence of finding the right options and the right trade-offs and that you did the work, but they also want to contribute somehow to the decision. Um, so, you know, the middle option is kind of the easy way to do that. It's a little tongue-in-cheek because I think not all leaders are like this. A lot of leaders will do their work themselves. They trust their teams more or less. There's sort of there's so many different ways to operate. Um, but at the time I remember we had like a pretty non-technical leader and this was kind of the way to to help her make make decisions. I think at this point in your career you had the most proximity you've had to senior management. It's you said you were reporting to uh a senior director at some point and you were involved in a lot of huge scoping conversations. I'm curious what's the downstream effects of reporting to someone so senior like that. + +[`26:43`](https://youtu.be/AmdLVWMdjOk?t=1603) Yeah, I think it kind of depends on the engineer and it depends on the company. Um, so for example, like you know, now I'm at Anthropic and I think at anthropic it doesn't matter. Um, it doesn't it doesn't matter which level you report to. There's some of the most senior people at the company report to line managers. Um, a lot of the line managers are like XCTO's and things like this. So um, it actually doesn't matter. So I think this is kind of like a meta it's a very meta-pecific cultural um cultural observation. I think there's sort of like two things going on. So one is you want at meta you needed uh as an engineer you always needed to find scope. Some of this you can find yourself and then some of it your manager helps you find or you know your tech lead or the people you surround yourself with and you know like the PSC process is like growing like famously growing at meta and so you just have to constantly talk about your impact and like scope is like the biggest contributor to that like if you have enough scope and you executed well that's impact that's the formula I think the other part was at meta no one had titles so even the most senior engineers their title was software engineer which I actually really love. And um you know like Bell We L We L We L We L We L We L We L We L We L We Labs had this with like member of technical staff and this is true at anthropic too, but we actually go even further here. Everyone's title is member of technical staff. It doesn't even matter if you're an engineer or a PM or a designer, it's all the same title. Um, and I actually really love it because back to this point of working outside your lane and doing stuff that just should be done and, you know, like are just good things to do regardless of what you are personally expected to do. Um, I think this kind of culture just sets that up. I mean, I I I see a lot of the benefits of the no titles. I could also see a case though where um and maybe this is only true for big companies where you reach out to someone across the company and you say hey I'd like to I don't know do this collaboration and if your title said director or whatever it kind of is like a shortcut for them to understand how seriously to take you or how to interact with you like if you're a designer or some other role. So I mean now anthropics got a bit bigger at this point. Do you see uh any of that? I mean, people probably all know you, so maybe you don't see it as much. + +[`29:01`](https://youtu.be/AmdLVWMdjOk?t=1741) Yeah, I think I think this is definitely the downside. I think the upside outweighs it, which is you have to earn trust. And I I think this is true. Like, you know, regardless of what company you're at, you got to earn it. And just because you did a cool thing before, doesn't mean that you have you should deserve respect. Well, everyone deserves respect. Doesn't mean that you should deserve authority at a new company in a new setting. Um, so I think even for people coming in with manager titles, you kind of have to earn it. And in some ways, having a manager title makes it a little bit harder to earn this kind of trust. Um, so as an IC, you got to do it either way. And I I think just the lack of titles makes it a little easier. At this point in your career, you were kind of like becoming more and more of a tech lead or Uber tech lead. And I think you had a few stories where you scoped out work for hundreds of engineers. And I was just thinking about how do you do that if there's so much to scope and you know you're one person. How do you go about doing such massive scoping requests for leadership? + +[`30:03`](https://youtu.be/AmdLVWMdjOk?t=1803) Yeah, this was a totally insane time. So I worked a lot with uh Tina Shutchman who's uh she she's now at Microsoft um but she was she was my manager at the time and then uh Ephe who's who's my manager after and there was a lot more investment going into Facebook groups at the time. So I think the org was maybe 150 or 200 people when I joined and by the time I left to Instagram I think it was like 600 or 800 people something like that. So there's this feeling from Zach that Facebook app should be all about communities and he just wanted us to go like faster and faster to make that a reality and you know as an executive your kind of biggest way to do that is to put the right people in charge of decisions and then uh to give them resources and so like in you know in the case of meta it's it's just engineers um you don't need like GPUs for this you need like engineers to do stuff and so we pitched this project to uh to Zach and it was called communities as the new organizations that was like the internal name and uh he grin just like a a bunch of headcount to go towards this and so we just had to figure out what these people will do and you know for him I I get it it's like if the thing is important you got to put a bunch of people on it in hindsight what I would have done differently is I I would have put way less people on it because what matters is like solving people's problems and building awesome product and this actually has to kind of be bottoms up and you kind of want to like slowly dial this up as you find product market fit for new product lines you can't just do it all at once. And uh yeah, we just had to like scope out all the stuff. Like there were weeks where I had to, you know, do like a scoping dock for like, okay, we're going to put 30 engineers on this. Here's like three technical options. We're going to pick this one. Next project, we're going to put 20 engineers on this. Here's three options. We're going to pick this one. Next project we're going to do. And just like doing this like over and over again just to have like, you know, some some sort of confidence that this thing isn't totally crazy. We did some baseline technical scoping roughly matching the number of engineers to the project. And there there's actually some pretty fun stuff like I remember we were trying to merge Facebook groups and uh pages at some point like in the in the data model side and this was this like very gnarly migration it would have been you know to fully do it this is like many years and like probably hundreds of engineers to fully do it because you have to do it across like the data model the product layer integrity systems ad systems there's just all sorts of stuff that has to get merged and at the time Ysef Carver uh he just joined I think he came from either profile or events like a different or that that joined forces with groups to make this happen and he was working on it but he was kind of struggling with a with a decision at the time and I think he was even more senior than I was but he just like wasn't making the decision on the data model and so I just took a bunch of people and I was like all right the tech leads across the entire org we're going to spend the next like 3 hours on this day and we're going to do this like essentially like game where we get to do architecture and so I split everyone up into two teams I think it was like blue team and green team or I I forget what these were. And we gave everyone this like this problem of like how do you merge these data models? Here are the requirements. And then everyone had 3 hours in a whiteboard and they had to come up with a design. And what was cool is that going into it, we had no idea how we would do this because it just seemed too crazy of a problem. But the going out of it, we had two designs that were 80% the same. And so it was really obvious what we could execute on. And then the 20% where the differences were, it was very obvious where the risk was. And so we could kind of front front frontload a little bit of that risk with a little bit of technical spikes. Um but also we can just start execution right away because we knew exactly what we had to do. + +[`33:31`](https://youtu.be/AmdLVWMdjOk?t=2011) Yeah, that was really interesting when I saw that it was like a technical design competition with all the senior engineers and you just put people in separate rooms to come up with um I've never heard anything like that. When you proposed that idea for this design competition within the org, were people excited about it or was it like kind of a crazy idea? + +[`33:52`](https://youtu.be/AmdLVWMdjOk?t=2032) Yeah, it was sort of crazy. I mean, with this sort of thing, you just have to kind of do it. So, I just I just kind of told everyone, "Hey, we're doing this." And then I just put it on everyone's calendar and um it just seems fun, you know? So, like as an engineer, you would want to do it. But I think this is the sort of thing where like sometimes you need consensus and sometimes you just have to act. And in this case, because the path was unclear, it was important to act. But at the same time, I didn't know how to proceed. So, we had to kind of get everyone together to build consensus. And so, I think it's like as a leader, you're kind of always juggling these kind of two things. + +[`34:23`](https://youtu.be/AmdLVWMdjOk?t=2063) After that experience, just giving being given hundreds of engineers and scoping things out, do you have any tips for someone who's like a tech lead who's needs to do quick, you know, scoping? Anything that worked well for you? I think the biggest thing I think the biggest foe that I've seen is people just taking too long and getting too into the weeds. there's always an infinite number of details. Just start with a high level. You know, most technical scoping you can do within like 30 minutes very very roughly. Um and if you don't know the systems like nowadays you would just use quad code run in the codebase and just ask it to like you know like what are all the systems involved? They can actually just do this for you. And this is another just totally insane change. You know I when I was doing this stuff I never would have expected that AI could do this for me now. Um but now it does. in the past. I think that would have been my biggest advice though is uh just time box it. Spend maybe 30 minutes, maybe like couple hours max. If you have to like dig through code and stuff, um definitely reach out to experts and just make a list of experts. Talk to all of them. Run the design by them. Don't just ask them for input. Give them a straw man cuz then they can actually like give you feedback on it and it's something to go off of. Continuing with your career story, I think the thing that got you promoted to senior staff or IC7 was um public groups on Facebook. So I'm curious like the story behind your involvement in that and you know anything interesting that happened at that point. Yeah. So public groups was one of these projects that came out of this uh the scoping for um you know like making Facebook groups more about communities. There's this like one very narrow change that we wanted to make that seems so simple on the surface, but it was so complex under it. And it's just funny like explaining this to anyone that wasn't there. They're like, "Wait, this is like a oneline change." And I'm like, "No, it's not." It's like it was very difficult to pull it off. And so the change was in order to participate in a public Facebook group, you no longer have to join first. + +[`36:18`](https://youtu.be/AmdLVWMdjOk?t=2178) So you're saying um you can just view like you have read access for all all groups essentially or public groups? read access for all groups and for some groups even comment access. So you can comment without joining first. + +[`36:28`](https://youtu.be/AmdLVWMdjOk?t=2188) Interesting. + +[`36:29`](https://youtu.be/AmdLVWMdjOk?t=2189) And this is the thing you know it feels like a oneline change and it actually was a oneline change but there's all these downstream implications that were so tricky. So one is um you know in the data model there's essentially a field in the database that was like group member and we had this like really intense technical debate about like these people that are commenting in a group are they group members and the model also changed where before to join a Facebook group an admin had to approve you so there's kind of a vote of confidence that you can be in this group and then after we switched to this model where to join a public Facebook group you just you just essentially press like follow and we actually went back and forth should it be join or follow like what's the right verb to describe this but it was essentially follow cuz there's no reciprocal action you know if you follow a group are you a member like should you be stored in that same part of the database and we we just went back and forth on this for a while and I remember at the time there was this like really senior engineer Bob he was kind of the most senior engineer in the in the or at the time and he felt very strongly that it should not be the same thing and he kind of pushed us pretty hard um even though it would be a ton of engineering work to migrate stuff to make at a different thing. And so we did this work um because he was actually one of the early engineers on Facebook group. So he knew it really well. Um and he felt pretty strongly. There's a bunch of these other like downstream changes around uh like moderation and different new like admin tooling that admins would need to handle kind of the influx of spam and things like this. And I remember at the time thinking like if anyone can make a comment, the comments are just going to be like filled up with spam. And I had to hard I had a hard time kind of convincing people of this. And so at some point I built this like Monte Carlo like visualization of how this would work. And it was just like this like really simple kind of like scratch pad of you know like a comment comes in there's a certain probability of it being good or bad and then like what actually happens to comments. And I think that actually did a pretty good job of convincing the integrity teams to jump in and help with this. And so at the time the pages integrity team jumped in and they helped with a comment ranking because kind of ranking spam comments lower was the main technical mechanism to make it so people don't see these comments. So there's a bunch of these like pretty gnarly downstream implications of uh letting people participate. There's also this data model migration that we're doing. And so to do all this, we had to staff a big team to um to kind of make this happen. And so we hired a new director, Yammen, who um hired a bunch of engineers. There's a bunch of internal transfers. So some of the most senior engineers from the org like uh there was like Henry Henry Long uh Joe Cham there was like a few other engineers and they were all working on this and I was the same level as them. I was like a you know an IC6 at the time and so were they and I remember just feeling this kind of imposter syndrome of having to kind of direct them and kind of point them at work knowing kind of in my mind that we're the same level even though levels are hidden. you kind of you know you know through like rumors and stuff who's what you know in hindsight I think this is sort of like misplaced imposttor syndrome because levels don't matter at all this is my current view and you know some people that are very junior can shoot way higher than that and just give you amazing results some people that are very senior can give you terrible results and so the level actually doesn't matter that much but at the time I remember just like really thinking about this and it it was just kind of hard to step into this role And eventually I did it. And it's funny, eventually the thing that got me the promo to IC7 was reversing this decision that Bob did cuz he wanted to do this big migration. And we did it. And it was just like, dude, it was so much work. It was like it was like 6 months or a year of work or something just migrating just hundreds and hundreds and hundreds of call sites to to do this correctly. And then technically I felt like actually what we did is we essentially just added an if else at every single one of these call sites in the process. We audited all the call sites. So we kind of knew that it was safe but uh we didn't actually change the logic. And so actually what we learned is that yes member is the right field to model both followers and group members. This was the right decision. And so I pushed the same engineer that did this to then undo it. it was the right thing to push this engineer because it showed maturity on his part that he said yes and was able to do it. He also had the most context technically so he could do it the best. And I think for Bob it made he he felt better about me as a technical leader because he knew that I was wishing I was willing to pull back to to push back on um decisions that even senior folks make. Um and in the end this was the right thing. So we reversed the migration. It also took a long time to do it, but in the end it made it so everyone building on this info could do it and everyone wasn't always constantly bumping into this like should I use this field or or this field. + +[`41:15`](https://youtu.be/AmdLVWMdjOk?t=2475) Yeah, I'm curious about that part cuz you had a strong technical disagreement with Bob or senior TL. Um, but the outcome at the end is actually it seems like it strengthened the relationship. He was a champion for you in your your promotion. So, I'm curious, how would you recommend going about strong technical disagreement in a way that doesn't hurt the relationship? + +[`41:38`](https://youtu.be/AmdLVWMdjOk?t=2498) I think the biggest thing is you have to earn it. Yeah. You just have to earn trust and it could be as simple as, you know, like what I did at the beginning, which is just disagreeing and committing and showing that I'm willing to do that and I'm willing to just execute if someone else thinks it's a good idea and I kind of look up to them. But also you have to kind of show that you have good technical judgment. Um but you can't really do that until you earn trust. So take the time to get that trust first. + +[`42:05`](https://youtu.be/AmdLVWMdjOk?t=2525) And then on the imposttor syndrome, um leading those engineers that were also very strong. Um do you have any advice for overcoming imposter syndrome? + +[`42:14`](https://youtu.be/AmdLVWMdjOk?t=2534) Yeah, just don't overthink it. You know, no one really knows what they're doing, you know, at any level. No one really knows. We're all just trying to figure it out. + +[`42:22`](https://youtu.be/AmdLVWMdjOk?t=2542) That's easier said than done. Was there like a an aha moment where you realize actually maybe I do got this or this isn't that big of a deal? You know, I don't I don't think so really. There wasn't a single moment. It just it kind of goes away over time. And I think at every at every level, it doesn't matter what level you're at, you should always feel a little bit of imposter syndrome cuz if you don't, then you're not pushing yourself hard enough. + +[`42:45`](https://youtu.be/AmdLVWMdjOk?t=2565) At this point in your career, you were like more and more of a tech lead and and therefore you were writing less and less code. Um and you mentioned that um you know at Meta especially there's cases where other functions are underst staffed and you view that as an opportunity for engineers so to be you know more product minded and maybe help out with uh you know the PM opportunities. I'm curious when would you say that you should go that direction as opposed to escalating and say hey we need more PM support um and you know trying to write more code instead. Yeah, you have to understand the trade-offs. I think this is the this is the thing that I think a lot of people don't really get when they push for stuff or, you know, I think a very common failure mode is an engineer will push for an idea and then get gets frustrated when no one else buys into it or wants to fund it. Um, or the organization just like doesn't listen or their leader doesn't listen. But what you have to do is understand the trade-offs. And whoever it is that you're trying to convince, think of it from their point of view. What do they care about? What are the projects they're working on? What is this trade-off against? if they do this thing, are are they going to see their work as a as a success? Um, so I I think I think that's really important and for some orgs at sometimes they might not have PMs cuz it might just not be a very sexy project and so it might be really hard to hire and maybe the leader is already feeling that pain. Maybe for some orgs uh they are trying to hire PMs but there's actually just much much more important things those PMs should go to. For other orgs, they might they might actually have like too many PMs. And so actually, if you ask, that's the right thing to do. Uh because they could just take a PM off a less important project and put on your project cuz it's more important. So I think it's really important to kind of be situationally aware, understand the context you're in, and understand how your decision makers think about it. at this point and this is kind of the end of that part one of your story. You credit a lot of your success to again the side quests and like having these side projects or running list of you called them 20% time ideas and I'm curious do you have any tips on how to find opportunities for engineers? Yeah, I think at some point there was probably I forget the exact numbers, but there was probably like 5000 engineers or something like this that were just like working on these like side quests that I like scoped out and like spun out of various points. And so pretty much like every week I I'll think of like some project, you know, just like on a run or something or maybe like while I'm coding I think of some idea, I'll just do some basic validation and then I'll just ping an engineer that I know and be like, "Yo, are you interested in this?" And then I'll connect them with a couple other engineers that might be interested. And this kind of added up very quickly. I think the for me one way that I really think about my work is how can I do less of it? And as an engineer, our superpower to do this is automation. The most tedious stuff you can automate. And this is something that's like really hard actually for other fields, but for us it's this incredible thing that we can do. And as it's something a lot of engineers don't really do for whatever reason, but we should all be doing it all the time. It's so important. It's leverage. It's like free leverage. And so a thing I often did was every time I did a code review, if I was commenting about a particular kind of issue, maybe like a stylistic issue or something, I literally had a spreadsheet where I would tally up that issue and I posted kind of the link to that poll request and then I would do this for every code review and then when I commented about the same kind of thing more than a few times, I would just write a lint rule for it to just automate that. Um, so this is kind of an example of leverage. So, and at some point I automated most of my code reviews cuz like I just had a you know like a flock of lint rolls that were just like doing all this work for me. And I think this is actually kind of similar because all these side quests it was improving prod infra and dev infra. And these are things that slowed me down in my day-to-day coding. And this is why like when I was doing west coding this was actually very dangerous because as an engineer you need to be anchored to reality. You need that intuition and if you're not in the code anymore then you lose it very quickly. It's it's a very dangerous place to be in. And so for me when I was in the code a lot there was all these really cool ideas that came out of it and it was leveraged not just for me but for the whole edge team because again of this principle that if you have a problem probably other people have it too. And you know I did like YC back in the day and in YC they teach you that first you build for yourself. You have to build like awesome stuff. You have to build stuff people love. But if you're trying to find a market to build for you start by building for yourself. And that's a pretty good indicator other people probably have that same problem. + +[`47:19`](https://youtu.be/AmdLVWMdjOk?t=2839) Yeah. There was a quote that you wrote that I thought was really good. You said better engineering is the easiest way to grow your network and gain influence as an engineer. So I could totally see um you had like your scope of influence was so much further than just the code you're writing because you're passing people all these great ideas and you know overseeing them. It's the the leverage is really uh insane. + +[`47:44`](https://youtu.be/AmdLVWMdjOk?t=2864) Absolutely. Yeah. And and it's also just like an example of being contextually uh was it situationally aware + +[`47:50`](https://youtu.be/AmdLVWMdjOk?t=2870) um because you know at meta at the time engineers were evaluated in the performance cycle uh we looked at project impact people do you remember the other + +[`47:58`](https://youtu.be/AmdLVWMdjOk?t=2878) direction + +[`48:00`](https://youtu.be/AmdLVWMdjOk?t=2880) and edge excellence + +[`48:02`](https://youtu.be/AmdLVWMdjOk?t=2882) and edge excellence yeah and the edge excellence is a thing that a lot of engineers struggled with and so you know I was you know one of the people that came along and was like hey if you want to do edge excellence here's a project and people are already incentivized to do it. So, they see it as an opportunity. And I think this is just like I don't know. I think it was a chance for me to kind of hone my skills about working with people where you never ever want to tell anyone what to do in any in any context. In a personal context, in a work context, everyone hates being told what to do. But if you understand what a person wants, then you can go to the right person with a red opportunity and they see it as an opportunity. Um, and this just always works better for everyone. When I think about these 20% time ideas, I mean, there's the there's the top of funnel, finding the ideas, and then there's actually, you know, executing on them, the, you know, getting someone to do it or whether it's yourself or someone else. Um, the thing I'm interested is the top of funnel, like how how do you source so many ideas um as an engineer for these side quests that are impactful? + +[`49:06`](https://youtu.be/AmdLVWMdjOk?t=2946) Just common sense. [laughter] I don't know. Maybe maybe spidey sense. I I don't know the right word sense like how so like what's a what's a concrete example? + +[`49:15`](https://youtu.be/AmdLVWMdjOk?t=2955) Yeah, like a really concrete example is um you know like I think lint rules are a good one. Maybe maybe another one is there were all these cases where we had sevs because uh Facebook groups were not being tested with very large sets of so um and so like for example and so kind of like this is kind of like a Facebook way of saying like you know rows in a database. So you could imagine like a Facebook group with like 10 million members. Like no one's ever tested this. There's no like unit test for this. You only see it in production. And when I looked across the org, I started seeing similar cases of this. There's, for example, like if you have a profile with like 20 million followers, a lot of stuff breaks. But obviously like no one tests this in an automated way just cuz it's kind of annoying to write a unit test with this much data. And so there there's a bunch of instances of this. And then um I pitched an engineer to build a way to write unit tests for large data sets. So you know like a really big object like a group with a lot of members, a profile with a lot of followers, an event with a lot of attendees. And uh I think this infra still exists. Um and it's you know it prevents a lot of issues and this is something where you can scope it and then he brought in a bunch of other engineers to do the work and and help him out with it. So I guess just think about the problems that you actually hit day-to-day. + +[`50:27`](https://youtu.be/AmdLVWMdjOk?t=3027) Got it. Okay. So think about the problems and if you're experiencing that problem repeatedly then it's time for automation and that's like a great uh better engineering project. + +[`50:38`](https://youtu.be/AmdLVWMdjOk?t=3038) Yeah. Exactly. Exactly. Like if you hit the same problem like two or three times you should probably kind of look around see if other people are hitting that project hitting hitting that problem too. + +[`50:47`](https://youtu.be/AmdLVWMdjOk?t=3047) The last leg of your career at Meta um this is where you got the E8 promo. I know that um you moved orgs. So, you did all of your growth in Facebook groups and then you moved to Instagram. I'm curious, uh, what's the story behind you moving orgs to Instagram? At the time, um, I was dating, my wife and I were still, uh, dating. And, um, she was living in Berkeley, I was living in SF. And at some point, she's like, I found my dream job. And I was like, sweet, awesome. And then she was like, we're gonna have to move. And I was like, okay, great. we we've been dating like 3 months at the time and uh we were kind of deciding like should we like keep dating and um and so she was like yeah we we would have to we'd have to move if you want to like keep dating and I was like yeah okay I do let's let's do it and then so the job ended up being in like rural Japan like it was sort of like middle of nowhere and I was trying to figure out like how do I do it because I really like the work that I was doing + +[`51:46`](https://youtu.be/AmdLVWMdjOk?t=3106) and so first I talked to uh like Facebook groups leadership and tried to set up like a Japan out there for for Facebook groups. That didn't really work for, you know, a bunch of kind of organizational rules. Um, then I tried to do this with the VR org and it was actually working, but then the person that was sponsoring it left to go to, I think like YouTube or something. Uh, and then at the time Will Bailey reached out and he was in the Instagram Tokyo office. He was part of this like landing team for for Instagram and he was like, "Hey, I kind of want to grow this office. Do you want to be part of that?" And I was like, "Yeah, let's let's do it." And I didn't know anything. I I didn't even have Instagram installed at the time. I'd never used it in my life. And um I so I I said yes and then I immediately downloaded Instagram and then like I moved like I think like the next week or something. Um so pretty much or or actually you know I think it was like a few weeks that that I had in the US. But I I moved out pretty quickly. Um and I actually really fell in love with the Instagram culture. Um it was very different than Facebook culture. big emphasis on building awesome products, on on shipping stuff that people don't use, on thinking about things not just from a data point of view, but also from a human point of view and an experience point of view. And you can see this in the app and in the craft that goes into it. It's just completely different engineering and product and design cultures between the two companies. Um, so I learned so much being being on that team and that that was such a fun journey. + +[`53:16`](https://youtu.be/AmdLVWMdjOk?t=3196) You mentioned the the un shipped part. Um, what what is that? + +[`53:21`](https://youtu.be/AmdLVWMdjOk?t=3201) Unchipping is the idea that if you just add features to an app, it's cool for some small percent of users, but it's actually bad for most users that don't use the feature. And so, you can think of an app where you only add features to it. And over time, the features accumulate and they add up. And you know, if every feature is used by like 10% of people, the average user sees a bunch of features that they don't use. And so, it seems cluttered and confusing. And when they open the app, they don't know what to do. And uh you know like with software fundamentally the screen is a limited size. That's the limited real estate. Uh there it's a limited resource that all the different features are competing for. And so by adding a feature that's taking the opportunity away from you know a different feature the person could have used. Um and so unshipping is the idea that you have to meet some sort of usage bar and if a feature doesn't meet that bar then we just delete the feature. And a small percent of users are going to be pissed, but it's actually great for the majority of users. And on average, it's really great for everyone + +[`54:22`](https://youtu.be/AmdLVWMdjOk?t=3262) at this point in your career. Um, I mean, you moved, you didn't just move orgs, you moved across the world to work at Instagram. And I think when you're such a senior tech lead with a lot of credibility in your existing org, it's much easier to get things done or at least influence others cuz they say, "Oh, I know Boris and I know his past work." But I'm curious, how did you build up credibility uh at Instagram uh when you were so far away from everyone else? + +[`54:52`](https://youtu.be/AmdLVWMdjOk?t=3292) I think a lot of the credit early on this goes to like Nam who was Nam Guian, he was the he's still the VP of Avenge at Instagram and and Jeff Hang um who was my director at the time but he now he's a VP. Um and you know will I think there was a lot of connections made by these people. So you know for example Nam was like hey you really like doing you know working on code quality and like tech debt reduction you know which we call you know better engineering at meta and he kind of connected me with the people working on it and this was like Lucas Camera and um Gabe and a bunch of this bunch of these other folks that that were working on this stuff. Uh so so those connections were really useful. Um, and then I think a lot of it was I just had to earn the trust again. And honestly, this is a healthy thing to do. And I think this is one of the really awesome things about meta engineering culture that there are not titles. And so you kind of have to constantly reearn your trust. And you know, even if I was a great engineer in the past, I may not have been a great engineer at Instagram. And if I wasn't, then I don't deserve influence. I don't deserve to have a really loud voice that people listen to. So I had to earn it along with everyone else. And so my first few weeks I spent a lot of time like meeting people, mapping out the org, mapping out goals, writing a lot of code so I can get to know the codebase. But then in Japan it was totally different because you know like 400 p.m. Tokyo time was like or it was like 9:00 a.m. Tokyo time was like 7:00 p.m. New York time. There was just like no time zone over. + +[`56:25`](https://youtu.be/AmdLVWMdjOk?t=3385) It was rough. Yeah. Um, but it was also great because I think in the few years before I was doing so many meetings and docs and all this stuff, I just wasn't coding. Um, so I just started to feel pretty unhappy cuz like as an engineer we code. That's that's what we do. Like that's that's the reason we pick this job is you like for me like when I write code I have an emotional relationship with a code and it's something that I think about when I'm really deep in a problem. I dream about it. So it's just so important for me to code. And when I wasn't doing this for years, it was sort of rough. And I think I was starting to burn out a bit. And so, actually, it was it was a gift to be in this time zone where I literally couldn't do meetings cuz people weren't awake or didn't want to like, you know, do 9:00 p.m. meetings just to talk. Um, so I didn't do any more one-on- ones. And this is actually still something I I don't do. So, I still don't do any standing one-on- ones. And I just could spend a lot of time coding. And what I realized is I was one of a few engineers at Instagram at the time that was coding this much. Um, you know, people code, but people don't code that much because there's all this stuff that fills up your time there. There's meetings and, you know, docs and all these other obligations. And I was able to do a lot of stuff that I think everyone else wanted to do, but just didn't have time. Um, and this was kind of a superpower in in that org. And pretty early on, Nam connected me with uh with Joel Pamer, who's still a good friend and and and mentor and um he's he's at Google now. And we just started talking about like you know at the time the codebase was written in Python and uh there it was sort of rough for a lot of different reasons and really the codebase should have been moved over to hack which is the main Facebook monolith you know and this is where all the language support is. There's so much infra HHVM is just this absolutely phenomenal web serving stack. There's nothing else like it in terms of like efficiency. If you're using GraphQL, you absolutely have to use it because it's just so optimized for this stuff. And Instagram just wasn't using any of this. And engineering was suffering. Like in the really early days, you know, like when like Mikey was at Instagram, really basic decisions were the the basic principle for decisions was do the simple thing that works. And this worked really well. But then at some point it stopped working once you get to like a thousand engineers, 2,000 engineers working the codebase. and you know many many years of techad and products built on top of each other you kind of have to do you have you have to make slightly different decisions than you would have made at the start and so even if Python was absolutely the right decision at the beginning it was not the right decision by the time I was there and this was painfully obvious as an engineer and I think a lot of other people saw this but what stopped them was just the amount of work it would have taken to to move the stuff over and so I just started like scoping this and kind of figuring out what it would take and so I started by finding the people that would disagree the And there's a bunch of these like info old-timers that just thought this was like a terrible idea and would never work. And so I went to talk to them first at like food in New York and you know like we got a bunch of beer and just got to know them as people before we even talked about the technical problem. You have to build trust. So I had to kind of get to know them as people and this was so valuable and this is still a lot of my friends today. Um, and after building this trust, I also learned there was a bunch of other people that actually did want to do this and were kind of afraid to say it. And so these people came out of the woodwork too. And eventually we started scoping this and this project kind of spun out. And it it's actually still going today. And there's, you know, many engineers working on it. But it but it was it's funny because at Facebook I think this kind of problem rarely happens because the org is so engineering driven. At Instagram there were many problems of the shape because the org is very product driven. So there isn't just a lot of time for those engineering driven initiatives. this project at some point I mean you got it off off the ground kind of this bottoms up initiative and then at some point it became high pry enough where it needed that uh in-person support of someone that wasn't in Japan and I understand that Jake Bolum is someone that you helped onto the project and he kind of took more of a a lead role um but locationbased and you know close to everyone else so he can help shepherd it along. Um, I'm curious your thoughts on that point of delegation. Like when do you decide when to delegate something so big and when do you decide, oh, I I need to still be around and how do you navigate that trade-off? Jake is amazing. We're we're, you know, we're friends. Every time I go to Seattle, we we hang out and he's just one of the best engineers I know. So, it was obvious that he would be a good owner for this. The same rules of delegation apply as always. So, you know, you delegate. You never delegate the thing you don't want to do. That's kind of the most important rule. You always delegate the thing you do want to do and that you know well because then you can monitor the progress and make sure it's going well. Um and there's this really great book uh high output management by uh Andy Grove. He was a you know old Intel CEO and it's just like the most boring sounding book ever, but it's just like the best. And this is one of the pieces of advice is delegate the thing that you like to do so then you can monitor progress. And so yeah, it's it's kind of the same thing. You kind of delegate a little bit. you check in. The more trust you have, the less you have to check in. And with Jake, he's so good technically and so proactive. There's just very little I had to do. It it was very much on track from the start. And so I think this coupled with um some other work uh large migration to kind of GraphQL or modernize some of Instagram's data model ended up getting you uh promoted to this principal level before you left Meta. Um, what was the story behind the promotion or anything that you might share + +[`1:01:58`](https://youtu.be/AmdLVWMdjOk?t=3718) that promotion? I think Will in in a one-on-one that I had with Will, my manager, he was like, "Hey, like I think you should like we should put you up for IC8." And I was like, "Cool." + +[`1:02:08`](https://youtu.be/AmdLVWMdjOk?t=3728) And that was pretty much it. I I hadn't really thought about it. Yeah, it's not something I really asked for. + +[`1:02:13`](https://youtu.be/AmdLVWMdjOk?t=3733) Um, I think Will was just like does a great job of recognizing people and kind of advocating for his team and he felt that I was ready and yeah, that was that. at any point in your journey because it sounds like you were impact and impact only and growing and your leverage and your credibility everything was growing and then the promos were this lagging thing where they just oh they kept happening as a byproduct. Um I'm curious though to structure your thinking about how to um get more leverage or kind of have more impact. Did did you ever think about the levels or would you say that it's not good to think about like oh what's the next level more think in terms of just I don't know leverage or impact or something else you have to think about what levels are for right levels exist so that the company can communicate to an engineer what it is they expect the engineer to do it also exists so that there's some accountability so for example in performance reviews the engineer at a particular level you can compare them to another engineer at that same level and also sometimes on the finance side different engineers or you know the pit costs a different amount. So you can kind of think about what kind of portfolio you want. So you know levels it kind of exists for company reasons and not for engineer reasons. And for me it's just never the way that I thought about any of this. Like the thing that I like to do is work on interesting projects. I like to figure out the problems and solve them. I like to um just make the things that people use delightful like the products that they use delightful. this this is what really motivates me. So for me, this was just never really the way I thought about it. And I I don't know like my my first week at Facebook, I was like an IC4 and I was I had like all these ideas for stuff that we should build. And so I just started writing like product briefs. And then I remember I went to like the VP of like connectivity and like pitched him some idea and he just didn't understand it at all and thought it was terrible. And then like that didn't work. And then I had another idea for messenger and like I went and like pitched that and like they also like didn't do it. But then they actually did end up building it a couple years later, this particular idea. So yeah, for me it's just like, you know, what are what are the cool ideas and like how can I help and who else is interested in this stuff and how can we build build cool stuff? You left Meta to go to Anthropic and I'm very curious what was your thinking about going to anthropic. + +[`1:04:32`](https://youtu.be/AmdLVWMdjOk?t=3872) I remember using chatt for the first time when it came out. This was uh you know this was like year years ago and I remember I was I was in Japan. I was the only engineer in my town. I was the only person that spoke English in my town and there's just no one that I could talk to about tech stuff and I remember every every morning I read Hacker News and I I remember using Chat GPT and I was just like blown away by by the product and just this this feeling that it gave me of just nowadays we take it for granted but you know LMS are just magic. It's just this absolutely incredible technology and I think now my view of it has shifted. It's like to me it's LMS are this kind of alien life form that we get to nurture and we get to bring into existence. It's not just a technology. And I'm also a really big reader. I I read a lot of sci-fi. That's kind of my my big genre. Um and so at the time I was like, "Oh my god, I have to work on this stuff." And you know, what are what are the labs that are that are working on it? So I went to talk to friends working, you know, at various labs. And I feel like when I came to Anthropic, I remember my first lunch. This was with Ben man, who's uh one of the founders here. And we were sitting at lunch with like him and a bunch of other people. And I mentioned this like weird like sci-fi book that I like. Uh it was I think it was like by Greg Egan or something. It's like hard sci-fi author. And I've literally never met anyone that's read this book. And at the table I kind of gave an anecdote from it. And everyone around the table was like, "Oh yeah, yeah, that book was good, but like what about this other book?" And so it was just like this group of people of these like intense sci-fi nerds, these people that think so deeply about these same problems I care about. And I I think the other part for me was how you're reading a lot of sci-fi, you kind of get a sense of, you know, in a very speculative way how this thing can play out. AI is just so transformative to society. I think it's hitting engineering first and it's going to hit every part of society. It's going to affect everything. And we're seeing the very first waves of this right now. And I think I just, you know, like I I read enough that I kind of knew the bad ways that this can play out and there can be so many ways this thing goes wrong. And so for me, anthropic was just the obvious choice cuz I wanted to be at a place where in the tiniest way I could make sure this thing goes well, which is as an engineer, this is all I can do. Um, and it it's funny. I think like before I joined, I sort of took safety seriously. Like you know, it's like a thing that can happen. And you know at Meta it was always seen as this kind of tax where integrity teams and you know and so on they kind of like they get you to do stuff but it's not really the thing anyone's really excited to do because it's not the product. And so this was kind of my view of safety before but at the same time I kind of speculatively knew that it could be kind of a very different thing. And now being at Anthropic, I know it's completely different and I see every model that comes out and kind of the new risks that come with it and how as a company we put our money where our mouth is, you know, in terms of like how much compute goes to safety research and alignment research in terms of like how many people work on this. We've held up model releases in the past because we did not know that they were safe and so we had to make sure that they were safe before. Um and I think also like with Opus 4 the risks just went way up like if the model can design you know like bioviruses and can do these things that are like really really dangerous and it's not just like you know like the baseline risk is something like election manipulation. This is something that you know like at was a really big deal. This is sort of a risk for kind of a low-level model. As the models get more dangerous, the risks get higher and very quickly you get into this territory where people can use the model to build things that are actually dangerous for humanity. Like not not just like you know like uh you know politics in a country but like literally the existence of humanity. Um and these this is not sci-fi. This is a real risk today that we actively have to fight. Um and so for me just like getting to be a part of this and getting to contribute a little bit this this is just what put me over. What about when you joined? When you think about the engineering cultures that you came from compared to enthropic, were there any really jarring differences? Yeah, I would say the two things. One is still being a startup, there's a lot of common sense. Um, and it's funny. I think this is something every big company loses and it's sort of this thing you have to fight because over time the decision makers get more distant from the impact of their decision, whether it's the product or the people or whatever. you have to come up with all sorts of processes to bring them closer and to improve the quality of decision-m but still being at a startup uh everyone just has common sense and generally just does the right thing. So I don't have to spend a lot of time convincing people to do stuff. If we should just do something it's it's obvious and everyone just does it. I think the second thing is for me personally something that I learned over time motivates me the most is mission. It's so important and it's the thing that keeps me going to work every day excited to go to work every day. It's the thing that makes me like code on the weekends because I want to do it, not because there's a deadline. Um, and so I I felt this a lot actually in Facebook groups. It it was very missionoriented. And um, for a long time, Jen Dolski was the VP and she she used to be the CEO of change.org. And so she ran all of Facebook groups like a nonprofit. She had like a theory of change and this theory about how you want to connect people to like-minded people to form communities and it was just so motivating to work on that. And I feel like at Instagram, you know, maybe because of the geographic distance or maybe something else, I just never quite felt that same mission. Um, but I feel like at anthropic I feel that so strongly and um that's probably the most exciting thing for me. I know that you know you're you're credited as the creator of Cloud Code and I think you've you've told that story in many places um but I'm kind of curious uh I was talking with a friend about what the environment was like when cloud code came and there were actually a lot of competing existing tools that hooked into the model and I'm curious what is it that was different about cloud code that kind of won out and just caught like wildfire internally At the time coding looked very different. If you thought about AI coding, people thought about like autocomplete. That was essentially it. I think there was like some very early agents, but it was kind of a secondary thing next to the auto autocomplete. And often times it was used for Q&A. Um it wasn't really used for coding. And so when people thought about AI for coding, it was just a completely different product that you imagined. You know, it was like tab to autocomplete. And I thought that's what it was. And I thought that was kind of the state of it. And then um Ben who um was my manager at the time uh he pushed me to think a little bit bigger and he I think really internalized cuz you know he was there from the beginning of of Enthropic and you know he was like at at other labs before and so I think he really understood the scaling laws kind of internally about how quickly the models are improving and so he actually pushed me really hard to be like don't build for the model of today build for the model 6 months from now. Um, and so honestly for a long time quad code was not a great product and even when it was used internally I used it for maybe like 10% of my code or something like this. You know use it sometimes but it really just can't do most things cuz the model is not capable enough and then at some point we released uh set and opus 4 and I think this was maybe March of this year and the product just worked and we saw this in kind of the usage data and I saw this in my own coding. I started to be able to use it for probably like half of half of my code. And this was totally borne out because this was actually like literally 6 months after starting the project. This was the timeline. And you know at this point most of quad code is written using quad code. I think it's like 80 or 90%. If you look at teams at anthropic, there's some teams that you know like 90% of their code is written using quad code. Um this is not just our team. And if you look at the impact on productivity even though anthropic has tripled I think since the start of the year uh productivity per engineer measured in you know like poor cost we were talking about this before has grown like almost 70% per engineer because of quad code and so you know like as a product person I usually think a step ahead and I think being at a lab you have to actually think kind of differently you have to think a step ahead um not two steps ahead um but also you have to be really aware of the model and kind of the exponential potential that we're on. + +[`1:12:57`](https://youtu.be/AmdLVWMdjOk?t=4377) Did you see the recent interview with Karpathy? + +[`1:12:59`](https://youtu.be/AmdLVWMdjOk?t=4379) I haven't had a chance to watch it yet. + +[`1:13:02`](https://youtu.be/AmdLVWMdjOk?t=4382) Okay. So, one thing that he said in the podcast was kind of like a you know pushing back a little bit because um basically vibe coding although it has a lot of miraculous results because of what it can generate there's also a lot of like he said like slop or you know there's like some drawbacks. So I'm curious like how do you think about that when the model produces um a lot of code but maybe it's not exactly how you'd like it or maybe the end result has some non-obvious problems with it. AI coding is a tool like every other tool that we use and you have to learn how to use it. So I think one of the most you know Karpathy obviously like he knows how to code. I think a lot of people that are new to this kind of tool, they tend to just ask it to do stuff that's a little bit too big or they hold a different bar for the model's code versus their own code. Um, and so something that I do for the team is for the quad code team, we have the same exact bar regardless of whether the code was written by the model or by a human. And so if the code sucks, we're not going to merge it. It's the same exact bar and you just ask the model to improve the code and and make it better. I think there's also kind of different ways of wielding these tools. Sometimes you want to vibe code. Uh, and this is really important for throwaway code and prototypes, code that's not in the critical path. And you know, I do this all the time, but it's it's definitely not the thing you want to do all the time. Um, because you want maintainable code sometimes. Um, you want to be very thoughtful about every line sometimes. So the way the the problem depending on the problem, you want a a different approach. And so, you know, there's like a set of approaches that I that I'll use. Like sometimes I'll vibe code stuff. Um, this is actually quite rare. It's actually mostly for like prototypes and things like that that are throwaway code. Usually I pair with a model to make to to write code. And so first we align on a plan, you know. So this is like shift tab in quad code to get into plan mode. And first the the model will make a plan, then I'll see the code, and then I I might ask it to improve the code or clean it up or so on. But it's a very involved process. I'm pairing with the model. We're working together to to write this code. And then sometimes I'll still write the code by hand. So you know there's some parts of our core query loop where I have very strong opinions about like you know things like the names of parameters or kind of like on which particular line of code is um some some code is and so for this I'll still write it by hand. I think the the thing though is the models I think are still overall not great at coding. I think there's still so much room to improve and this is the worst it's ever going to be. But it's just insane to me to think a year back where the state of AI coding was, you know, like type ahead and it's just a completely different world. And you sort of think about like where this is headed and kind of what's about to happen and what this looks like over the next few months and few years. And yeah, I think for me what keeps me really excited about it is just having the context about this trajectory that we're on. When people hear cloud code, they think about coding, but um there's many use cases outside of just software engineering like querying data for like data scientist. What are your thoughts when you think of cloud code for everything? It was the craziest thing when I walked in. I remember walking into the office like maybe it was like 6 months ago or something and our data scientist Brandon had cloud code up on his computer. He like sits next to us and I'm like, "Dude, what are you doing? Are you like trying it out?" And he's like, "No, no, I'm like it's like doing my work." I was like, "What?" So he like he figured out how to like use a terminal and like how to install Node.js and then he installed quad code and then it was writing a bunch of SQL and like doing analysis for him. And now when I walked by kind of the the the data scientists that sit next to us, every person has like a bunch of cloud codes up at the same time. It's not just one anymore. And they're doing all sorts of stuff. They're like writing SQL and you know kind of crunching data. Um they're writing DBT pipelines and they're writing code. Um, so I think there's all these applications outside of coding and it's just so cool to see how people are are using this for all sorts of stuff and there's even like totally nontechnical users like half of our sales team at Anthropic uses quad code to do their work like they they can like connect it to Salesforce and they can connect it to different data sources and you know like they can do their work this way. So it it's just so cool to see this is not how we designed it. This is not the intent. When I hear cloud code, I also think of Codeex, one of the biggest competitors. And I'm curious, what are your thoughts on the competition with Codeex and OpenAI? What does Cloud Code do better? Um, and also I'm curious like the stickiness of these AI products like, you know, what keeps people in cloud code versus um Codeex for instance. + +[`1:17:46`](https://youtu.be/AmdLVWMdjOk?t=4666) You know, I'm not totally sure. I don't personally, I don't really use the other products. [laughter] + +[`1:17:51`](https://youtu.be/AmdLVWMdjOk?t=4671) Okay. Okay. For me, you know, like the thing I tell the team is like it's so easy to get sidetracked by, you know, looking at competitors. And I think this is something that I saw that big companies fall into this failure mode a lot where because there's so many competitors and it's so easy to see the thing you could build by just, you know, copying it. It's a little bit harder to come up with novel ideas and things that solve the user need better. And so the thing that I try really hard to do and the thing that I nudge our team to do is don't get sidetracked by all these other you know products there's always going to be a lot and the more there are the bigger a sign of success that is for us and the thing we stay laser focused on is solving our problems and solving anthropic researchers problems and solving our users problems. Coming to the end of the conversation I just want to ask a few career reflections. Um, one thing I was curious about when I was looking is that um, you didn't have a CS degree or a computer science degree and you've, yeah, you've become such a strong software engineer and so I was curious is there any part in your career where you know it might have held you back in any way or do you think it's not necessary or relevant? + +[`1:19:05`](https://youtu.be/AmdLVWMdjOk?t=4745) Yeah, I studied economics and I actually dropped out to to startups. Um, you know, for me, anything that you do, you learn on the job and I think programming is just such a practical skill. I couldn't imagine, you know, the kinds of things you learn in school. And like, you know, if you're if you're like in a data structures class or something, you're like running this, but you haven't like built a product, how is it relevant at all? Um, so I don't know. I think my recommendation would be to people like learn coding practically. It's a very practical skill. And then if you want to go back and learn the theory after, go do that. Um, but personally, I've never felt like it it's held me back at all. + +[`1:19:44`](https://youtu.be/AmdLVWMdjOk?t=4784) What about productivity tips? So, I saw that you said you work roughly 9 to 6 every day and you only type with two fingers, [laughter] but your output is ridiculous. I mean, you have all these side projects and of course, your main stuff's no joke. So, what's your top productivity tips or how do you maintain that? Yeah, I think I think nowadays my tips are very different than what I would have said a couple years ago. Nowadays, the tip is just learn how to use quad code and learn how to run a bunch of quad codes to do stuff like um you know we launched plugins like a couple weeks ago and Daisy who's one of the the the engineer that built it she just had her quads like set up a sauna board make a tasks and then she had a swarm of like 20 clouds just like build plugins over the weekend and uh you know she ran it in like a docker container dangerous mode and it was done after a couple days. Um and this is the kind of thing that is the future of engineering. Um, and I think nowadays when we talk about tips for productivity, it's learn how to use claude in order to automate toil and also how to use a bunch of quads together to to do uh work. So you're kind of orchestrating instead of manually writing code. Um, I think years ago my tips would have been really different. It would have been a lot more prosaic than that, you know, like about like blocking off time and and things like this. + +[`1:21:03`](https://youtu.be/AmdLVWMdjOk?t=4863) Yeah, it's it's interesting with cloud code. I wonder what that does for you know the famous um like maker schedule versus like manager schedule. It feels like what you just said is that software engineers becoming more like a manager style of working where you got a fleet of these cloud codes and you're not you don't need deep focus to move forward. You need context switching across like 20 different things. Um so do you no longer have big focus blocks for coding or what are your thoughts on that? not as much. I tend to code on the weekends also. Um so I love the quiet time. Um but yeah, otherwise I'll kind of start every morning I open Quad Code and um you know like the mobile app. It's like there's like a code tab in Quad now. We we just launched this this week, but we've been kind of using it for a while. And so every morning I wake up and I start a few agents to just like start my code for the day. And it's crazy because I if you'd asked me like 6 months ago if this is how I would code, I would be like, "No, are you like are you crazy? Like how can you code in this way?" But it actually works. like this is here and it works and this is how I write a lot of my code now. And I'll I'll start a few agents then you know when I get to a computer I'll kind of check in on the status. Sometimes I'll just merge it if the code looks good. Sometimes I'll like pull it locally and kind of teleport to to edit a little bit. Um but yeah and and I think like you're going to talk to Fiona later and I think for her from what she told me she hasn't coded in you know like a decade but she's writing code like multiple times a week now because as a manager even though her schedule was insane uh she can still use the mobile app and she can use web and you know she can still open a terminal to just kind of write write code for her. Um, so yeah, it's it's just crazy like we get to live through this transition where the thing that we do and like the thing that I grew up on, it's just totally changing and yeah, it's just so cool. Like it's becoming accessible to everyone. + +[`1:23:00`](https://youtu.be/AmdLVWMdjOk?t=4980) And then last question for you is um knowing everything that you know now in your career, if you could go back to yourself when you just entered the industry and give yourself some advice, what would you say? Just use common sense. [laughter] [gasps] I think there's a lot of stuff in a especially in big companies that pulls you away from common sense. There's a lot of this like organia. Things are this way because they have been this way. There's a lot of misaligned incentives. There's also a lot of good things, but there's the these things also. So, it it's just really important to use common sense for this. And you know, early on in my career, I was kind of starting a bunch of startups and worked at a lot of startups. And I think there too, it's the same thing. Kind of use common sense to figure out what the market wants and what users want to build it. So yeah, just like trust yourself and and develop your common sense. + +[`1:23:53`](https://youtu.be/AmdLVWMdjOk?t=5033) Awesome. Well, thank you so much, Boris, for your time. Really appreciate it. + +[`1:23:57`](https://youtu.be/AmdLVWMdjOk?t=5037) Yeah. Thanks. Thanks for listening to the podcast. I don't sell anything or do sponsorships, but if you want to help out with the podcast, you can support by engaging with the content on YouTube or on Spotify. If you want to drop a review, that'll be super helpful. And if there's any guests that you want to bring on to, please let me know. I feel like sourcing very senior IC's, there's no wellstudied list out there on Google that I can just search this up. So, if there's someone in your org or at your company who you really look up to and you want to hear their career story, let + +--- + +## Sources + +- [Boris Cherny (Creator of Claude Code) On What Grew His Career — Ryan Peterman — YouTube](https://youtu.be/AmdLVWMdjOk) +- [Ryan Peterman on YouTube](https://www.youtube.com/@RyanPetermanPlus) diff --git a/videos/claude-boris-y-combinator-17-feb-26.md b/videos/claude-boris-y-combinator-17-feb-26.md new file mode 100644 index 0000000..2776bc1 --- /dev/null +++ b/videos/claude-boris-y-combinator-17-feb-26.md @@ -0,0 +1,340 @@ +# Inside Claude Code With Its Creator Boris Cherny — Y Combinator + +Transcript of the interview with Boris Cherny ([@bcherny](https://x.com/bcherny)), creator of Claude Code, on the Y Combinator Light Cone podcast, published February 17, 2026. + + + + + + +
← Back to Claude Code Best PracticeClaude
+ +--- + +## Video Details + +- **Guest:** Boris Cherny (Creator of Claude Code) +- **Host:** Y Combinator (The Light Cone) +- **Published:** February 17, 2026 +- **YouTube:** [Watch on YouTube](https://youtu.be/PQU9o_5rHC4) + +--- + +## Transcript + +[`0:01`](https://youtu.be/PQU9o_5rHC4?t=1) At Enthropic, 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 to founders that are building on LLM. Just try to think about like what is that frontier where the model is not very good at today cuz it's going to get good at it. All of Quad Code has just been written and rewritten and rewritten and rewritten over and over and over. There is no part of Quad Code that was around 6 months ago. You try a thing, you give it to users, you talk to users, you learn, and then eventually you might end up at a good idea. Sometimes you don't. Are you also in the back of your mind thinking that maybe like in 6 months you won't need to prompt that explicitly? Like the model will just be good enough to figure out on its own? + +[`0:36`](https://youtu.be/PQU9o_5rHC4?t=36) Maybe in a month, + +[`0:38`](https://youtu.be/PQU9o_5rHC4?t=38) no more need for plan mode in a month. Welcome to another episode of the light cone and today we have an extremely special guest, Boris Churnney, the creator engineer of Claude Code. Boris, thanks for joining us. + +[`0:59`](https://youtu.be/PQU9o_5rHC4?t=59) Thanks for having me. + +[`1:00`](https://youtu.be/PQU9o_5rHC4?t=60) Thanks for creating a thing that has taken away my sleep for about 3 weeks straight. + +[`1:07`](https://youtu.be/PQU9o_5rHC4?t=67) I am very addicted to Cloud Code and uh 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 uh a lot of my friends said like something changed. + +[`1:21`](https://youtu.be/PQU9o_5rHC4?t=81) I remember for me I felt this way when I first created Quad Code and I didn't yet know if I was on to something. I kind of felt like I was on to something and then that's when I wasn't sleeping. + +[`1:28`](https://youtu.be/PQU9o_5rHC4?t=88) Yeah. + +[`1:29`](https://youtu.be/PQU9o_5rHC4?t=89) And that was just like three straight months. + +[`1:33`](https://youtu.be/PQU9o_5rHC4?t=93) This was uh September 2024. Yeah. It was like three straight months. I 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 it couldn't actually code yet." + +[`1:48`](https://youtu.be/PQU9o_5rHC4?t=108) If you look back on uh those moments to now, like what would be like the most surprising thing about this moment right now? + +[`1:54`](https://youtu.be/PQU9o_5rHC4?t=114) 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 cuz uh you know at the beginning it didn't really write code. Even in February when we G it wrote maybe like 10% of my code or something like that. I didn't really use it to write code. it wasn't very good at it. I still wrote most of my code by hand. Uh so the fact that it it actually like our bets paid off and it got good at the thing that we thought it was going to get good at because it wasn't obvious. At Enthropic, the way that we thought about it is we don't build for the model of today. We build for the model 6 months from now. And that's actually like still my advice to to founders that are building on LLM is, you know, just try to think about like what is that frontier where the model is not very good at today. um because it's going to get good at it and you just have to wait. + +[`2:39`](https://youtu.be/PQU9o_5rHC4?t=159) Going back though, but when do you remember when you first got the idea? Can you just talk us through that? Like was it some like a spark or what was even the first version of it in your mind? + +[`2:47`](https://youtu.be/PQU9o_5rHC4?t=167) You know, it's funny. It was like it was so accidental that it just kind of evolved into this. Um you know as as anthropic I think for Ant the bet has been coding for a long time and the bet has been the path to save to safe AGI is through coding + +[`3:03`](https://youtu.be/PQU9o_5rHC4?t=183) and this is this has kind of always been the idea and the way you get there is you you teach the model how to code then you teach it how to use tools then you teach it how to use computers um and you can kind of see that because the the first team that I joined at Enthropic it was called the anthropic labs team uh and it produced three products it was quadcode MCP and in 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 no one asked me to build a CLI. Um we kind of knew maybe it was time to build some kind of coding product cuz it seemed like the model was ready, but no one had yet really built the 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 cuz like no one had built this yet. And so I I started like hacking around uh and I was like, "Okay, we build a coding product. What do I have to do first? I have to understand how to use the API because I hadn't used anthropic API at that point." Um and so I I just built 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 of the time and you know for non-coders today most what what are most people using is just a chat app. So that's what I built. Uh and you know it was in a terminal. I can ask questions. I give answers. Then I think tool use came out. I just wanted to try out tool use because I I don't really understand what this is. I was like to use this is cool. Is this actually useful? Probably not. Let me just try it. + +[`4:25`](https://youtu.be/PQU9o_5rHC4?t=265) You built it in terminal just because it was the easiest way to get something up and running. + +[`4:29`](https://youtu.be/PQU9o_5rHC4?t=269) Yes. Cuz I didn't have to build a UI. + +[`4:30`](https://youtu.be/PQU9o_5rHC4?t=270) Okay. + +[`4:31`](https://youtu.be/PQU9o_5rHC4?t=271) It was just me + +[`4:32`](https://youtu.be/PQU9o_5rHC4?t=272) at that point. It was like the IDEs, Cursor, Windsurf taking off. Were you sort of under any pressure or getting lots of suggestions of, hey, like we should build this out as a plugin or as a as a fully featured ID itself? There was no pressure because we didn't even know what we wanted to build. Like the the team was just in explore mode, you know, like we we didn't we know vaguely we wanted to do something in coding, but it wasn't obvious what no one was high confidence enough. That was like my job to figure out. And so I g I gave the model uh the batch tool. That was the first tool that that I gave it just cuz I think that was literally the example in our docs. I just like took the example. It was in Python. I just ported it to TypeScript because that 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 file. So like that was cool. And then I was like, "Okay, like what can you actually do?" And and I asked her, "What music am I listening to?" He wrote some like Apple script to script my my Mac and look up the music in my music player. + +[`5:24`](https://youtu.be/PQU9o_5rHC4?t=324) Oh my god. + +[`5:26`](https://youtu.be/PQU9o_5rHC4?t=326) And this was Sauna 3.5. + +[`5:28`](https://youtu.be/PQU9o_5rHC4?t=328) And you know, like I I didn't think the model could do that. And that was my first I think ever fuel the AGI moment + +[`5:34`](https://youtu.be/PQU9o_5rHC4?t=334) where I was just like, "Oh my god, the model it just wants to use tools. That's all it wants." + +[`5:39`](https://youtu.be/PQU9o_5rHC4?t=339) That's kind of fascinating. I mean it's very kind of contrarian that clocker works so well in such an elegant simple form factor. I mean terminals have been around for a really long time and that seemed to be like a good design constraint that allowed a lot of interesting developer experiences like it doesn't feel like working. It just feels fun as a developer. I don't think about files where everything is and that came by accident almost. + +[`6:09`](https://youtu.be/PQU9o_5rHC4?t=369) Yeah, it was an accident. I remember so after the terminal started to take off internally. Um and honestly like after building this thing I think like 2 days after the first prototype I started giving it to my team just for dogfooting cuz 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 who's another engineer he he just like had quad code on his computer and he was like using it to code. I was like I was like what what are you what are you doing? Like this thing isn't ready. It's just a prototype. But yeah, it 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, something like that in 2024. Um Dario asked and he was like, "The us chart internally like the the Dow chart is like vertical. Are you like forcing engineers to use it? Like why are you mandating them?" + +[`7:00`](https://youtu.be/PQU9o_5rHC4?t=420) And I was just like, "No, no, we didn't. We I just like posted about it and they they' just been like telling each other about it." Honestly, it was it was just accidental. We we started with the CLI because it was the cheapest thing and it just kind of stayed there for a bit. + +[`7:13`](https://youtu.be/PQU9o_5rHC4?t=433) So in that 2024 period, what how were the engineers using it? Were they sort of shipping code with it yet or were they using it in a different way? + +[`7:19`](https://youtu.be/PQU9o_5rHC4?t=439) The model is not very good at coding yet. I I was using it personally for automating git. Um I think at this point I I probably forgotten most of my git because cloud code has just been doing it for so long. But yeah, like automating uh bash commands that 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 were some early signs of this. I think the first use case was actually writing unit tests because it's a little bit lower risk and the model was still pretty bad at it + +[`7:46`](https://youtu.be/PQU9o_5rHC4?t=466) but people were were were kind of figuring it out and and they were figuring out how to use this thing. + +[`7:51`](https://youtu.be/PQU9o_5rHC4?t=471) Um 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 latent demand. Um and the just every bit of this product is built through latent demand after their initial CLI. Uh 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 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 quantumd and kind of the scaffolding is an example of that and really I think that's why we stayed in the CLI is because we felt there is no UI we could build that would still be relevant in 6 months because the model was improving so quickly + +[`8:50`](https://youtu.be/PQU9o_5rHC4?t=530) 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 MD + +[`9:03`](https://youtu.be/PQU9o_5rHC4?t=543) okay so I I checked this before we came so my my cloud has two Um, one is, uh, there it's just two lines. So, the first line is whenever you put up a PR, enable automerge. Um, so as 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, post it in our internal team stamps channel. Uh, just so someone can stamp it and I can get unblocked. Uh, and the idea is every other instruction is in our quadmd 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 Claude 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. + +[`9:52`](https://youtu.be/PQU9o_5rHC4?t=592) Do you have to like compact the Claude MD? Like I 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? + +[`10:03`](https://youtu.be/PQU9o_5rHC4?t=603) So our quadm is actually pretty short. I think it's like couple thousand tokens maybe something like that. Um if if you hit this my recommendation would be delete your quadmd and just start fresh. + +[`10:11`](https://youtu.be/PQU9o_5rHC4?t=611) Interesting. + +[`10:12`](https://youtu.be/PQU9o_5rHC4?t=612) I think a lot of people like they try to overengineer this right and 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 quadd and then you know the model is getting off track, it does the wrong thing. That's when you kind of add back a little bit at a time. And what you're probably going to find is with every model, you have to add less and less. For me, I consider myself a pretty average engineer to be honest. Like I don't use a lot of fancy tools. Like I I don't use like Vim. I use, you know, VS Code because it's simpler. Um I don't really + +[`10:44`](https://youtu.be/PQU9o_5rHC4?t=644) Wait, really? I would have assumed that because you built this in the terminal that you were sort of like a dieh hard ter terminal like Vim Vim only person you know screw those VS code people you know + +[`10:53`](https://youtu.be/PQU9o_5rHC4?t=653) well we have people like that on the team there's you know like Adam Wolf for example he's he's on the team he's like you will never take Vim for my cold dead hands like yeah so there's definitely a lot of people like that on the team and this is one of the things that I learned early on is every engineer likes to hold their dev tools differently they like to use different tools there's just no one tool that works for everyone but I think also this is one of the things that makes it possible for 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 Vim 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 it'll do all this stuff + +[`11:30`](https://youtu.be/PQU9o_5rHC4?t=690) 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 shorter I mean every user probably has a for an opinion like how do you make those sorts of decisions? + +[`11:47`](https://youtu.be/PQU9o_5rHC4?t=707) What What's your opinion? Is it is it too verbose right now? + +[`11:50`](https://youtu.be/PQU9o_5rHC4?t=710) Oh, I love the verbosity cuz 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. + +[`12:07`](https://youtu.be/PQU9o_5rHC4?t=727) This is something that we probably change pretty often. Um, 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 these giant long bash commands, I don't actually care. And then I gave it to anthropic employees for a day and everyone just revolted. I want to see my dash because it 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 this, you actually do want to see it. We recently hit the hid the file reads and uh file searches. So you'll notice instead of saying, you know, like read food.md said, you know, like read one file, search searched one pattern. And this is something I think we could not have shipped six months ago because the model just was not ready. It would have, you know, it still read the wrong thing pretty often. As a user, you still had to be there and kind of catch it and debug it. But nowadays, I just 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. Um, but then we shipped it. Uh, we dog fooded it for like a month and then people on GitHub didn't like it. Uh so there was a big issue where people like no like I want to see the details and that was really great feedback. Um and so we added a new verbose mode and so that's just like in slash config you can enable verbose mode and if you want to see all the file outputs you can continue to do that and then I posted on the issue and people still 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. Um and so we just like iterated more and more and more to get that really good and to make it the thing that people want. I'm amazed like how much I enjoy uh fixing bugs now. And then all you have to do is uh 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 it'll look at your production DB for you. It's like this is insane. Bug fixing is just going to sentry copy markdown. You know pretty soon it's just going to be straight MCP. It's like an autobug fixing like and test making sort of uh what's the new uh term they call it like a making a startup factory. Oh yeah. + +[`14:10`](https://youtu.be/PQU9o_5rHC4?t=850) 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 a real human being has to look at code uh that's bad. + +[`14:30`](https://youtu.be/PQU9o_5rHC4?t=870) Yeah. Yeah. Yeah. + +[`14:31`](https://youtu.be/PQU9o_5rHC4?t=871) Which is fascinating. + +[`14:32`](https://youtu.be/PQU9o_5rHC4?t=872) I think like Dan Chipper talks about this a lot as kind of when whenever you see the model make a mistake try to put in the quadmd try to put it in like skills or something like that so it's reusable. But I I think there's this meta point that I actually struggle with a lot. And I 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. + +[`14:58`](https://youtu.be/PQU9o_5rHC4?t=898) And I'm just constantly surprised by this. Like for example, there was a we had like a memory leak and we were trying to debug it. Um and by the way, like Jared Sumar has just been on this crusade killing all the memory leaks and it's just been amazing. But before Jared was on the team, I had to do this and there was this memory leak. I I was trying to debug it. And so I I took a heap dump. I opened it in DevTools. I was looking through the profile. Then I was looking through the code and I 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 leak. Can you like run this?" 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 leak faster than I did. And this is just something I have to constantly relearn because my brain is still stuck somewhere six months ago at times. + +[`15:45`](https://youtu.be/PQU9o_5rHC4?t=945) So what would be some advice for technical founders to really become maximalists 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 uh I don't know maybe just like humility like I feel like engineers as a discipline we've learned to have very strong opinions and senior engineers are kind of rewarded for this in my old job at a big company when I hired like architects and this kind of a type of engineer you look for people that have a lot of experience and really strong opinions but it actually turns out a lot of this stuff just isn't relevant anymore and a lot of these opinions should change because the model is getting better um so I think actually the biggest skill is people that can think scientifically and can just think from first principles. + +[`16:40`](https://youtu.be/PQU9o_5rHC4?t=1000) How do you screen for that when you try to hire someone now for for your team? + +[`16:43`](https://youtu.be/PQU9o_5rHC4?t=1003) I sometimes ask about what's an example of when you're wrong. It's a really good one. You know, some of these like classic behavioral questions like not even coding questions I think are quite useful because you can see if people can recognize their mistake in hindsight, if they can claim credit for the mistake and if they learn something from it. And I think a lot of these like very senior people especially there there are some founder types like this but I think founders in particular are actually quite good at it. Um but other people sometimes will never really take uh they'll never take the blame for a mistake. But I don't know like for me personally I'm wrong probably half the time. Like half my ideas are bad and you just have to try stuff and you know you try a thing you give it to users you talk to users you learn and then eventually you might end up at a good idea. Sometimes you don't. And this is the skill that I think in in the past was very important for founders, but now I think it's very important for every engineer. + +[`17:34`](https://youtu.be/PQU9o_5rHC4?t=1054) Do you think um you would ever hire someone based on the uh claude code transcript of uh them working with the agent cuz we're actively doing that right now. We just added uh just as a test like you can upload a transcript of you coding a feature with cloud code or codeex or whatever it is. Personally, I think that like it's going to work. I mean, you can figure out uh 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 there are tests or you know, all of these different things that, + +[`18:11`](https://youtu.be/PQU9o_5rHC4?t=1091) 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 uh a spiderweb graph, you know, like in those video games like NBA 2K. It's like, oh, this person's really good at shooting or defense. It's like you could imagine a spiderweb graph of like, you know, someone's claude code skill level. + +[`18:31`](https://youtu.be/PQU9o_5rHC4?t=1111) Yeah. What would what would the skills be? What would be those? + +[`18:34`](https://youtu.be/PQU9o_5rHC4?t=1114) I mean, I think it's like systems testing must be like user behavior. I mean, there's got to be a design part like product sense maybe also just like automating stuff. Mhm. My favorite thing in CloudMD uh for me is I have a thing that says for every plan decide whether it's overengineered, underengineered, or perfectly engineered and why. + +[`18:54`](https://youtu.be/PQU9o_5rHC4?t=1134) I think this is something that we're trying to figure out, too, cuz I I think uh when I look at engineers on the team that I think are the most effective, there's essentially two, it's very biodal. Um there's one side where it's extreme specialists. Um and so like I named Jared before, like he's a really good example of this and kind of the bun team is a really good example. Just hyper 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 generalists and that's kind of the rest of the team. And a lot of people they span like product and info or product and design um or you know like product and user research, product and business. I really like to see people that just do weird stuff. I think that's one of these things that was kind of a warning sign in the past because it's like can these people actually build something useful? + +[`19:39`](https://youtu.be/PQU9o_5rHC4?t=1179) Um that's the limits test. Yeah, that's what must but but nowadays like for example an engineer on the team Daisy, she was on a different team and then she transferred onto our team and the reason that I wanted her to transfer is she put up a PR for Claude Code like a couple weeks after she joined or something and the PR was to add a new feature to Claude Code and then instead of just adding the feature what she did is first she put up a PR to give Claude code a tool so that it can test an arbitrary tool and verify that that works. And then she put up that PR and then she had 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 is just so interesting because not a lot of people get it yet. You know, like we use the Quad agents SDK to automate pretty much every part of development. It automates code review, security review. Uh it labels all of our issues. It shephards things to production. It does pretty much everything for us. But I think externally I'm seeing a lot of people start to figure this out, but it's actually taken a while to figure out how do you use LMS in this way? How do you use this new kind of automation? So it's kind of a new skill. + +[`20:42`](https://youtu.be/PQU9o_5rHC4?t=1242) I guess one of the uh funnier things that I've been having office hours with various founders about is um you have like sort of the visionary founder who has like the idea they've like built this like crystal palace of the product that they want to build. they've totally loaded in their brain, you know, who the user is and what they feel and what they're motivated by and then they're sitting in claude code and they can do like, you know, 50x work and then but they have engineers who work for them who like don't have the, you know, crystal memory palace of like the platonic ideal of the product that the pro 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, you know, trying to blast it out of their brain. What's the nature of like teams like that? You know, it seems like that's almost a stable configuration. Like you're going to have the visionary who like now is unleashed, but you know, maybe going back to the top of it, like I'm experiencing this right now. I was like, "Oh, well, I'm only a solo person and you know, I need to eat and sleep and I have, you know, a whole job. It's like, how am I going to do this?" You know, + +[`21:52`](https://youtu.be/PQU9o_5rHC4?t=1312) you know, like we just launched 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. + +[`21:59`](https://youtu.be/PQU9o_5rHC4?t=1319) What's the vision for cloud teams? + +[`22:01`](https://youtu.be/PQU9o_5rHC4?t=1321) Just collaboration. It's like there's this whole new field of like agent top apologies that people are exploring. Like what are the ways that you can configure agents? There's this one sub idea which is uncorrelated context windows. And the idea is just multiple agents, they have fresh context windows that aren't essentially polluted with each other's context or their own previous context. And if you throw more context at a problem, that's like a form of test time compute. Um, and so you just get more capability that way. And then if you have the right topology on top of it, so the agents can communicate in the right way, they're laid out in the right way, then they can just build bigger stuff. And so Teams is kind of like one idea. There's a few more that are coming pretty soon. Um, 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. It just ran for like a few days. There wasn't really human intervention. And plugins is pretty much in the form that it was when when it came out. + +[`22:54`](https://youtu.be/PQU9o_5rHC4?t=1374) 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? + +[`23:04`](https://youtu.be/PQU9o_5rHC4?t=1384) Yeah. an engineer on the team just gave uh gave Quad a spec and um told Quad to use a Asauna board and then Quad just put up a bunch of tickets on a sauna and then spawned a bunch of agents and the agent started picking up tasks. The main quad just gave it instructions and they all just figured it out + +[`23:21`](https://youtu.be/PQU9o_5rHC4?t=1401) like independent um agents that didn't have the context of the bigger spec. Right. + +[`23:25`](https://youtu.be/PQU9o_5rHC4?t=1405) Right. If you if you think about the way that uh you know like how our 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 uh sub agents cuz 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 + +[`23:45`](https://youtu.be/PQU9o_5rHC4?t=1425) and that that's all it is and I think probably if you look at most agents they're launched in this way + +[`23:49`](https://youtu.be/PQU9o_5rHC4?t=1429) 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. + +[`24:11`](https://youtu.be/PQU9o_5rHC4?t=1451) For weird scary bugs, I try to uh fix bugs in plan mode and then it seems to use the agents to sort of search everything. Whereas like when you're just trying to do it in line, it's like, okay, I'm going to do like this one task instead of search wide. This is something I do all the time too. I I just say if the if the test seems kind of hard, this kind of research test, I'll calibrate the number of sub aents I ask it to use based on the difficulty of the task. + +[`24:33`](https://youtu.be/PQU9o_5rHC4?t=1473) So if it's like really hard, I'll say like use three or maybe five or even 10 sub aents, research in parallel and then see what they come up with. + +[`24:40`](https://youtu.be/PQU9o_5rHC4?t=1480) I'm curious. So then why don't you put that in your clawed MD file? + +[`24:44`](https://youtu.be/PQU9o_5rHC4?t=1484) It's kind of case by case, you know, like quadm 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 quad MD. But otherwise, you don't have to put everything there. You can just prompt quad. + +[`24:56`](https://youtu.be/PQU9o_5rHC4?t=1496) Are you also in the back of your mind thinking that maybe like in six months, you won't need to prompt that explicitly? Like the model will just be good enough to figure out on its own. + +[`25:05`](https://youtu.be/PQU9o_5rHC4?t=1505) Maybe in a month. + +[`25:07`](https://youtu.be/PQU9o_5rHC4?t=1507) No more need for plan mode in a month. + +[`25:07`](https://youtu.be/PQU9o_5rHC4?t=1507) Oh my god. + +[`25:09`](https://youtu.be/PQU9o_5rHC4?t=1509) I think plan mode probably has a limited lifespan. + +[`25:11`](https://youtu.be/PQU9o_5rHC4?t=1511) Interesting. + +[`25:12`](https://youtu.be/PQU9o_5rHC4?t=1512) That's some 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 uh we've started experimenting with this because quad code can now enter plan mode by itself. I don't know if you've you guys have seen that. + +[`25:26`](https://youtu.be/PQU9o_5rHC4?t=1526) Yeah. + +[`25:28`](https://youtu.be/PQU9o_5rHC4?t=1528) 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. + +[`25:44`](https://youtu.be/PQU9o_5rHC4?t=1544) That's all it is. You can you can actually just say that. + +[`25:47`](https://youtu.be/PQU9o_5rHC4?t=1547) Yeah. So it sounds like a lot of the feature development for clock code is very much a what we talk about a YC talk to your users + +[`25:54`](https://youtu.be/PQU9o_5rHC4?t=1554) and then you come and implemented it. It wasn't the other way that you had this master plan and then implemented all the features. + +[`25:59`](https://youtu.be/PQU9o_5rHC4?t=1559) Yeah. Yeah. I mean that that's all it was like plan mode was we saw users that that were like hey quad come up with an idea plan this out 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 that they were asking Claude to write, but the common dimension was do a thing without coding yet. And so literally like this was like Sunday night at 10 p.m. I was I was just like looking at GitHub issues and kind of seeing what people were talking about and looking at our internal Slack feedback channel and I just wrote this thing in like 30 minutes and then uh shipped it that night. It went out Monday morning. That was plan mode. So do you mean that there will be no need for plan mode to in the sense of I'm worried that the model's 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. + +[`26:49`](https://youtu.be/PQU9o_5rHC4?t=1609) I kind of think about it in terms of like kind of increasing model capabilities. So maybe 6 months ago a plan was insufficient. So you get Claude to make a plan. Let's say even with plan mode you still have to kind of sit there and babysit cuz it can go off track. Nowadays what I do is probably 80% of my sessions I say I say plan mode has a limited lifespan but I I'm a heavy plan mode user. Um I probably 80% of my sessions I start in plan mode and claude will you know it'll start it'll start making a 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 code tab and then I just start a bunch of tabs there and they all start in plan mode probably know like 80% of the time. Once the plan is good, and sometimes it takes a little back and forth, they just get clawed 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. + +[`27:53`](https://youtu.be/PQU9o_5rHC4?t=1673) The next step is Claude just speaks to your users directly. Yeah, it just bypasses you entirely. + +[`27:59`](https://youtu.be/PQU9o_5rHC4?t=1679) It's funny. This is actually the current stuff for us. Our quads actually like they talk to each other. They talk to our users on Slack, at least internally pretty often. Um, my quad will like tweet once in a while. + +[`28:08`](https://youtu.be/PQU9o_5rHC4?t=1688) No way. + +[`28:11`](https://youtu.be/PQU9o_5rHC4?t=1691) Um, but I actually like delete it. It's just like it's a little like cheesy. Like I don't love the tone. + +[`28:16`](https://youtu.be/PQU9o_5rHC4?t=1696) What does it want to tweet about? + +[`28:17`](https://youtu.be/PQU9o_5rHC4?t=1697) Sometimes it'll just like respond to someone cuz I always have like co-work in the background and it's like it's the co-work that really loves to do that because it likes using a browser. + +[`28:25`](https://youtu.be/PQU9o_5rHC4?t=1705) That's funny. A a really common pattern is I ask Quad to build something. It'll look in the codebase. Uh it'll see some engineer touch something in the git flame and then it'll message that engineer on Slack. Um just like asking a clarifying question and then once it gets answer back, it'll keep going. + +[`28:40`](https://youtu.be/PQU9o_5rHC4?t=1720) 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? + +[`28:49`](https://youtu.be/PQU9o_5rHC4?t=1729) So I think some of these are pretty are pretty basic, but I think they're even more important now than they were before. Um, so one example is latent demand. Like I mentioned it a thousand times for me. It's just like the single biggest idea in product. It's a it's a thing that no one understands. It's a thing I certainly did not understand my first few startups. And 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 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 can kind of figure this out. + +[`29:30`](https://youtu.be/PQU9o_5rHC4?t=1770) That's what you mean by plan mode was latent demand that people were already like I don't know had their clawed chat window open in a browser and were like talking to it to figure out like the spec and and what it should do. And now that like pi mode just became that you just do it in claw code. + +[`29:45`](https://youtu.be/PQU9o_5rHC4?t=1785) Yeah. Yeah, that's it. Some 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 like I I'll say like hi so it's not and then um I'll I'll just see kind of like how they're using quad code. Um and this is also just something I saw a lot um but it also came up in GitHub issues like people were talking about it. It seems like so 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 swore multiple agents like do you think there's going to be a new a need for a different UI on top of it? + +[`30:19`](https://youtu.be/PQU9o_5rHC4?t=1819) It's funny if you asked me this a year ago I would have said the terminal has like a threemonth lifespan and then we're going to move on to the next thing. Uh 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 quadcode 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 um 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 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 of the CLI. So, I'm probably not the person to forecast that. + +[`30:58`](https://youtu.be/PQU9o_5rHC4?t=1858) What about like your advice to DevTool founders? Like, someone's building a DevTool company today. Should they just like be building for engineers and humans or should they be thinking more about like what Claude going to think and want and build for sort of like the agent? + +[`31:13`](https://youtu.be/PQU9o_5rHC4?t=1873) 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 I realized like this thing just wants to use tools. It just wants to interact with the world. And how 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 startup, I would 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? + +[`31:54`](https://youtu.be/PQU9o_5rHC4?t=1914) 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 y combinator.com/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 heav 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? + +[`32:27`](https://youtu.be/PQU9o_5rHC4?t=1947) Yeah, something like that. + +[`32:29`](https://youtu.be/PQU9o_5rHC4?t=1949) 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 it's the right thing and it feels like clot code in the terminal has a lot of parallels with TypeScript at the beginning. + +[`32:47`](https://youtu.be/PQU9o_5rHC4?t=1967) 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 cuz 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. + +[`33:06`](https://youtu.be/PQU9o_5rHC4?t=1986) It was like very strongly typed. + +[`33:08`](https://youtu.be/PQU9o_5rHC4?t=1988) Yeah, it was very strongly and and the idea was like when you know like when Joe Pamer 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 untyped JavaScript code bases. We have to get types in there, but we're not going to get engineers to change that 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, right? They're going to write code the way they're going to write it. They're they're going to use reflection and they're going to use mutation and they're going to use all these features that traditionally are very very difficult to type. + +[`33:38`](https://youtu.be/PQU9o_5rHC4?t=2018) They're a very unsafe type to any strong functional programmer. + +[`33:41`](https://youtu.be/PQU9o_5rHC4?t=2021) That's right. 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 built a type system around this. 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. It purely came out of the practice of observing people and seeing how JavaScript programmers want to write code. And so you know for for quad code it there there are some ideas that are kind of similar in that you know like you can use it like a Unix utility. You can pipe into it. You can pipe out of it. Um in some ways it is kind of rigorous in this way but in in almost every other way it's just the tool that we wanted. like I I build a tool for myself and then the team builds the tool for themselves and then for anthropic 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 codebases are in Haskell which is more academic and there's tons of them now on TypeScript because it's way more practical + +[`34:42`](https://youtu.be/PQU9o_5rHC4?t=2082) right + +[`34:43`](https://youtu.be/PQU9o_5rHC4?t=2083) which is interesting. Yeah, it is interesting, right? It's like TypeScript solves a problem. + +[`34:47`](https://youtu.be/PQU9o_5rHC4?t=2087) 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. + +[`34:58`](https://youtu.be/PQU9o_5rHC4?t=2098) When I first started building it, you know, like I I did front-end engineering for for a while. So, and I was also like a, you know, I'm I'm sort of like a hybrid, like I do like design and user research and, you know, write code and all this stuff. And we love hiring engineers that are like this. Um, 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 um you know are are going to be working in a terminal. And I think just the delight is so important. And I feel like at YC this is something you talk about a lot, right? It's like build a thing that people love. If the product is useful but you don't fall in love with it, that's not great. Um so it kind of has to do both. Designing for the terminal honestly has been hard, right? It's like uh 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 this stuff you can't do, and there's all these very hard trade-offs. 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. + +[`35:54`](https://youtu.be/PQU9o_5rHC4?t=2154) Oh, how do you do that in cloud code? I've been trying to figure out how to do this. + +[`35:58`](https://youtu.be/PQU9o_5rHC4?t=2158) 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 trade-off is you have to virtualize scrolling and so there's all these weird trade-offs because like 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 like the 1960s or whatever. + +[`36:16`](https://youtu.be/PQU9o_5rHC4?t=2176) Yeah. It feels like BBS's. It's like a BBS door game. + +[`36:17`](https://youtu.be/PQU9o_5rHC4?t=2177) Yeah. + +[`36:18`](https://youtu.be/PQU9o_5rHC4?t=2178) Oh my god. + +[`36:19`](https://youtu.be/PQU9o_5rHC4?t=2179) That's like that's like a great compliment. Yeah. Yeah. Like it should feel like you're discovering + +[`36:24`](https://youtu.be/PQU9o_5rHC4?t=2184) Lord of the Red Dragon. It's fantastic. Oh my god. + +[`36:26`](https://youtu.be/PQU9o_5rHC4?t=2186) Yeah. But we have we've had to just like discover all these kind of UX principles for building the terminal cuz 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, they use like ed curses and they have all these like 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 had 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 the next one. try it, didn't feel good, move on to the next one. Uh, and this was like sort of one of the amazing things about quad code, right? Is like you can write these prototypes and 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. + +[`37:14`](https://youtu.be/PQU9o_5rHC4?t=2234) Whereas in the past, what you would have had to do is like wen to use origami or framer or something like this. You built like maybe three prototypes, it took like two weeks. It just took much much longer. + +[`37:24`](https://youtu.be/PQU9o_5rHC4?t=2244) 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 lets us build a product that's like joyous and that people like to use. + +[`37:38`](https://youtu.be/PQU9o_5rHC4?t=2258) Boris, you had other advice for for builders and we kept interrupting you because we have so many questions, but + +[`37:45`](https://youtu.be/PQU9o_5rHC4?t=2265) I would say um 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 uh don't build for the model of today, build for the model of 6 months from now. This is like sort of weird, right? Because like you can't find PMF if the product doesn't work. But actually this is the thing that you should do because otherwise what will happen is you spend a bunch of work you find PMF for the product right now and then you're just going to get leaprogged by someone else um 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 6 months from now. I think the second thing is um you know actually in the in the quad code where in the quad code area where we sit we have a framed copy of the bitter lesson on the wall. Um and this is this like rich sutton uh I like everyone should read it if if you haven't uh and the idea is the more general model will always be the more specific model and there's a lot of corlaries to this but essentially what it boils down to is never bet against the model. Uh, and so this is just like a thing to that that we always think about where we could build a feature into cloud code. We could make it better as a product and we call this scaffolding. That's all this code that's not the model itself. But we could also just wait like a couple months and the model can probably just do the thing instead. Um, and there's always this trade-off, right? It's like engineering work now and you can kind of extend the capability a little bit, maybe 10 20% or whatever in whatever domain on this like, you know, like the spider chart of what you're trying to extend. Um, or you can just wait and the next model will do it. So just always always think in terms of this trade-off where where do you actually want to invest and assume that whatever the scaffolding is it's just tech. + +[`39:18`](https://youtu.be/PQU9o_5rHC4?t=2358) How often do you rewrite the code ways of uh clock code is every six months with this with this + +[`39:24`](https://youtu.be/PQU9o_5rHC4?t=2364) is there scaffolding that you've deleted because you don't need it anymore because the model just improved. + +[`39:29`](https://youtu.be/PQU9o_5rHC4?t=2369) 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 unhip tools every couple weeks. We add new tools every couple weeks. There's no part of quad code that was around six months ago. It's just constantly rewritten. + +[`39:43`](https://youtu.be/PQU9o_5rHC4?t=2383) Would you say most of the code base for current cloud code is only say 80% of it is only less than a couple months old. + +[`39:49`](https://youtu.be/PQU9o_5rHC4?t=2389) Yeah, definitely. It might it might even be like less than Yeah, maybe like a couple months. That that feels about right. + +[`39:55`](https://youtu.be/PQU9o_5rHC4?t=2395) So it's like the life cycle of code now. That's another alpha is expecting it to be the shelf life to be just couple months. + +[`39:59`](https://youtu.be/PQU9o_5rHC4?t=2399) Yeah. + +[`40:00`](https://youtu.be/PQU9o_5rHC4?t=2400) For the best founders. + +[`40:02`](https://youtu.be/PQU9o_5rHC4?t=2402) Do you see uh Steve Yaggi's uh post about how awesome working at Anthropic is? And I think there's a line in there that says that an anthropic engineer uh currently averages 1,000x more productivity than a Google engineer at Google's peak which is really an insane number honestly like 1,000x like you know we're 3 years ago we were still talking about 10x engineers now we're talking about 1000x 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. Um, and even non-technical employees, I think like half the sales team uses quad code. Um, they they've started switching to co-work because it's a little easier to use. It has like a VM, so it's a little bit safer. But yeah, we actually we just pulled a stat and the I think the team doubled in size last year, but productivity per engineer grew something like 70%. + +[`40:54`](https://youtu.be/PQU9o_5rHC4?t=2454) It's measured by + +[`40:56`](https://youtu.be/PQU9o_5rHC4?t=2456) just like the simplest stupidest measure, pull requests. Um, but we also kind of cross check that against like commits and like uh the lifetime of commits and things like this. And since quad code came out, productivity per engineer at anthropic has grown 150%. + +[`41:07`](https://youtu.be/PQU9o_5rHC4?t=2467) Oh my god. + +[`41:10`](https://youtu.be/PQU9o_5rHC4?t=2470) Um, and this is crazy because I in my old life I was responsible for code quality at Meta. + +[`41:14`](https://youtu.be/PQU9o_5rHC4?t=2474) Um, and I was responsible for the quality of all of our code bases across every product across like you know Facebook, Instagram, WhatsApp, whatever. + +[`41:22`](https://youtu.be/PQU9o_5rHC4?t=2482) 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. + +[`41:36`](https://youtu.be/PQU9o_5rHC4?t=2496) What drove 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 uh it was all it just started to be like AI stuff at some point and uh I started to use some of these early products and uh I remember like the first couple times that I used it I was just like it just took my breath away. That was like very cheesy to say, but that was actually that was actually the feeling. Like it was just like it was amazing like as a as as a builder, I've just never kind of felt felt this feeling like using these very very early products. That was like in the quad 2 days or you know something like that. And so I I just talking started talking to friends at Labs um just to kind of see what was going on. Um and uh I met Ben man who's one of the founders at uh at Anthropic and uh he just immediately won me over. Um and as soon as I met kind of the rest of the team at an it just won me over and I think I think probably in two ways. So one is it operates as a research lab. Um so the product was teeny teeny tiny. It's really all about building a safe model. That's all that matters. Um 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. Um that really resonated with me after building product for many years. And then the second thing was just how missiondriven it is. Um like I'm I'm a huge sci-fi reader. My bookshelf is just like filled with sci-fi. And so like I just know how bad this can go. + +[`43:11`](https://youtu.be/PQU9o_5rHC4?t=2591) And when I kind of think about what's going to happen this year, it you know it's going to be totally insane. And in the worst case it can go very very bad. + +[`43:19`](https://youtu.be/PQU9o_5rHC4?t=2599) Um and so I just wanted to be at a place that really understood that and kind of really internalized that. And at Ant, you know, like if you overhear conversations in the lunchroom or in the hallway, people are talking about AI safety. this is really the thing that everyone cares about more than anything. Um, and so I just wanted to be in a place like that. I I know I know for me personally the mission is just so important. + +[`43:40`](https://youtu.be/PQU9o_5rHC4?t=2620) What is gonna happen this year? + +[`43:42`](https://youtu.be/PQU9o_5rHC4?t=2622) Okay. So if you think back like six months ago and uh kind of what are the predictions that people are making? So Daario predicted that 90% of the code at Anthropic would be would be written by Quad. This is true. Um for me personally it's been 100% for like since Opus 4.5. Um I just I uninstalled my IDE. I don't edit a single line of code by hand. It's just 100% quad code and Opus. Um and you know I land you know like 20 PR a day every day. If you look at Enthropic overall it ranges between like 70 to 90% uh you know depending on the team. For a lot of teams it's also like 100% for a lot of people it's 100%. And I remember making this prediction back in May when we ged cloud code that you wouldn't need an ID to code anymore. Uh and it was totally crazy to say. I feel like people in the audience gasped + +[`44:28`](https://youtu.be/PQU9o_5rHC4?t=2668) 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 + +[`44:34`](https://youtu.be/PQU9o_5rHC4?t=2674) and this is just like so deep in you know the DNA at cuz like you know three of our founders were co-authors of the scaling laws 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. Um, and I think today coding is practically solved, you know, for me and I think it'll be the case for everyone. Um, you know, regardless of domain, 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 our PM's code, our designers code, our EM codes, our um like everyone our our finance guy codes like everyone on our team codes. We're going to start to see this everywhere. So this is sort of uh this is kind of like the lower bound if we just continue the trend. The upper bound I think is a lot scarier. Um, and this is something like, you know, we hit ASL4. Um, 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. Um, and so if this happens, essentially, we have to meet a bunch of criteria before we can release a model. And so the the extreme is that, you know, this happens um or there's some kind of catastrophic misuse like people are using the model to design bioiruses, design zero days, stuff like this. Um, and this is something that we're really really actively working on so that doesn't happen. I think uh it's just been honestly it's just been like so exciting and humbling like seeing how people are using quad code like uh you know I just wanted to build a cool thing and it ended up being really useful uh and that was so surprising and so exciting. + +[`46:23`](https://youtu.be/PQU9o_5rHC4?t=2783) My impression from Twitter 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. Is that how it was for you at like internally? Did you were you having like a nice Christmas break and then came back and like what happened? Well, actually for all of December, I was traveling around. Uh, and I 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. Uh, and then I also started to use Twitter at the time cuz like I 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 discovered that was the moment where they discovered Opus 4.5. I kind of already knew. + +[`47:01`](https://youtu.be/PQU9o_5rHC4?t=2821) Mhm. + +[`47:02`](https://youtu.be/PQU9o_5rHC4?t=2822) Uh, and internally quad code's 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 cloud code now, you know, there was some stat from Mercury that like 70% of startups are you know choosing cloud as their model of choice. There was some other stat from like semi analysis that 4% of all public commits are made by cloud code. um like of all code written everywhere. All the companies, you know, use squad code from like the biggest companies to kind of, you know, smallest startups, you know, like it it wrote it it plotted the course for Perseverance like for like the Mars rover. This is just like this is the coolest thing for me. And we like we even printed posters cuz the team was like, "Wow, this is just like so cool that NASA chooses to use this thing." So, yeah, it's just like it's humbling. Um but it also feels like the very beginning. What's the sort of interaction between uh claude code and then co-work like you know was it a fork of cla code? Was it like you had cla code look at the cloud code and say let's make a new spec for nontechnical 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? + +[`48:12`](https://youtu.be/PQU9o_5rHC4?t=2892) This is going to be like my fifth time using the word wait and demand. It was just that I mean like we we were looking at Twitter and there was like that one guy that was using quad code to like monitor his tomato plants. + +[`48:21`](https://youtu.be/PQU9o_5rHC4?t=2901) Mhm. + +[`48:23`](https://youtu.be/PQU9o_5rHC4?t=2903) Uh there was like this other person that was using it to like recover wedding photos off of a corrupted hard drive. There were people that using it for like uh for finance. When we looked internally at anthropic, 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 cloud code wrapper in a guey in the desktop app and that's all it is. It's just quad code under the hood. It's the same agent. + +[`48:55`](https://youtu.be/PQU9o_5rHC4?t=2935) Oh wow. + +[`48:58`](https://youtu.be/PQU9o_5rHC4?t=2938) Um and uh Felix and the team and Felix was early Electron contributor. He kind of knows that stack really well and he was hacking on various ideas and uh they they built it in I think something like 10 days. It was it was just like 100% written by quad code. Uh and it just felt ready to release. There was a lot of stuff that we had to build for nontechnical users. So it's a little bit different than a technical audience. Uh it runs in a all the code runs in a virtual machine. Uh there's a lot of delete uh protections for deletion and things like this. There's a lot of permission prompting and kind of other guardrails for users. Um yeah, it was honestly pretty obvious. Boris, thank you so much for making something that uh 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 3 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. + +[`49:54`](https://youtu.be/PQU9o_5rHC4?t=2994) Yeah, thanks for having me. And uh send bugs. + +[`49:59`](https://youtu.be/PQU9o_5rHC4?t=2999) Sounds good. + +--- + +## Sources + +- [Inside Claude Code With Its Creator Boris Cherny — Y Combinator — YouTube](https://youtu.be/PQU9o_5rHC4) +- [Y Combinator](https://www.ycombinator.com/) diff --git a/videos/claude-cat-every-29-oct-25.md b/videos/claude-cat-every-29-oct-25.md new file mode 100644 index 0000000..ad3f79f --- /dev/null +++ b/videos/claude-cat-every-29-oct-25.md @@ -0,0 +1,462 @@ +# The Secrets of Claude Code From the Engineers Who Built It — Every + +Transcript of the interview with Cat & Boris (Claude Code engineers) on the Every podcast, published October 29, 2025. + + + + + + +
← Back to Claude Code Best PracticeClaude
+ +--- + +## Video Details + +- **Guest:** Cat & Boris (Claude Code Engineers, Anthropic) +- **Host:** Every +- **Published:** October 29, 2025 +- **YouTube:** [Watch on YouTube](https://youtu.be/IDSAMqip6ms) + +--- + +## Transcript + +[`0:02`](https://youtu.be/IDSAMqip6ms?t=2) What made it work really well is that quad code has access to everything that an engineer does at the terminal. Everything you can do, quad code can do. There's nothing in between. + +[`0:10`](https://youtu.be/IDSAMqip6ms?t=10) There's actually an increasing number of people internally at anthropic that are using like a lot of credits [music] like spending like over a,000 bucks every month. We see this like power user behavior. This is something that they teach in YC. If you can solve your own problem, it's much more likely you're solving the problem for others. There's this like really old idea in product called latent demand. You build a product in a way that is hackable that is kind of open-ended enough that people can abuse it for other use cases it wasn't really designed for and you build for that cuz you kind of know there's demand for it. Do you think the CLI is the final form [music] factor? Are we going to using cloud code in the CLI primarily in a year or in 3 years or is This podcast is sponsored by Google. Hey folks, I'm Omar, product and design lead at Google DeepMind. We just launched a revamped vibe coding experience in AI [music] Studio that lets you mix and match AI capabilities to turn your ideas into reality faster than ever. Just describe your app and Gemini will automatically wire up the right models and APIs for you. And if you need a spark, hit I'm feeling lucky and we'll help you get started. Head to a.studio/bild. studio/build to create your first app. + +[`1:29`](https://youtu.be/IDSAMqip6ms?t=89) Cat Boris, thank you so much for being here. + +[`1:30`](https://youtu.be/IDSAMqip6ms?t=90) Thanks for having us. + +[`1:32`](https://youtu.be/IDSAMqip6ms?t=92) Yeah. Um, so for people who don't know you, you are the creators of Claude Code. Thank you very much from the bottom of my heart. It's uh I love Cloud Code. + +[`1:42`](https://youtu.be/IDSAMqip6ms?t=102) That's amazing to hear. [laughter] That's what we love to hear. Um I Okay, I think the place I want to start is when I first used it. Um, there was like this moment like I think it was around when uh Sonnet 37 came out where I was like I used it and I was like, "Holy this is like a completely new paradigm. It's a a completely new way of thinking about code." And the the big difference was um you went all the way and just eliminated the text editor and you're just like all you do is like talk to the talk to the terminal and and that's that's it. Um, and you know, previous paradigms of AI programming, pre previous harnesses have been like you have a text editor and you have the AI on the side and it's kind of like or it's a tab complete. So, take me through like that decision process that ar that that process of of architecting this new paradigm. How do you how did you think about that? + +[`2:36`](https://youtu.be/IDSAMqip6ms?t=156) Yeah, I think the the most important thing is it was not intentional at all. [laughter] Okay. + +[`2:42`](https://youtu.be/IDSAMqip6ms?t=162) Uh, we we sort of ended up with it. So at the time when I joined Enthropic um we were still on different teams at the time. Um there was this previous predecessor to quad code. It was called Clyde like CL C cliop. And it was this like research project you know it took like a minute to start up. It was this kind of like really heavy Python thing. It had to like run a bunch of indexing and stuff. And when I joined I wanted to ship my first PR and I hand wrote it like a you know like a noob in a in [laughter] a like I didn't know about any of these tools. U I didn't know any better and then I I put up this PR and um Adam Wolf who was the um manager for our team for a while. He was my ramp up buddy and he just like rejected the PR and he was like you wrote this by hand. What are you what are you [laughter] doing? Use Quide. Um cuz he was also hacking a lot on Quiet at the time. And so I tried Quaid. I gave it the description of the task and it just like one shot at this thing + +[`3:39`](https://youtu.be/IDSAMqip6ms?t=219) and this was like you know sonnet 35. So I still had to fix a thing even for this kind of basic task and the harness was super old. So it took like 5 minutes to turn this thing out and just took forever and um but it but it worked and I was just mind-blown that this this was even possible and they just kind of got the gears turning. maybe you don't actually need an IDE. + +[`4:02`](https://youtu.be/IDSAMqip6ms?t=242) And then later on I was prototyping using the anthropic API and the easiest way to do that was just building a little app in the terminal cuz that way I didn't have to build a UI or anything. And I started just making a little chat app and then I just started thinking maybe we could do something a little bit like Clyde. So let let me build like a little Clyde and it actually ended up being a lot more useful than that without a lot of work. And I think the biggest revelation for me was when we started to give the model tools. It just started using tools and it was just it was this insane moment. Like the model just wants to use tools. Like we gave it bash and it just started using bash writing apple script to like automate stuff uh in response to questions. And I was like this is just the craziest thing. I've never seen anything like this. Cuz at the time I had only used IDE with like you know like text editing a little like oneline autocomplete, multi-line autocomplete, whatever. Um, so that that's where this came from. It was this kind of convergence of like prototyping but also kind of seeing what's possible in kind of like a very um rough way. + +[`5:03`](https://youtu.be/IDSAMqip6ms?t=303) Um, and this thing ended up being surprisingly useful and and I think it was the same for us. I think for me it was like kind of sonnet 4 opus 4. That's where that magic moment was. I was like, "Oh my god, this this thing works." + +[`5:17`](https://youtu.be/IDSAMqip6ms?t=317) That's interesting. So like tell me about that that the tool moment because I think that is one of the special things about cloud code is it just writes bash and it's really good at it. And I think a lot of um previous agent architectures or even anyone building agent today, your first instinct might be okay, we're going to give it a find file tool and then we're going to give it a uh open file tool and you you build all these like custom wrappers for you know uh all the different actions you might want the agent to take, but Cloud Code just uses bash and it's like really good at it. So how do you think about um how do you think about what you learned from that? Yeah, I think we're at this point right now where Quad Code actually has a bunch of tools. I think it's like a dozen or something like this. We we actually like add and remove tools most weeks. So, this changes pretty often. Um, but today there actually is a search uh there's a tool for for searching. Um, and we do this for two reasons. One is the UX, so we can show the result a little bit nicer to the user because there's still a human in the loop right now for most tasks. Uh, and the second one is for permissions. So, if you say in your like cloud code like settings.json JSON on this file you cannot read. We we have to kind of enforce this. Uh we enforce it for bash but we can do it a little bit more efficiently for if we have a specific search tool. Um but definitely we want to like unhip tools and kind of keep it simple for the model. Um like last week or two weeks ago we unchipped the OS tool because in the past we needed it but then we actually built a way to enforce this kind of permission system for bash. Um, so in Bash, if we know that you're not allowed to read a particular directory, Quad's not allowed to OS that directory. And because we can enforce that consistently, we don't need this tool anymore. Um, and this is nice because it's a it's a little less choice for Quad. A little less stuff in context. + +[`7:01`](https://youtu.be/IDSAMqip6ms?t=421) Got it. And how do you guys split responsibility on the team? + +[`7:06`](https://youtu.be/IDSAMqip6ms?t=426) Um, I would say Boris sets the technical direction and has been the product visionary for a lot of the features that we've come out with. I see myself as more of like a supporting role to make sure that um that one that like our pricing and packaging resonates with our users. Um two making sure that we're shephering all our features across the launch process. So from like deciding all right like these are the prototypes that we should definitely ant food to like setting the quality threshold for ant fooding through to communicating that to our end users. And um there's definitely some new initiatives that we're working on that uh I would say historically a lot of quad code has been built bottoms up like Boris and a lot of the core team members have just had these great ideas for to-do list sub agents hooks like all these are bottoms up. As we think about expanding to more services and bring cloud code to our places, I think a lot of those are more like, all right, let's talk to customers. Let's bring engineers into those conversations and prioritize those services and knock them out. + +[`8:08`](https://youtu.be/IDSAMqip6ms?t=488) Got it. What is ant fooding? + +[`8:10`](https://youtu.be/IDSAMqip6ms?t=490) Oh, ant fooding is + +[`8:11`](https://youtu.be/IDSAMqip6ms?t=491) Oh, ant fooding. + +[`8:14`](https://youtu.be/IDSAMqip6ms?t=494) Oh, um it it means dog fooding. [laughter] So, + +[`8:19`](https://youtu.be/IDSAMqip6ms?t=499) anthropic ant. I [laughter] got it. + +[`8:22`](https://youtu.be/IDSAMqip6ms?t=502) Yeah. Our nickname for um internal employees is ant. And so uh ant fooding is our version of dog fooding. Uh internally over I think 70 or 80% of ants uh technical anthropic employees use cloud code every day. And so every time we are thinking about a new feature, we push it out to people internally and we get so much feedback. We have a feedback channel. I think we get a post every five minutes. And so you get really quick signal on whether people like it, whether it's buggy, um or whether uh it's not good and we should unchip it. + +[`8:57`](https://youtu.be/IDSAMqip6ms?t=537) You can tell um you can tell that someone that is building stuff is using it all the time to build it. Uh because the the like its ergonomics just makes sense if you're trying to build stuff and that that only happens if you're like ant ant fooding. [laughter] Um I Yeah. Yeah. And I I think that that's a really interesting paradigm for building new stuff like that sort of bottoms up I make something for myself. Um tell me about that. + +[`9:23`](https://youtu.be/IDSAMqip6ms?t=563) Yeah. And C cat is also so humble. Um I think cat has a really big role in the product direction also like it comes from everyone on the team and like these specific examples this actually came from everyone on the team like to-do lists and sub aents that was Sid Hooks Dixon shipped that plugins Daisy shipped that. + +[`9:38`](https://youtu.be/IDSAMqip6ms?t=578) So like everyone on the team like these ideas come from everyone. Um, and so I think for us like we build this core agent loop and this kind of core experience and then everyone on the team uses the product all the time. Uh, and so everyone outside the team uses the product all the time. And so there's just all these chances to build things that serve these needs. Like for example, like bash mode, you know, like the exclamation mark and you can type in bash commands. This was just like many months ago. I was using quad code and I I was going back and forth between two terminals and just thought it was kind of annoying. Uh, and just on a whim, my asked squad to kind of think of ideas, the thought of this like exclamation mark bash mode. And then I was like, great, make it pink and then ship it. [laughter] It just did it. And like that that's the thing that still kind of persisted. And you know, now you see kind of others also kind of catching on to that. + +[`10:24`](https://youtu.be/IDSAMqip6ms?t=624) That's funny. I actually didn't know that. And that's extremely useful because I always have to open up a new tab to like run any bash commands. So you just you just do an exclamation point and then it just like runs it directly instead of filtering it through all all the cloud stuff. + +[`10:38`](https://youtu.be/IDSAMqip6ms?t=638) Yeah. And quad code sees the full output too. + +[`10:40`](https://youtu.be/IDSAMqip6ms?t=640) Interesting. That's perfect. [laughter] + +[`10:42`](https://youtu.be/IDSAMqip6ms?t=642) So anything you see in the cloud code view, cloud code also sees. + +[`10:44`](https://youtu.be/IDSAMqip6ms?t=644) Okay, that's really interesting. + +[`10:46`](https://youtu.be/IDSAMqip6ms?t=646) And this is kind of a UX thing that we're thinking about. Like in the past tools were built for engineers, but now it's equal parts engineers and model. + +[`10:53`](https://youtu.be/IDSAMqip6ms?t=653) And so like as an engineer, you can see the output, but it's actually quite useful for the model also. And this is part of the philosophy also like everything is dual use. Um so for example, the model can also call slash commands. So like you know I have a slash command for slashcomit where I run through kind of a few different steps like diffing and generating a reasonable commit message and and this kind of stuff. I run it manually but also Claude can run this for me. Uh and this is pretty useful because we get to share this logic. We get to kind of define this tool and then we we both get to use it. + +[`11:24`](https://youtu.be/IDSAMqip6ms?t=684) Yeah. What are the differences in uh designing tools that are dual use from designing tools that are you know used by one or the other? Surprisingly, it's the same. + +[`11:32`](https://youtu.be/IDSAMqip6ms?t=692) Okay. + +[`11:34`](https://youtu.be/IDSAMqip6ms?t=694) So far. + +[`11:36`](https://youtu.be/IDSAMqip6ms?t=696) Yeah. I I I sort of feel like this kind of elegant design for humans translates really well to the models. + +[`11:41`](https://youtu.be/IDSAMqip6ms?t=701) So, you're just thinking about what would make sense to you and the model generally, it makes sense to the model, too, if it makes sense to you. + +[`11:49`](https://youtu.be/IDSAMqip6ms?t=709) Yeah. I think one of the really cool things about Cloud Code being um a terminal UI and what made it work really well is that Cloud Code has access to everything that an engineer does at the terminal. And I think when it comes to whether the tool should be dual use or not, I think making them dual use actually makes the tools a lot easier to understand. It just means that okay, everything you can do, cloud code can do. There's nothing in between. + +[`12:14`](https://youtu.be/IDSAMqip6ms?t=734) Yeah, that's interesting. Yeah, there there are a couple of those decisions. So, um no no code editor, it's in the terminal, so it has access to your files. Um, and it's it's on your computer versus like in the cloud in a virtual machine. So you get like repeated you you get to use it in a repeated way where you can like you know build up your cloud MD file or you know like all all like build slash commands and all that kind of stuff where it becomes very composable um and extensible [snorts] from a very simple starting point. And I'm curious about how you think about, you know, for for people who are thinking about, okay, I want to build an agent, I want to build probably not cloud code, but like something else, how you get that that simple package that then can extend and be really powerful over time. + +[`13:07`](https://youtu.be/IDSAMqip6ms?t=787) For me, I I start by just thinking about it like developing any kind of product where you have to solve the problem for yourself before you can solve it for others. And like this is something that they teach in YC is you have to start with yourself. So like if you if you can solve your own problem, it's much more likely you're solving the problem for others. And I I think for coding starting locally is the reasonable thing and you know now we have cloud code on the web. So you can also use it with a virtual machine and um you know you can use it in a remote setting and this is super useful when you're on the go you want to take that from your phone + +[`13:37`](https://youtu.be/IDSAMqip6ms?t=817) and and this is sort of we we started proving this out kind of a step bat a time + +[`13:43`](https://youtu.be/IDSAMqip6ms?t=823) where you can do atcloud in GitHub and uh I use this every day like on the way to work I'm like at a red light I probably shouldn't be doing this but I'm like you know on GitHub at a red light and then I'm like at claude you know fix this issue or whatever and so it's it's just real useful to be able to control it from your phone um and this kind proves out this experience. I I don't know if this necessarily makes sense for every kind of use case. For coding, I think starting local is right. Um I don't know if this is true for everything, though. + +[`14:07`](https://youtu.be/IDSAMqip6ms?t=847) Got it. What are the slash commands you guys use? + +[`14:11`](https://youtu.be/IDSAMqip6ms?t=851) Slashprit. [laughter] + +[`14:12`](https://youtu.be/IDSAMqip6ms?t=852) Yeah. + +[`14:15`](https://youtu.be/IDSAMqip6ms?t=855) Um yeah, it it's I I think the pritcomand makes it a lot faster for claw to know exactly what bash commands to run in order to make a commit. + +[`14:24`](https://youtu.be/IDSAMqip6ms?t=864) And what does the prit slash command do for people who are unfamiliar? Oh, it it just tells it like exactly how to make a commit. Okay. + +[`14:33`](https://youtu.be/IDSAMqip6ms?t=873) Um and you can like dynam you can say like, okay, these are the three bash commands that need to be run. + +[`14:37`](https://youtu.be/IDSAMqip6ms?t=877) Got it. And and what's pretty cool is also we have um this kind of templating system built into slash commands. So we actually run the bash commands ahead of time. They're like embedded into the slash command. Um and you can also pre-allow certain tool invocations. So for that slash command we say allow um you know get commit get push gh and so you don't get asked for permission after you run the slash command because we have like a permission uh based security system. Um and then also it uses haik coup which is pretty cool. Um so it's kind of a cheaper model and faster. Um yeah and for me I I use like commit uh commit PR uh feature dev we use a lot. So like sid created this one. It's kind of cool. So it kind of like walks you through step by step um building something. So we prompt quad to like first ask me how to what exactly I want like build the specification + +[`15:27`](https://youtu.be/IDSAMqip6ms?t=927) and then um you know kind of like build like a detailed plan and then make a to-do list walk through step by step. So it's kind of like more structured feature development + +[`15:35`](https://youtu.be/IDSAMqip6ms?t=935) and then I think the last one that we probably use a lot so we use like security review for all of our PRs and then also code review. Um so like quad does all of our code review internally at anthropic. Um, you know, there's still a human approving it, but quad does kind of the first step in code review. That's just a slashcode review command. + +[`15:51`](https://youtu.be/IDSAMqip6ms?t=951) Got it. Yeah. What are the things I would love to go deeper into like the how do you make a good plan? So, the sort of the feature dev thing because I think there's a lot of like little tricks that um I'm starting to find or people at every start starting to find that work and I'm curious like what what are things that that we're missing. So for example, one um step in the one unintuitive step of the of the you know plan development process is even if I don't exactly know what the thing that needs to be built is I just have like a little sentence in my mind like I want feature X I have Claude just like implement it just without giving it anything else and I see what it does and that helps me understand like okay here's actually what I mean because it made all these different mistakes or like it it did something that I didn't expect that might be And then I use that like the learning from the sort of throwaway development. I just clear it out. And then that helps me write a better plan spec for the actual feature development, which is something that you would never do before because it'd be too expensive to just like yolo send an engineer on a feature that you hadn't actually speced out. But because you have cloud going through your codebase and doing stuff, you can like learn stuff from it. Um that helps inform the actual plan that you make. + +[`17:04`](https://youtu.be/IDSAMqip6ms?t=1024) Yeah. I feel maybe I I can start and I'm curious how you use it too. + +[`17:07`](https://youtu.be/IDSAMqip6ms?t=1027) I think there's like a few different modes maybe for me like one one is prototyping mode. + +[`17:12`](https://youtu.be/IDSAMqip6ms?t=1032) So like traditional engineering prototyping you want to kind of build the simplest possible thing that touches all the systems just so you can kind of get a vague sense of like what are the systems there's unknowns and just to kind of trace through everything. + +[`17:24`](https://youtu.be/IDSAMqip6ms?t=1044) Um and so I I do the exact same thing as you Dan like Claude just does the thing and then I see where it messes up and then I'll ask it to just throw it away and do it again. So just hit escape twice, go back to the old checkpoint and then try again. I think there's also maybe two other kinds of tasks. So one is just things that quad can one-shot and I feel pretty confident it can do it. So I'll just tell it and then I'll just go to a different tab and I'll I'll shift tap to auto accept and then just go do something else or go to another one of my quads and tend to that while it does this. + +[`17:54`](https://youtu.be/IDSAMqip6ms?t=1074) Um but also there's this kind of like harder feature development. So these are you know things are maybe in the past it would have taken like a few hours of engineering time and for this usually I would I'll shift tap into plan mode and then align on the plan first before it even writes any code. Um and and I think what's really hard about this is the boundary changes with every model and it in kind of a surprising way where the newer models they're more intelligent so the boundary of what you need plan mode for got pushed out like a little bit + +[`18:21`](https://youtu.be/IDSAMqip6ms?t=1101) like before you used to need to plan now now you don't. And I think it's this general trend of like stuff that used to be scaffolding with a more advanced model, it gets pushed into the model itself and the model kind of tends to subsume everything over time. Yeah. How do you think about like building a agent harness that isn't just going to like you're you're not spending a bunch of time um building stuff that is just going to be subsumed into the model in 3 months when the new cloud comes out? like, yeah, how do you how do you know what to build versus what to just say it doesn't work quite yet, but next time it's going to work, so we're not going to spend time on it. + +[`18:57`](https://youtu.be/IDSAMqip6ms?t=1137) I think we build most things that we think would improve Cloud Code's capabilities, even if that means we'll have to get rid of it in 3 months. If anything, we hope that we will get rid of it in three months. + +[`19:09`](https://youtu.be/IDSAMqip6ms?t=1149) I think for now, we just want to offer the most premium experience possible and so we're not too worried about throwaway work. H + +[`19:17`](https://youtu.be/IDSAMqip6ms?t=1157) interesting. Yeah. And an example of this is something like even like plan mode itself. I think we'll probably un ship it at some point when Quad can just figure out from your intent that you probably want to plan first. Um or you know, for example, I just deleted like 2,000 tokens or something from the system prompt yesterday just cuz like Sonnet 45 doesn't need it anymore. Um but Opus Opus 41 did need it. What about um you know in the case where uh the the latest frontier you know model doesn't need it but you know you're trying to figure out how to make it more efficient because you have so many users that you know you're maybe you you're not going to use Opus or Sonnet 45 for everything. Maybe you're going to use Haiku. So there's a trade-off between having a more um elaborate harness for Haiku versus just like not spending time on it using Sonnet eating the cost and working on more Frontier type stuff. In general, we've positioned Quad Code to be a very premium offering. So, our north star is making sure that it works incredibly well with the absolutely most powerful model we have, which is Sonnet 45 right now. + +[`20:20`](https://youtu.be/IDSAMqip6ms?t=1220) Um, we are investigating how to make it work really well for like future generations of smaller models, but it's um it's not the top priority for us. + +[`20:29`](https://youtu.be/IDSAMqip6ms?t=1229) Okay. What do you think about um you know one thing that I notice is we get models um often and thank you very much for this. We get models a lot before they come out and it's our job to kind of figure out is it any good and over the last six months when I'm testing claude for example in the claude app with a new frontier model it's actually very hard to tell whether it's how whether it's better immediately. Um, but it's really easy to tell in cloud code because the the harness matters a lot for the performance that you get out of the model. And you guys have the benefit of building cla or building cloud code inside of the um inside of enthropic. So there's like a much tighter integration between um the fundamental like model training and the harness that you're building and and they seem to kind of like really impact each other. So how does that how does that work internally and and um what are the benefits you get from having that like tight integration? + +[`21:25`](https://youtu.be/IDSAMqip6ms?t=1285) Yeah, I think the biggest thing is like researchers just use this and so you know as they see what's working, what's not, they can they can improve stuff. Um we do like a lot of eval to kind of communicate back and forth and understand where exactly the model's at. Um, but yeah, there's this frontier where you need to give the model a hard enough task to really push the limit of the model. And if you don't do this, then all models are kind of equal. But if you give it a pretty hard task, you can you can tell the difference. + +[`21:55`](https://youtu.be/IDSAMqip6ms?t=1315) What sub aents do you use? + +[`21:57`](https://youtu.be/IDSAMqip6ms?t=1317) Um, I I have a few. I have like a planner sub agent that I use. I have a code review sub aent. Code review is actually something where sometimes I use a sub agent, sometimes I use a slash command. So usually in CI to slash command, but in synchronous use I use a sub aent for the same thing. + +[`22:14`](https://youtu.be/IDSAMqip6ms?t=1334) um it's a good question. Yeah, maybe it's like a matter of taste. Yeah, I don't know. I don't know. Um I think it's maybe when you're running synchronously, it's kind of nice to fork off the the context window a little bit because all the stuff that's going on in the code review, it's not relevant to what I'm doing next. But in CI, it just doesn't matter. + +[`22:32`](https://youtu.be/IDSAMqip6ms?t=1352) Are you ever spawning like 10 sub agents at once? And for what? + +[`22:36`](https://youtu.be/IDSAMqip6ms?t=1356) For me, I do it mostly for like big migrations. Okay, + +[`22:40`](https://youtu.be/IDSAMqip6ms?t=1360) this like the big thing. Um, actually we have so this like coder slash command that we use there's a bunch of sub aents there and so one of the steps is like find all the issues and so there's one sub agent that's like checking for quadmd compliance. There's another sub agent that's looking through git history to see what's going on. Another sub aent that's looking for kind of obvious bugs and then we do this like kind of dduping quality step after. So they find a bunch of stuff. A lot of these are false positives and so then then we spawn like five more sub aents and these are all just like checking for false positives. And in the end, the result is awesome. It finds like all the real issues without the false issues. + +[`23:13`](https://youtu.be/IDSAMqip6ms?t=1393) That's great. I actually do that. Um, so one of my non-technical cloud code use cases is um expense filing. So like when I'm I'm in SF right now, so like I have all these expenses. And so I built this little cloud project that uh in in cloud code that um it uses uh one of these, you know, finance APIs to just download all my credit card transactions. And then it uh decides like these are probably the expenses that I'm going to have to like file. And then I have two sub agents, one that represents me and one that represents the company. And they like do battle to like figure out like what's the proper um like actual set of expenses. [laughter] uh it's like an auditor sub agent and like you know pro Dan sub agent. So um yeah that kind of thing the the sort of like opponent processor uh pattern seems to be like an interesting one. + +[`24:00`](https://youtu.be/IDSAMqip6ms?t=1440) Yeah. Yeah. It's it's it's it's cool. I I feel like when sub aents were first becoming a thing actually what inspired us there's like a Reddit thread a while back where someone made sub agents for like there was like a front end dev and a backend dev and like a think it was like a designer + +[`24:11`](https://youtu.be/IDSAMqip6ms?t=1451) testing dev + +[`24:13`](https://youtu.be/IDSAMqip6ms?t=1453) testing dev like there was like a PM sub agent and this is like you know it's cute like it feels like a little maybe too anthropomorphic um maybe maybe there's something to this but I I think like the value is actually like the uncorrelated context windows where you have like these two context windows that don't know about each other and this is kind of interesting um and you tend to get better results this way. What about you? Do you have any interesting sub agents you use? + +[`24:35`](https://youtu.be/IDSAMqip6ms?t=1475) So, I've been tinkering with one um that is really good at front-end testing. So, it uses Playright to like see all right, what are like all the errors that are client side and pull them in and try to test more steps of the app. Um, it's not totally there yet, but I'm seeing signs of life and I think it's the kind of thing that we could potentially um, bundle in one of our plugins marketplaces. + +[`25:02`](https://youtu.be/IDSAMqip6ms?t=1502) Yeah. Um, definitely. I I' I've used something like that just with Puppeteer and just like watching it build something and then open up the browser and then be like, "Oh, I need to change this." It's like this is like, "Oh my god." + +[`25:12`](https://youtu.be/IDSAMqip6ms?t=1512) Yeah. It's really cool. + +[`25:13`](https://youtu.be/IDSAMqip6ms?t=1513) It's really cool. I think I think we're starting to see the beginnings of this like massive like multi- massive sub aents. I I don't know what they call this like swarms or something like that. There's a bunch of people there's actually an increasing number of people internally at anthropic that are using like a lot of credits every month like you know like spending like over a thousand bucks every month. Um and this like this percent of people is growing actually pretty fast. And I think the common use case is like code migration. And so what they're doing is like framework A to framework B. uh there's like the main agent, it makes a big to-do list for everything and then just kind of map produce over a bunch of sub agents. So you instruct quad like yeah like start 10 agents and then just go like you know 10 at a time and just migrate all all the stuff over. + +[`25:53`](https://youtu.be/IDSAMqip6ms?t=1553) That's interesting. What would be like a concrete example of the kind of migration that you're talking about? + +[`25:58`](https://youtu.be/IDSAMqip6ms?t=1558) I think the most classic is like lint rules. + +[`26:00`](https://youtu.be/IDSAMqip6ms?t=1560) So there's like you know there's some kind of lint rule you're rolling out. There's no autofixer because it's like you know like as an analysis can't really it's kind of too simplistic for it. Um I think other stuff is like framework migrations like um we just migrated from like one testing framework to a different one. That's a pretty common one where it's super easy to verify the output. + +[`26:19`](https://youtu.be/IDSAMqip6ms?t=1579) One of the things I found is and this is both for project projects inside of every and then just open source projects. It's like if you're someone building a product and you want to build a feature that's um been done before. So maybe like an an example that people might need to implement a bunch is like memory. How do you do memory? Um because we have a bunch of different products internally, you can just like spawn cloud sub agents to be like how do these three other products do it? And there's like possibility for just like tacit code sharing where you don't need to like have an API or you don't need to like ask ask anyone. You can just be like how does how do we do this already? And then use the best practices to um uh to uh build your own. And you can also do that with open source because there's like tons of open source projects where people are like you know they've been working on memory for like a year and it's like really really good. You be like what are the patterns that um people have figured out and which ones do I want to implement? + +[`27:10`](https://youtu.be/IDSAMqip6ms?t=1630) Totally. You can also connect your version control system. If you've built a similar feature in the past, cloud code can use those APIs like query GitHub directly and find how people implemented a similar feature in the past and read that code and um copy the relevant parts. + +[`27:27`](https://youtu.be/IDSAMqip6ms?t=1647) Yeah. Is there um have you found any use for like log files of okay you know here's here's the full history of like how I implemented it and like is that important to give to claude and and and how are you how are you um implementing that or making it useful for it? + +[`27:44`](https://youtu.be/IDSAMqip6ms?t=1664) Some people swear by it. Uh there are some people at anthropic where for every task they do, they tell cloud code to write a diary entry in a specific format that just documents like what did it do, what did it try, why didn't it work, and then they even have these agents that like look over the past memory and synthesize it into observations. + +[`28:02`](https://youtu.be/IDSAMqip6ms?t=1682) I think this is like the starting budding + +[`28:06`](https://youtu.be/IDSAMqip6ms?t=1686) like there's like something interesting here that we could productize. + +[`28:10`](https://youtu.be/IDSAMqip6ms?t=1690) Um but it's a new emerging pattern that we're seeing that works well. I think the hard thing about like oneshotting memory from just one transcript is that it's hard to know how relevant a specific instruction is to all future tasks. Like our canonical example is if I say make the button pink, I don't want you to remember to make all buttons pink in the future. And so I think um synthesizing memory from a lot of logs is a is a way to um find these patterns more um consistently. It seems like you probably need like there's some things where you're going to know um you'll be able to summar like synthesize or summarize in this sort of like top down way like this this will be useful later and and you'll you'll know the right level of abstraction at which it might be useful but then there's also a lot of stuff where it's like you actually you know any given like commit log like make the button pink it could be useful for kind of an infinite number of different reasons um that you're not going to know beforehand. So you also need the the model to be able to look up all similar past, you know, commits and surface that at the right time. Is that something that you're also thinking about? Yeah, I think I think there could there could be something like that. And maybe I think one way to see it is this kind of like traditional memory storage work like like mex like kind of stuff where you just want to like put all the information into the system and then it's kind of a retrieval problem problem after that. Um, yeah. I think as the model also gets smarter, it naturally I've seen it start to naturally do this also with Sonnet 45 where if it's stuck on something, it'll just naturally start looking like we talked about before like using bash spontaneously. So just like look through git history and be like, "Oh, okay. Yeah, this is kind of an interesting way to do it." + +[`29:56`](https://youtu.be/IDSAMqip6ms?t=1796) Yeah. One of the things that like we were talking before we started recording, one of the um things that we're doing inside of every like I feel like it has really um change the way that we do engineering because everyone is cloud code build like CLI build and um we have this engineering paradigm that we call compounding engineering where in normal engineering every feature you add it makes it harder to add the next feature and in compounding engineering your goal is to make the next feature easier to build um from the feature that you just added. And the the way that we do that is we try to um codify all the learnings from um from everything that we've done to build the feature. So like you know how did we make the plan and and what parts of the plan needed to be changed or like when we started testing it like what what issues did we find? What are the things that we missed? Um and then we codify them back into all the prompts and all the sub agents and all the slash commands so that the next time when someone does something like this uh it catches it and that makes it easier. And that's why for me, for example, I can like hop into one of our code bases and start like being productive even though I'm I don't know anything about how the code works because we have this like builtup memory system of um of all the stuff that we've learned as we've implemented stuff, but we've had to build that ourselves. I'm curious, are you working on that kind of loop so it the cloud code does that automatically? + +[`31:15`](https://youtu.be/IDSAMqip6ms?t=1875) Yeah, we're we're starting to think about it. Uh it's funny. We we're just uh we we heard the same thing from Fiona. She just joined the team. And you know, she she's our she's our manager. She hasn't coded in like 10 years, something like that. And she was landing PRs on her first day. And she was like, "Yeah, like not only did I kind of I forgot how to code and quad code kind of made it super easy to just get back into it, + +[`31:39`](https://youtu.be/IDSAMqip6ms?t=1899) but also I didn't need to ramp up on any context because I kind of knew all this." And I think a lot of it is about like when people put up poll requests for quad code itself and I think our customers tell us that they do like similar stuff pretty often. Um if you see a mistake I'll just be like add quad add this to quad MD so that the next time it just knows this automatically and you you can kind of like instill this memory in kind of a variety of ways. So you can say like at quad add it to quadmd. You can also say add quad write a test. You know, that's like easy way to make sure this doesn't regress. And I don't feel bad asking anyone to write tests anymore, right? It's just like super easy. And like I think probably close to 100% of our tests are just written by Quad. And if they're bad, we just won't commit it. And then the good ones stay committed. Um, and then also I think lint rules are a big one. So for stuff that's enforced pretty often, we actually have a bunch of internal lint rules. Claude writes 100% of these. Um, and this is mostly just like at Claude in a PR write write this lint rule. And yeah, there's sort of this problem right now about like how how do you do this automatically? And I think generally how like Cat and I think about it is we see this like power user behavior and the first step is how do you enable that by making the product hackable so the best users can figure out how to do this cool new thing + +[`32:53`](https://youtu.be/IDSAMqip6ms?t=1973) but then really the hard work starts of like how do you take this and bring it to everyone else. Um, and for me, I I kept myself in the everyone else bucket. Like, you know, I don't really know how to use Vim. Like, I don't have this like crazy like T-box setup. So, I have like a pretty vanilla setup. So, if you can make a feature that I'll use, it's a pretty good indicator that like other kind of average engineers will use it. That is interesting. Like, tell me about that because like that's something I think about all the time is um making something that is extensible and flexible enough that power users can find like novel ways to use it that you would not have even dreamed of. But it's also simple enough that anyone can use it and it's and they can be productive with it and you can you can kind of pull what the power users find back into like the basic experience. Like how do you think about making those design and product decisions so that you enable that? + +[`33:41`](https://youtu.be/IDSAMqip6ms?t=2021) In general we think that like every engine environment is a little bit different from the others and so it's really important that every part of our system is extensible. Um so everything from your status line to adding your own slash commands through to hooks which let you um insert a bit of determinism at pretty much any step in quad code. So we think these are the these are like the basic building blocks that we give to every engineer that they can play with. um for plugins. Plugins is actually our um so it was built by Daisy on our team and this is this is our attempt to make it a lot easier for the average user like us um to bring these slashcomands and hooks into our workflows. And so what plugins does is it lets you browse existing MCP servers, existing hooks, existing plugins and just like or sorry existing like sash commands and just let you write one command in quad code to pull pull that in for yourself. + +[`34:38`](https://youtu.be/IDSAMqip6ms?t=2078) There's this like really old idea in product called latent demand which I think is probably the main way that I personally think about product and like thinking about what to build next is it's a super simple idea. It's you build a product in a way that is hackable that is kind of open-ended enough that people can abuse it for other use cases it wasn't really designed for. Then you see how people abuse it and then you build for that cuz like you you kind of know there was demand for it, + +[`35:00`](https://youtu.be/IDSAMqip6ms?t=2100) right? + +[`35:02`](https://youtu.be/IDSAMqip6ms?t=2102) Um and like you know when I when I was at Meta, this is how we built kind of all the big products. I think almost every single big product had this nugget of latent demand in it. um you know like for example something like Facebook dating it came from this idea that when uh we looked at who looks at people's profiles I think 60% of views were between people of opposite gender so kind of like traditional setup that were not friends with each other and so we're like oh man okay maybe there's like maybe if we like launch a dating product we can kind of harness this demand that exists + +[`35:32`](https://youtu.be/IDSAMqip6ms?t=2132) that's interesting + +[`35:34`](https://youtu.be/IDSAMqip6ms?t=2134) and for you know marketplace it was pretty similar I think it was like 40% of posts in Facebook groups at the time were by sell posts and so I Okay, people are trying to use this product to buy themselves. We just build a product around it that's probably going to work. And so we think about it kind of similarly, but also we have the luxury of building for developers and developers love hacking stuff and they love customizing stuff and it's like as a user of our own product, it makes it so fun to build and and use this thing. Um, and so yeah, like like I said, we just build the right extension points. We see how people use it and that kind of tells us what to build next. Like for example, we got all these user requests where people were like, "Dude, Quad Code is asking me for all these permissions and I'm out here getting coffee. I don't know that it's asking me for permissions. How could I just get it to like ping me on Slack?" And so we built hooks. Uh Dixon built hooks um so that people could get pinged on Slack and you could get pinged on Slack for anything that you want to get pinged on Slack for. Um, and so it was very much like people really wanted the ability to do something. We didn't want to build the integration ourselves. And so we we exposed hooks for people to do that. + +[`36:41`](https://youtu.be/IDSAMqip6ms?t=2201) The thing that makes me think of is um you you recently um released you kind of moved or rebranded how you talk about cloud code to be this like more general purpose agent SDK. Is that was that driven by some latent demand where you you sort of saw there's like a more general purpose use case for what you built? + +[`37:00`](https://youtu.be/IDSAMqip6ms?t=2220) We realized that similar to how you were talking about using cloud code for things outside of coding, we saw this happen a lot like um we get a ton of stories of people who are using cloud code to like help them write a blog and like manage all the like data inputs and take a first pass in their own tone. Um we find people building like email assistants on this. Um I use it for a lot of just like market research. Um because at the core it's like an agent that can just go on for an infinite amount of time as long as you give it a concrete task and it's able to fetch the right underlying data. So one of the things I was working on was I wanted to look at all the companies in the world and how many engineers they had and to create a ranking. And this is something that quad code can do even though it's not a traditional coding use case. So we realized that like the underlying primitives were really general as long as you give as long as you have like an agent loop that can continue running for a long period of time and you're able to like access the internet and write code and run code pretty much you can if you squint you can kind of build anything on it. Mhm. + +[`38:09`](https://youtu.be/IDSAMqip6ms?t=2289) And and I think like by at the point where we like rebranded it so like from the quad code SDK to the quad Asian SDK, there was already like many thousands of companies using this thing and a lot of those use cases were not about coding. So it's like both both internally and externally. We kind of saw that + +[`38:26`](https://youtu.be/IDSAMqip6ms?t=2306) like health assistants, like financial analysts, legal assistance. Um it was pretty broad. + +[`38:33`](https://youtu.be/IDSAMqip6ms?t=2313) Yeah. What are the coolest ones? I feel like actually you you had Noah Brier on the the podcast recently. I thought like the obsidian like kind of mind mapping notekeeping use case is really cool. It's funny. It's insane how many people use it for this [laughter] + +[`38:47`](https://youtu.be/IDSAMqip6ms?t=2327) particular combination. Uh I think some other like some coding or kind of coding adjacent use cases that are kind of cool is um we have this like issue tracker for quad code. The team's just like constantly underwater like trying to keep up with all the issues coming in. There's just so many. And so I quad ddupes the issues and it automatically finds duplicates and it's extremely good at it. It also does first pass resolution. So usually when there's an issue it'll um proactively put up a PR internally and this is a new uh thing that Enigo on the team built. Um so this is pretty cool. Uh there's also like on call and kind of collecting signals from other places like getting like sentry logs and getting like logs from BigQuery and kind of collating all this. um plus just really good at doing this because it's all just bash in the end, right? + +[`39:29`](https://youtu.be/IDSAMqip6ms?t=2369) And so these are all kind of these internal use cases that that I saw. + +[`39:34`](https://youtu.be/IDSAMqip6ms?t=2374) Is it um so when it's you know collating logs or um you doing issues is that like you have clouds like continually running in the background and is that something that you're building for? + +[`39:43`](https://youtu.be/IDSAMqip6ms?t=2383) Um it gets triggered for that particular one. It gets triggered whenever a new issue is filed. So it runs once but it can choose to run for as long as it needs. + +[`39:52`](https://youtu.be/IDSAMqip6ms?t=2392) Got it. What about the idea of clouds always running? Oo, proactive quads. I think it's definitely where we want to get to. U I would say right now we're very focused on making quad code incredibly reliable for like individual tasks. And you know, if you think about like if you think about like multi-line autocomplete and then like single turn agents and then now we're working on like quad code that can complete tasks. I feel like if you trace this curve eventually you go to even higher levels of abstraction like even more complicated tasks and then hopefully the next step after that is a lot more productivity. So just understanding what your team's goals are what your goals are being able to say hey I think you probably want to try this feature and here's a first pass at the code and here are the assumptions I made and are these correct? + +[`40:41`](https://youtu.be/IDSAMqip6ms?t=2441) I can't wait. Um and I think probably right after that is um Claude is now Um, + +[`40:50`](https://youtu.be/IDSAMqip6ms?t=2450) that's not in the plan. [laughter] + +[`40:52`](https://youtu.be/IDSAMqip6ms?t=2452) So, everyone on the team was like super excited that uh we were we were talking today and they gave me a bunch of questions and I want to make sure I I hit all the questions. Um, uh, oh, here's a good one. Why did you choose agentic rag over vector search in your architecture? And are like vector embeddings uh still relevant? Um so actually initially we did use vector embeddings. Um they're just a really tricky to maintain because you have to continuously reindex the code and they might get out of date and you have local changes. So those need to make it in. And then as we thought about what does it feel like for an external enterprise to adopt it, we realized that this exposes a lot more surface area and like security risk. Um we also found that actually cloud code is really good and cloud models are really good at agentic search. So um you can get to the same accuracy level with agentic search and it's just a much cleaner deployment story. + +[`41:51`](https://youtu.be/IDSAMqip6ms?t=2511) H that's really interesting. + +[`41:53`](https://youtu.be/IDSAMqip6ms?t=2513) Um if you do want to bring semantic search to quad code, you can do so via an MCP tool. So if you want to manage your own index and expose an MCP tool that lets Quad Code call that, that that would work. What do you think are the top MCPS to use with cloud code? + +[`42:09`](https://youtu.be/IDSAMqip6ms?t=2529) Puppeteer and Playright are pretty high up there. + +[`42:11`](https://youtu.be/IDSAMqip6ms?t=2531) Definitely. Yeah. + +[`42:13`](https://youtu.be/IDSAMqip6ms?t=2533) Century has a really good one. Asana has a really good one. Hm. Do you think that there are um any any power user tips that you see people inside of anthropic or you know other people who are you know big power you know inside of organizations that are big cloud code power users that people don't know about but they should. Um, one thing that QuadCo doesn't naturally like to do, but that I personally find very useful is, um, QuadCo doesn't naturally like to ask questions, but you know, if you're brainstorming with a thought partner, a collaborator, usually you do ask questions back and forth to each other. And so, this is one of the things that, um, I like to do, especially in plan mode. I'll just tell Cloud Code like, "Hey, we're just brainstorming this thing. Um, please ask me questions if there's anything you're unsure about." um I want you to ask questions and it'll do it. And I think that actually helps you arrive at a better answer + +[`43:11`](https://youtu.be/IDSAMqip6ms?t=2591) there. There's like there's also like so many tips that we can share. I think like there there's a few really common mistakes I see people make. One is like like you said like not using plan mode enough. This is this is just super important. And I think this is people that are kind of new to a coding. They kind of assume this thing can do anything and it can't. It's like not that good today and it's going to get better but today it can oneshot some tests. can't one-shot most things. Um, and so you kind of have to understand the limits and you have to understand like where you get in the loop. And so [snorts] like something like plan mode, it can like two 3x success rates pretty easily if you like land on the plan first. Um, other stuff that I've seen power users do really well is companies that have really big deployments of quad code and now um, you know, luckily there's a lot of these companies so we can kind of learn from them. Uh having settings JSON that you check into the codebase is really important because you can use this to pre-allow certain commands so you don't get permission prompted every time and also to block certain commands. Let's say you don't want web fetch or whatever and this way as an engineer I don't get prompted and um I can check this in and share it with the whole team so everyone gets to use it. + +[`44:16`](https://youtu.be/IDSAMqip6ms?t=2656) I I get around that by just using dangerous they skip permissions. [laughter] + +[`44:21`](https://youtu.be/IDSAMqip6ms?t=2661) Yeah, we kind of we kind of have this here but we don't you know we don't recommend it. It's like it's a model, you know, it can do it can do weird stuff. Um, I think another kind of cool use case that we've seen is people using stop hooks for interesting stuff. So stop hook runs whenever the turn is complete. So like the assistant did some tool calls back and forth with you know whatever and uh it's done and it returns control back to the user then we run the stop hook and so you can define a stop hook that's like um if the tests don't pass return the text keep going and essentially it's like you can just like make the model like keep going until the thing is done and this is just like insane when you combine it with the SDK and this kind of programmatic usage + +[`45:00`](https://youtu.be/IDSAMqip6ms?t=2700) you can you know this is a stochcastic thing it's a nondeterministic thing but with scaffolding you can get these determin deterministic outcomes. + +[`45:09`](https://youtu.be/IDSAMqip6ms?t=2709) So you guys started this sort of CLI, this CLI paradigm shift. Um, do you think the CLI is the final form factor? Are we are we going to using cloud code in the CLI primarily in a year or in three years, or is there something else that's better? + +[`45:23`](https://youtu.be/IDSAMqip6ms?t=2723) I mean, it's not the final form factor, but we are very focused on making sure the CLI is like the most intelligent that we can make it and that's as customizable as possible. you can talk about the next form factors. + +[`45:38`](https://youtu.be/IDSAMqip6ms?t=2738) Yeah, I mean [laughter] cat C's asking me to talk about because no one knows like this this stuff's like it's just moving like so fast, right? Like no no one knows what these form factors are. Like right now I think our team is in experimentation mode. So we have uh CLI then we came out with the ID extension. Now we have a new ID extension that's like a guey. It's a little more accessible. Um we have add quad and github so you can just add quad anywhere. Um, now there's at quad, there's quad on web and on mobile, so you can use it on any of these places. Um, and we're just in experimentation mode, so we're trying to figure out what's next. I think like if we kind of zoom out and see where this stuff is headed. I think one of the big trends is longer periods of autonomy. And so with every model, we kind of time how long can the model just keep going and do tasks autonomously and just, you know, in dangerous mode in a container, keep autocompacting until the task is done. And now we're on the order of like double digit hours. I think it's like the last model is like 30 hours, something like this. And I, you know, the next model is going to be days. And as you think about kind of parallelizing models, um there's kind of a bunch of problems that come out of this. So one is what is the container this thing runs in because you don't want to have to like close your laptop. I have that right now because I'm doing a lot of uh disb I don't know I've only heard I've only read it but DSPY or disb prompt optimization and like it's on my laptop and it's like I don't want to close I'm like in the way [laughter] middle like with my laptop open because I'm like I don't want to close it. Yeah. + +[`47:03`](https://youtu.be/IDSAMqip6ms?t=2823) Yeah. That's right. Yeah. We've like visited companies before like like customers that everyone's just like walking around with their like quad codes. [laughter] + +[`47:11`](https://youtu.be/IDSAMqip6ms?t=2831) Is this running? So, I think like one is kind of getting getting away from this mode and then I also think pretty soon we're going to be in this mode of like quads monitoring quads. + +[`47:17`](https://youtu.be/IDSAMqip6ms?t=2837) Yeah. + +[`47:19`](https://youtu.be/IDSAMqip6ms?t=2839) Um and kind of I I don't know what the right form factor for this is because as as a human you need to be able to inspect this and kind of see what's going on. Um but also it needs to be quad optimized where um you're optimizing for kind of bandwidth between like the quad to quad communication. Um so my prediction is terminal is not the final form factor. My prediction is there's going to be a few more form factors in the coming months, you know, maybe like year or something like that. And it's going to keep changing very quickly. + +[`47:48`](https://youtu.be/IDSAMqip6ms?t=2868) What do you think about, you know, I teach a lot of cloud code to a lot of every subscribers and + +[`47:52`](https://youtu.be/IDSAMqip6ms?t=2872) thank you. + +[`47:54`](https://youtu.be/IDSAMqip6ms?t=2874) You're welcome. Doing doing your work for you. [laughter] Um uh and I think the like one of the big things is just the terminal is intimidating and uh just like being on a call with subscribers being like here's how you open the terminal and you're allowed to do this even if you're non-technical is like a big deal. [laughter] How do you think about that? Yeah, I um one of the people on our marketing team uh started using cloud code because she was writing some content that touched on cloud code and I was like you should really experience it and she got like 30 popups on her screen where she had to accept various permissions because she'd never used a terminal before. So I completely see eye to eye with you on that. It's definitely um hard for non-engineers and there's even some engineers we've found who aren't fully comfortable with working day-to-day in the terminal. Um, our VS Code GUI extension is our first step in that direction because you don't have to think about the terminal at all. It's like a traditional interface with a bunch of buttons. Um, I think we are working on more um graphical interfaces. Uh, so quad code on the web is a guey. I think that actually might be a good starting point for people who are less technical. + +[`49:05`](https://youtu.be/IDSAMqip6ms?t=2945) Yeah. Yeah. There there was this like magic moment maybe like a few months ago where like I walked into the office and the some of the data scientists at Anthropic like sit right next to the quad code team and the data scientist just had like quad code running on their computers and I was like what what is this like how did you figure this out? I think it was like Brandon uh was like the first one to do it and he was like, "Oh yeah, I just like installed it. Like I work on this product so like I should use it." And I was like, "Oh my god." So he like he figured out how to like use a terminal and JS like you know he hasn't really done this kind of workflow before. Obviously like very technical. Um so I think now we're we're starting to see all these kind of like code adjacent uh like functions. people you use quad code and um yeah it's kind of interesting like from a latent demand point of view these are people hacking the product so there's like demand to use it for this and so we want to make it a little bit easier with more accessible interfaces but at the same time for us for quad code we're laser focused on building the best product for the best engineers and so um we're focused on software engineering and we want to make this like really good but we want to make it a thing that other people can can hack + +[`50:11`](https://youtu.be/IDSAMqip6ms?t=3011) some sometimes cloud code will write code that's a bit verbose post. Um, but you can just tell it to simplify it and it does a really good job. + +[`50:20`](https://youtu.be/IDSAMqip6ms?t=3020) Interesting. And so, and how are how and when are you doing that? So, you're you're using a slash command or you're + +[`50:26`](https://youtu.be/IDSAMqip6ms?t=3026) I just say it. I just + +[`50:27`](https://youtu.be/IDSAMqip6ms?t=3027) Sometimes you're like, "Hey, this should be a oneline change and I'll write five lines and you're like, simplify it and it understands immediately what you mean and it'll fix it." + +[`50:35`](https://youtu.be/IDSAMqip6ms?t=3035) Yeah. I think a lot of people on our team do that, too. Um, that's that's interesting. Why do you like why not then if you're saying that all the time why not then you know push that into like a slash command or the harness or something like that to yeah make it just happen automatically. + +[`50:51`](https://youtu.be/IDSAMqip6ms?t=3051) We do have instructions for this in the cloud MD. I think it impacts such a low percentage of conversations that we don't want it to like over rotate in the other direction. + +[`51:03`](https://youtu.be/IDSAMqip6ms?t=3063) Um and then the reason why not a slash command is because you actually don't need that much context. I think slash command's really good for situations where you would otherwise need to write two three lines but for simp like even for plan mode you actually can use a few words but sometime but it actually takes two or three lines to capture the entirety of what you want in plan mode. Um for simplify it you can just write simplify it and it gets it. + +[`51:28`](https://youtu.be/IDSAMqip6ms?t=3088) Yeah. Yeah, that makes sense. Cool. + +[`51:29`](https://youtu.be/IDSAMqip6ms?t=3089) Yeah. + +[`51:33`](https://youtu.be/IDSAMqip6ms?t=3093) Um okay, now we're we can [laughter] um that's interesting. Yeah, but but this stuff like you know it still feels just so early. + +[`51:39`](https://youtu.be/IDSAMqip6ms?t=3099) Yeah. + +[`51:41`](https://youtu.be/IDSAMqip6ms?t=3101) You know, like we we were talking before before the recording about like kind of where are we on the adoption curve and it still + +[`51:47`](https://youtu.be/IDSAMqip6ms?t=3107) the hian curve or whatever [laughter] whatever that term was. + +[`51:50`](https://youtu.be/IDSAMqip6ms?t=3110) Exactly. And it just feels it just feels like we're you know like first 10% still like the stuff is going to change so fast it's going to keep changing. Even when I talk to researchers outside of enthropic who who abuse quad code um they also get stuck on things like this like not realizing that they can just tell the LLM to simplify it and I think that just goes to show that even for people who are like working in this industry they don't always realize that you can just talk to the model. That's the thing is like I I think that there's this underlying expectation that using AI shouldn't have to be a skill like because it just does whatever you say and you're like well I mean whatever you say is going to matter for what it does. So if you can say things better it's going to do better. [laughter] + +[`52:33`](https://youtu.be/IDSAMqip6ms?t=3153) Yeah. I mean it it changes with every model though. That's the that's the hard part. like you know prompt engineer was a job and now famously it's not a job anymore and there's going to be more jobs that are then like not not jobs anymore of these kind of like little micro skills that you have to learn to use this thing and as the model gets better it can just like interpret it better + +[`52:50`](https://youtu.be/IDSAMqip6ms?t=3170) but I think that's also like for us this is part of this kind of humility that we have to have building a product like this that we just really don't know what's next and we're just trying to figure it out kind of along with everyone else we're just here for the ride + +[`53:00`](https://youtu.be/IDSAMqip6ms?t=3180) and that's why it's cool that you're building it for yourself cuz I think that's the that's the best way to know that is just like you're and this is what we do too is like you're sort of living in the future. You're using it all the time. And uh it's pretty clear what's missing. You're like I just want this thing and you can just do the next thing rather than being like hm let me ask like some enterprise product manager at like some gigantic company like what kind of AI feature do you want? And they're like I don't know like you know put a little chatbot on the side of my you know IDE and you're like okay. [laughter] + +[`53:28`](https://youtu.be/IDSAMqip6ms?t=3208) Yeah. + +[`53:30`](https://youtu.be/IDSAMqip6ms?t=3210) Yeah. This is like the luxurious thing about building dev tools right you're your own customer. I think it's also really um a unique thing about AI because um it sort of reset the game board for all software. So um you know we have Kora this like email assistant and we have like Sparkle which organizes your files and it's like anything that you do for something that you want to use on your computer if you're if you're building it with AI there's a good chance that hasn't been done before because like the whole whole landscape has been reset. And so it's a it's a uniquely exciting time to build stuff for yourself. + +[`54:06`](https://youtu.be/IDSAMqip6ms?t=3246) Totally. I think it totally opens the playing field, too. It's like any individual can now build an app to fill their need and then distribute it to everyone else. + +[`54:14`](https://youtu.be/IDSAMqip6ms?t=3254) Yeah, + +[`54:15`](https://youtu.be/IDSAMqip6ms?t=3255) it's really cool. + +[`54:17`](https://youtu.be/IDSAMqip6ms?t=3257) I've been prototyping all these like random pet projects. Um + +[`54:23`](https://youtu.be/IDSAMqip6ms?t=3263) um I just moved into a new apartment and it's empty. And so I've been um I've been building this like shopping advisor assistant on like the Cloud Agent SDK cuz who has time to like read all the reviews and like look at all the options and find their pricing and everything's like really hard to discover. And so it just like asks me a bunch of questions and I tell it what I want and it shows me a bunch of Yeah, exactly. and it shows me a bunch of photos of like different sofas and options and what people say online + +[`54:49`](https://youtu.be/IDSAMqip6ms?t=3289) and then I tell it what I don't like and it's literally feels like working with a shopping assistant + +[`54:55`](https://youtu.be/IDSAMqip6ms?t=3295) and it it's been really cool. + +[`54:56`](https://youtu.be/IDSAMqip6ms?t=3296) That's really cool. + +[`54:58`](https://youtu.be/IDSAMqip6ms?t=3298) Um I also have my little email response agent that like drafts responses for me but I don't use email that much so + +[`55:05`](https://youtu.be/IDSAMqip6ms?t=3305) Oh, and I knew it wasn't you responding. [laughter] The agent's just take doing a very thorough job. [laughter] + +[`55:16`](https://youtu.be/IDSAMqip6ms?t=3316) Yeah, + +[`55:18`](https://youtu.be/IDSAMqip6ms?t=3318) agent SDK is cool though. + +[`55:20`](https://youtu.be/IDSAMqip6ms?t=3320) Yeah, agent SDK is cool. + +[`55:22`](https://youtu.be/IDSAMqip6ms?t=3322) Yeah, it's it always just feels amazing like how much we're able to build with such a small team. + +[`55:24`](https://youtu.be/IDSAMqip6ms?t=3324) Yeah. + +[`55:25`](https://youtu.be/IDSAMqip6ms?t=3325) So, I feel like + +[`55:26`](https://youtu.be/IDSAMqip6ms?t=3326) the other thing that's really cool is that I think people are just shifting their mindset from docs to demos. Like internally, our currency is actually demos. It's like you want people to be excited about your thing. Yeah, + +[`55:38`](https://youtu.be/IDSAMqip6ms?t=3338) show us like show us 15 seconds of what it can do. + +[`55:42`](https://youtu.be/IDSAMqip6ms?t=3342) And we find that everyone on the team now has this kind of indoctrinated + +[`55:45`](https://youtu.be/IDSAMqip6ms?t=3345) demo culture for sure. And I think that's better because + +[`55:49`](https://youtu.be/IDSAMqip6ms?t=3349) there's a lot of things that you might have in your head that if you're a great writer, maybe you could figure out how to explain it, but it's just even then it's just really hard to explain. But if someone can see it, they like get it immediately. And I think that's happening for product building, but it's also happening for like all sorts of other types of creative endeavors like making a movie for example. Like you had to pitch it, but now you can just be like I made this Sora video and like you know check like you can kind of see like like the glimmer of the thing you're trying to make for very cheap. And so that means you don't have to spend time convincing people as much. You can just be like here I made it. + +[`56:24`](https://youtu.be/IDSAMqip6ms?t=3384) Yeah. And and also as a builder like you can just make it and then like make it again and then make it again [laughter] until you're happy. Like + +[`56:31`](https://youtu.be/IDSAMqip6ms?t=3391) I I feel like that like the flip side is like you used to make a dock or you know like whiteboard something or you know like I I would draw stuff in like Sketch or Figma or whatever and now we'll just like build it until until I like how it feels. + +[`56:42`](https://youtu.be/IDSAMqip6ms?t=3402) And it's just like so easy to get that feeling out of it now. And I I think it's like you could see it visually before or you could describe it in words but it's like you could never get the vibe. And now like the vibe is really easy. + +[`56:53`](https://youtu.be/IDSAMqip6ms?t=3413) Yeah. And you built plan mode like three times. + +[`56:55`](https://youtu.be/IDSAMqip6ms?t=3415) Yeah. Yeah. + +[`56:56`](https://youtu.be/IDSAMqip6ms?t=3416) Because of this. + +[`56:57`](https://youtu.be/IDSAMqip6ms?t=3417) Like you you built it and then you threw it out and rebuilt it and then threw it out and rebuilt it. + +[`57:02`](https://youtu.be/IDSAMqip6ms?t=3422) Yeah. Or like Tudos's uh like Sid built the original version like also like three or four he built like three or four prototypes and then I prototype maybe like 20 versions after that like in like a day. Yeah. I think this is like a lot of pretty much everything we released there was at least a few prototypes behind it. How do you like um keep track of and carry forward the things you learn from prototype to prototype? And especially if it's like, you know, some one person is prototyping it and then you're like, I'm going to take it over. I'm going to do 20 more. Like how do you how do you maximize what you get out of that? You know, it's it's like there there's maybe a few elements of it. One is the style guide. So there's like some elements of style that we discover. And I think a lot of this is like building for the terminal or like we're kind of discovering a new design language for for the terminal and kind of building it as we go. Um, and I think some of this you can codify in a style guide. So this is our quad MD, but then there's this other part of it that's like kind of product sense where I don't think the model totally gets it yet. And I think maybe we should be trying to find ways to like teach the model this this kind of product sense about like this works and this doesn't, right? Because in in product, you want to solve the person's problem in the simplest way possible and then delete everything else that's not that and just get everything out of the way. So you kind of you you align the product to the intent as cleanly as possible. And maybe the model doesn't totally get that yet. + +[`58:24`](https://youtu.be/IDSAMqip6ms?t=3504) Yeah. It's never it doesn't really feel what it's like to use quad code. Like the model doesn't use quad code. + +[`58:31`](https://youtu.be/IDSAMqip6ms?t=3511) Yeah. Yeah. And so I think like when you know like quad code can like test itself and it can kind of use itself. Um and like we we do this when developing and it can see like UI bugs and things like that. I don't know maybe we should just try prompting it though. It could like honestly a lot of the stuff is as simple as that. Like when there's some new idea usually you just prompt it and often it just works. Maybe we should just try that. + +[`58:57`](https://youtu.be/IDSAMqip6ms?t=3537) A lot of the prototypes are actually the UX interactions. Um, and so I think once we discover a new UX interaction like shift tab for auto accept, I think uh Boris figured out. Um, then + +[`59:11`](https://youtu.be/IDSAMqip6ms?t=3551) that was Eigor actually. + +[`59:12`](https://youtu.be/IDSAMqip6ms?t=3552) Oh, Eigor. + +[`59:13`](https://youtu.be/IDSAMqip6ms?t=3553) Yeah, we went back and forth can like fit into that. + +[`59:16`](https://youtu.be/IDSAMqip6ms?t=3556) We did like dueling prototypes for like a week. [laughter] + +[`59:20`](https://youtu.be/IDSAMqip6ms?t=3560) Yeah, shift tab felt really nice. And then one of the the now current plan mode iteration um uses shift tab because it's actually just like another way to tell the model how agentic it should be. + +[`59:35`](https://youtu.be/IDSAMqip6ms?t=3575) And so I think as as more features use the same uh interaction, you form like a stronger mental model for what should go where. + +[`59:42`](https://youtu.be/IDSAMqip6ms?t=3582) Yeah. Or like thinking I think is another really good one. Like first we were like before we released quad code or maybe it was like the first thinking model was it like 37? I forget what the first one was. + +[`59:51`](https://youtu.be/IDSAMqip6ms?t=3591) Yeah. + +[`59:54`](https://youtu.be/IDSAMqip6ms?t=3594) But yeah and it it was like it was able to think and we're like brainstorming like how do we like toggle thinking? And then someone was just like what if you just like ask the model to think in natural language and it knows how to think and we're like okay sweet let's do that. [laughter] And so like we we did that for a while and then um we realized that people were accidentally toggling it. So they were like don't think and then the model was like oh I should think. it just started thinking + +[`1:00:15`](https://youtu.be/IDSAMqip6ms?t=3615) and so we had to kind of like tune it out so you know don't think didn't trigger it but then it still wasn't obvious but then we made a UX improvement to like highlight the thinking that + +[`1:00:23`](https://youtu.be/IDSAMqip6ms?t=3623) and that was like that was so fun and it felt really magical + +[`1:00:25`](https://youtu.be/IDSAMqip6ms?t=3625) when you do ultra think it's like rainbow or whatever exactly [laughter] and then with uh with sonet 45 we actually find like a really really big performance improvement when you turn on extended thinking um and so uh we made it really easy to toggle it because sometimes you want it sometimes you because you you kind of for a really simple task, you don't want the model to think for like five minutes. You want it to just do the thing. And so we used tab as the interaction to toggle it. And then we unchipped a bunch of the thinking words. Although I I think we kept ultra think just for like sentimental reasons. [laughter] It was such a cool UX. + +[`1:01:02`](https://youtu.be/IDSAMqip6ms?t=3662) Interesting. Do you think there's some there's some new metric that's about what you deleted? And I I think programmers have always felt like, you know, deleting a bunch of code feels really good, but there's something about because you can build stuff so fast, it becomes more important to like also delete stuff. I think my favorite kind of diff to see is a red diff. [laughter] This is the best whenever I'm like, "Yeah, bring it on. Another one. Another one." Um, but it, you know, but it's hard because like anything you ship, people are using it. And so you got to keep people happy. And so I think generally our principle is if we un ship something, we need to ship something even better. um that can kind of um that people can can take advantage of that that kind of matches that intent uh even better. Um and yeah, I think this is kind of back to like how do you measure like quad code and the impact of it and this is something like every company every customer asks us about and I think like in so internally at anthropic I think we like doubled in size since January or something like that but then productivity per engineer has increased like almost 70% in that time. um + +[`1:02:01`](https://youtu.be/IDSAMqip6ms?t=3721) measured by + +[`1:02:03`](https://youtu.be/IDSAMqip6ms?t=3723) uh I think we actually measured it yeah in a few ways but kind of PRs are the the simplest one and the main one um but like you said like this doesn't capture the full extent of it because a lot of this is like making it easier to prototype making it easier to try new things making it easier to these things that you never would have tried because they're way below the cut line. Um you're launching a feature and there's this kind of like wish list of stuff now you just do all it because it's so easy + +[`1:02:25`](https://youtu.be/IDSAMqip6ms?t=3745) and you just wouldn't have done it. + +[`1:02:27`](https://youtu.be/IDSAMqip6ms?t=3747) So yeah, it's really hard to talk about it. And then there's this flip side of it where more code is written. So you have to delete more code. You have to code review more carefully and you know automate automate code review as much as you can. There's also like an interesting like new product management challenge because you can ship so much that you end up it it ends up not feeling as cohesive because you could just like add button here and like a tab there and like a little thing here. Like it's just it's much easier to build a product that has all the features you want but doesn't have any sort of organizing principle because you're just shipping lots of stuff all the time. I think we try to be pretty disciplined about this and making sure that all the abstractions are really easy to understand for someone even if they just hear the name of the feature. We have this principle that I believe Boris brought to the team that I really like where we don't want a new user experience. Everything should be so intuitive that you just drop in and it just works. And I think that's that's really set the bar really high for making sure every feature is really intuitive. How do you do that with um a conversational UI? Because um you know when there's not a bunch of but buttons and knobs and it's just a blank text box to start, how do you think about making it intuitive? + +[`1:03:37`](https://youtu.be/IDSAMqip6ms?t=3817) Um there's a lot of like little things that we do like um we teach people that they can use the question mark to see tips. Um we show tips as quad code is working. We have like the change log on the side. um we tell you about like oh there's a new model that's out or like we show you at the bottom we have a notification section for thinking. I think there's just like subtle ways in which we tell users about features. I think the other thing that's really important is to just make sure that all the primitives are very clearly defined like hooks have a common meaning um in the developer ecosystem. plugins have a very common meaning in the developer ecosystem and just making sure that what we build matches what like the you know the average developer would immediately think of when they hear that + +[`1:04:25`](https://youtu.be/IDSAMqip6ms?t=3865) there there's this also this like progressive disclosure thing like you know to to any anytime in quad code when you run it you can hit control O to see like the full raw transcript the same thing the model sees and we don't like show you this until it's actually relevant so when there's a tool result that's collapsed then we'll say use control O to see it so we kind of we don't want to put too much complexity on you at the start because this thing can do you know anything. Um I think there's this other kind of new principle which we've just started exploring which is like the model teaches you how to use the thing and so you can ask quad code about itself and it it kind of knows to look up its own documentation to tell you about it but we can also go even deeper like for example slash commands are a thing that people can use but also the model can call slash commands and maybe you see the model calling it and then you'll be like oh yeah I guess I can do that too. + +[`1:05:13`](https://youtu.be/IDSAMqip6ms?t=3913) Yeah. Yeah. Yeah. Interesting. How has it changed like you know when you first started doing this cloud code was this sort of like singular thing this singular way of thinking about you know using AI through a CLI other people had stuff like this but it it felt like this shift and now there's a whole landscape of everyone is like going CLI CLI CLI like how has that changed how you think about building how it feels to build and how are you dealing with the sort of pressure of the race that you're in? I + +[`1:05:39`](https://youtu.be/IDSAMqip6ms?t=3939) think for for me like imitation is the greatest flattery. Mhm. Um, so it's like it, you know, it's it's awesome and it's just like it's cool to see all this other stuff that everyone else is building like inspired by this. And I think this is ultimately the goal is to kind of inspire people to build this next thing for this just incredible technology that's that's coming. And that that's just really exciting. Personally, I don't really use a lot of other tools. So, usually when something new comes out, I'll I'll maybe just try it to get a vibe. Um, but otherwise [snorts] I think we're pretty focused on just solving problems that we have and our customers have and kind of building the next thing. + +[`1:06:15`](https://youtu.be/IDSAMqip6ms?t=3975) Cool. Sweet. Um, I I loved this part of the interview, too. [laughter] + +[`1:06:22`](https://youtu.be/IDSAMqip6ms?t=3982) Did we answer all of your team's questions? + +[`1:06:23`](https://youtu.be/IDSAMqip6ms?t=3983) Questions? + +[`1:06:25`](https://youtu.be/IDSAMqip6ms?t=3985) Do Oh, did we get through all my team's questions? Let's see. Uh, I think we did. Um, uh, I'm curious also how you would answer like the unshipping question cuz also like if you're doing this kind of like AIdriven development, you ship a lot. You have a small team, so it's a lot of operational load. + +[`1:06:43`](https://youtu.be/IDSAMqip6ms?t=4003) The reason I asked that is because I don't think we do a good job of that. Um, and I have this feeling that some of the products are like a little bit messy because of that. And I think particularly for Kora, um there's just a big product surface area and it can do a lot of different things like it we have an email assistant so you can ask it like you know uh tell me about the trip I'm taking and it'll go through all your emails and you know summarize the the trip. Um or we have this feature that it automatically archives any email that you don't need to respond to immediately. Um, and then twice a day you get a brief that summarizes all the stuff that you probably need to see but you don't need to like actually do anything with and you just scroll through it and you're done. Um, and there's just like all this there's all this complexity that around you know for example how are emails categorized? So now we have a whole view of we have all these categorization rules and you can order them and whatever, but like it's just complicated and hard to communicate and and uh and I want to retain a lot of the like all the power and flexibility, but also you can't look at a screen and be like I have no idea what's going on. This is like way too complicated. So that's I'm just like I'm processing all that stuff. So the the kind of like deletion, you know, un unshipping idea feels like an interesting um cultural principle that we haven't really explored. + +[`1:08:14`](https://youtu.be/IDSAMqip6ms?t=4094) Yeah, it's really hard. I think there's like a social cost to it, too, where like you kind of want to be the person who tells your coworker to unship their thing. [laughter] + +[`1:08:24`](https://youtu.be/IDSAMqip6ms?t=4104) It's definitely tricky. It's more than just the code. Yeah, I I definitely learned this at Instagram honestly cuz I I think Facebook does a terrible job at unshipping and we had this problem where + +[`1:08:34`](https://youtu.be/IDSAMqip6ms?t=4114) every time we I think even like unshipping pokes was like really spicy cuz there's a bunch of these like old-timers. They're like, "No pokes, you're never going to take it away." But like if you look at the data, no one really uses it anymore. + +[`1:08:44`](https://youtu.be/IDSAMqip6ms?t=4124) But for sentimental reasons, they were kind of tied to it. + +[`1:08:47`](https://youtu.be/IDSAMqip6ms?t=4127) And so like for Facebook, it always maybe nothing ever got unchipped. It always got moved to like a secondary place like a, you know, like an overflow menu somewhere that no one looks at, like a graveyard. + +[`1:08:55`](https://youtu.be/IDSAMqip6ms?t=4135) Yeah. + +[`1:08:57`](https://youtu.be/IDSAMqip6ms?t=4137) And I think Instagram was just very principled. There was like, you know, very strong in a product and design point of view that was like, if this thing isn't used by like half of people, you know, 50% of WOW or whatever, we're just going to delete it and deal with it and then we'll figure out some next thing that's used by more people. + +[`1:09:13`](https://youtu.be/IDSAMqip6ms?t=4153) I love it. Um, well, thank you. This was amazing. I'm really uh glad I got to talk to you and uh keep building. + +[`1:09:18`](https://youtu.be/IDSAMqip6ms?t=4158) Thank you for having us. + +[`1:09:29`](https://youtu.be/IDSAMqip6ms?t=4169) Oh my gosh, folks. You absolutely positively have to smash that like button and subscribe to AI and I. Why? Because this show is the epitome of awesomeness. It's like finding a treasure chest in your backyard, but instead of gold, it's filled with pure unadulterated knowledge bombs about chat GPT. Every episode is a roller coaster of emotions, insights, and laughter that will leave you on the edge of your seat, craving for more. It's not just a show, it's a journey into the future with Dan Shipper as the captain of the spaceship. [snorts] So, do yourself a favor, hit like, smash subscribe, and strap in for the ride of your life. And now, without any further ado, let me just say, Dan, I'm + +--- + +## Sources + +- [The Secrets of Claude Code From the Engineers Who Built It — Every — YouTube](https://youtu.be/IDSAMqip6ms) +- [Every](https://every.to/)