Building Claude Code with Boris Cherny

23:08Boris Cherny:And I didn't want to build a UI. I just wanted to, you know, hack something up quite quickly because we didn't have cloud code back then. We're still writing code by hand. And I wrote this little batch tool that all it did was it hit the Anthropic API and it was essentially like a chat-based application, but just in the terminal because that's what AI used to be. And, you know, 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 think now when you ask non-engineers about like, what is AI, they would say it's this conversational AI.

23:48Boris Cherny:It's like a chatbot or something. And that's why I'm actually very excited for, you know, Cowork, this new product that we launched, because it's going to bring the same thing that engineers saw very early to everyone else. But when I think about, you know, co-work, 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. But we had to kind of figure out kind of what is the next thing. And so at the time I built this chatbot, it was somewhat useful, but it was just a chatbot. And the next thing that I tried was I wanted it to use tools because tool use just came out and I didn't know what it was.

24:27Boris Cherny:And I was like, let's experiment. And 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 actually didn't know if it could even do this, but I asked it like, what music am I listening to? And it just wrote a little Apple script program using like said or whatever to 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 field AGI moment very quickly after the first one. And the model just wants to use tools. That's just what I realized.

25:06Boris Cherny:This thing, 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 I think about the way that people were approaching AI encoding, 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, how do you want to interact with this model? What do you need it to do? Essentially, it's like, if you have a program, 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.

25:36Boris Cherny: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 its thing. Don't try to put it in a box. Don't try to force it to behave a particular way. One of the first ways you saw it was giving it tools, giving access to the bash and then later to the file system and then to more tools, right?

26:13That's right.

26:14Boris Cherny:Yeah, we give it bash, then I say we, it was just me the first three months, but then the team grew. So it was bash, it was, and file edit, that was the second one. And one of the interesting thing we talked about last time for the deep dive is when you built it and it started to actually write code with all the tools that you had, you've had an internal debate inside Entropic, should we just keep it to ourselves? because 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.

26:50Boris Cherny:Because when you think about safety, and 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, 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 it's kind of putting the model in a Petri dish and synthetically studying it in this way. And then you can study it in the wild and you can see how it actually behaves.

27:20Boris Cherny: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've been able to make the model much safer. So 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 I saw and what a lot of engineers saw is like, oh, Antrophic release, Cloud Code. Oh, wow. For the first release with, I believe it was with Sonet 4 release. Did it come out with Sonet 4 originally or Sonet 4.5? I think it was for, that was the general availability in February, but I think it was research preview before that.

27:58Yeah, but when it came out, my interpretation was like, oh, this thing can write code pretty well. And over time, it became a lot more capable. So 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 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 on the other hand, And like some startups have been trying to build developer tools deliberately to get adoption.

28:35And yet this research tool is getting a lot more adoption.

28:38Boris Cherny:I mean, this is a, you know, Anthropic, we're a research lab, we're a safety lab. And, you know, product is this kind of thing tacked onto 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's also this funny moment early on when we had this launch review and we were deciding whether to launch it. I remember this moment because we were in the room. I think there was like there was Mike Krieger, there was Dario, 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.

29:11Boris Cherny:It was just insane. It was, you know, like nowadays. It's 100 percent, right? Just 100 percent. Like nowadays, everyone at every technical employee at Anthropic uses quad code every day. It's pretty much 100 percent for non-technical employees. It's also like it's actually getting quite close to 100 percent. 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 yeah and they chose it you don't seem like the person who's active exactly forcing people to use your tool yeah yeah i mean the way we did it we just we launched the thing and then we just like listen 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 percent of the code and anthropic on average and you know it writes all my code for sure 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 reviewed that code for example so the switch was instant when we started using opus 4.5 this was before before it came out you know we were dogfitting it for a little bit and it was just right away it's such a more capable model i just found that i didn't have to open my ide anymore i just uninstalled my ide because because i just didn't need it at that point i actually did that like a month later because i i just didn't even realize that i wasn't using it anymore.

30:48Yeah, a lot of us had similar experiences once Opus 4.5 was out in the public, and especially over the winter break, 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 with, technologies I'm not as familiar with.

31:13Boris Cherny:Yeah, I'll be honest, it writes better code than I do. I don't want to go there. I still like to keep my pride, but probably true. Yeah, yeah. I realized this because also in December, I was traveling a little bit. I was on a coding vacation. We were talking about this before, but I went to Europe. We were just in a different time zone, kind of nomading around. And it was so fun because I was just coding all day, every day, which is my favorite thing to do. And I wrote maybe, you know, like 10, 20 pull requests every day, something like that. Opus 4.5 and Quad Code wrote 100 % of every single one.

31:44Boris Cherny:I didn't edit a single line manually. And I realized at the end of that month, Opus introduced maybe two bugs. Whereas if I'd written that by hand, that would have been, you know, like 20 bucks or something like that. Can we talk about your development workflow? You have written threads about this, which is awesome. It's on social media, on threads, and on X. But can you tell us how you use today a cloud code in terms of, you know, parallelism and tips and tricks that you and the team have kind of learned and share across the team? Yeah, I mean, look, there's no one right way to use quad code.

32:18Boris Cherny:So I can share some tips and things, but I think the wrong conclusion to draw would be to just copy these and use it. The way we build quad 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 engineer is - Same with workstation setup, right? Like a keyboard's monitor place, with all that ever has it differently. Yeah, it's like we're like graphs people, right? Like you choose your tools. Like we care deeply about it. So there's no one right way to do it.

32:49Boris Cherny: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. And usually all kind of round robin and start quad code in each one. Almost every time I start in plan mode. So that's like shift tab twice in the terminal. And I also overflow as I run out of tabs because there's only so many terminal tabs. I used to use web a lot for this, like cloud.aii slash code. That's the place that I overflow to. Nowadays, I actually use the desktop app. It's more convenient. So cloud code, you know, it's been in our desktop app for, you know, for many months.

33:25Boris Cherny:It's just the code tab in the cloud app. And I actually really like it because it has built-in work tree support. So that's existed for a while. And 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 Worktrees for you. So you get this kind of environment isolation. The reason I do that is I actually just really hate fiddling with Git Worktrees on the command line because it's kind of fiddly. Like you need to know the CD. And the Git Worktrees, for those who are not as familiar with it, it's when you can check out, instead of having a separate local folder, it's almost like checks out a separate branch, right?

34:02And then you can work on it separately but not have the complex only at like merge time.

34:07Boris Cherny:That's right. Imagine that you have a folder, but you have maybe like Git makes five copies of that folder in a way that's very cheap and kind of easy to throw away. So you get this kind of isolation. You can work in parallel and the clouds don't interfere. Yeah. So you now have support for this, which I think you recently added like native support. But like for your workflow, you just stuck with the old one of checking out on separate folders, right? Yeah, exactly. I actually find that over time I'm using the desktop app more and more for this just because I don't need these separate checkouts.

34:36Boris Cherny:and, you know, 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 native one, yeah. The native one, yeah. It's just like, it's the quad app, it's the code tab in the quad app and it's the same exact quad code. Except it runs in the cloud, right? It runs in the cloud. Yeah, so you have to kind of configure the environment. Lucky our environment's pretty simple. So, you know, and we just use hooks for it. So you just use the session start hook and configure it.

35:04Boris Cherny:This is kind of one of the benefits of making quad code really hackable is it's very easy to do this kind of configuration. And this is something, honestly, I would never have predicted because, you know, like 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 what I'm doing today. And you're using parallel agents. At what point did you start using them and how has it changed your work? because one thing that I noticed on myself, I don't really use that many parallel agents.

35:40I may be like two at a time, but I'm someone who, well, I like to be in charge and especially with Cloud. Cloud is a tool that you can follow it along. It tells you what it's doing. You can also have, for example, learn mode, which this was shipped a lot earlier where you can actually follow along. It gives you tasks. 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 do you feel you're losing any control or it doesn't really matter that much?

36:14Boris Cherny:Yeah, I think there's kind of like two modes to think about or kind of like two kind of workflows to think about. So when you're new to a code base, learn mode is awesome. Highly recommend it. For people that are onboarding to the QuadCode team, people that onboard to Anthropic, the thing that we recommend is, so you do, for people that haven't tried it, you do slash config in quad code, you pick the output style and you can do learn or explanatory. We usually recommend explanatory because that tends to be better for new code bases that you kind of haven't been in before. For me, once you're familiar with the code base, you just want to be productive, right?

36:49Boris Cherny:Like you just want to ship as much as you can and you want to kind of be effective doing that. So the world 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.5, I think it got there. With 4.6, it just really, really does it. Once there is a good plan, it will one-shot the implementation almost every time. 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 start one, I enter plan mode, I give it a prompt. As it's chugging along, I'll go to my second tab, 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.

37:26Boris Cherny:Then maybe I'll go back to the first one when I get notified that it's done. Do you have notifications on or do you turn them off? I actually operate in both modes. Sometimes I do focus mode on the Mac, so I just have it off. But also sometimes I use the system notifications. And you're very, very productive with PRs. I mean, I think it was very visible. Even around the holiday breaks on social media you actually were responding to i think someone reported a bug or a feature request i'm not sure which one it was and then an hour or two later it was done because because you did it you've also talked about like number of pull requests you've done on a day not to like show up but just as context what what does a pull 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 yeah pull requests each one varies a lot um sometimes it's a few lines sometimes it's a few hundred or a few thousand lines.

38:22Boris Cherny: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 top two, maybe top three, most productive engineers at Instagram just by volume of code written. Oh, wow. So I've always, you know, for me, I've always just coded a lot. Like this is 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 think with quad code, the kind of code that you write, if you are very productive, It tends to be even, it's just the number of PRs sort of undersells what's happening.

38:55Boris Cherny:Because 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 one-liner 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 dozens, some of them are one-liners. None of these are kind of code migrations because actually Claude just does those.

39:25Boris Cherny:And I don't need to be part of that. Shipping this much code or this much more productive, the obvious question that comes up for any 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. You make a pull request, you put it up there. There's a mandatory human reviewer at Google. There's actually two because there's one on code quality as well. How has this workflow changed? How does the PodCode team think about CodeReview and how has it changed over time? Yeah, I'll start by thinking, I'll start by talking about how CodeReview used to work for me.

39:58Boris Cherny:So the way that I used to do it is every time, I also used to be one of the most prolific CodeReviewers. Oh, okay. So both. Yeah, yeah. Right, or is it CodeReviewers? That's actually, that's one of the benefits of being in a different time zone. Like I'm not superhuman. I just didn't have any meetings. And 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 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.

40:27Boris Cherny:If someone did some bad react pattern or something, 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 row for it. So just automate it with kind of static analysis. And so that's what it used to look like. For me, I've always tried to automate myself away because there's just so many things to do. And this is one of our superpowers as engineers is we're able to automate all of the tedious work. There's very few other fields where you're able to do this thing.

40:56Boris Cherny:This is a thing uniquely that we're able to do. And this is a thing that I've just always enjoyed because it gives me more free time and I get to do the work I actually enjoy. And so today, the way this looks is a little different, but it mirrors this a little bit. So when Cloud Code writes code, 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 kind of verification. When we make changes to Cloud Code, Cloud will also test itself. So it'll launch itself kind of in a sub process. It'll verify itself and it'll test itself end to end.

41:29This is for your internal Cloud Code implementation. So you have like this test suite so they can test itself.

41:36Boris Cherny:Yeah, 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? Wow, okay. So it'll do this. And this is something that we just didn't code in. Like it just with Opus 4.5 especially, it just started spontaneously doing this. It just wants to kind of check. So we do this. And then we also run clod-p. So this is the clod-agent SDK in CI. So every pull request at Anthropic is code reviewed by clod code. And that actually catches maybe like 80 % of bugs, something like this. And it's the first round of kind of code review. Cloud will automatically address some of these.

42:11Some of them it'll leave to a human

42:13Boris Cherny:because it's not sure what to do. There's always an engineer that does the second pass of code review. And there always has to be a person in the loop approving the change. So 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 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 i think it depends how how it's used yeah i'd agree with that like you know if you're building some personal side project like you can just yolo street to maine you know like even even before ai you would have not reviewed you just trust yourself or you know just shipped up production or sss into production and do some changes, that kind of stuff, right?

43:05Boris Cherny:Exactly, exactly. The very first versions of QuadCode 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 Anthropic, 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 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 one thing that is just known about all limbs is they're non-deterministic and by putting the element as a reviewer cloud doing a review like it will give good feedback but how would you deal with the fact that you can't 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 to catch that?

44:00Are you doing anything 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 using, for example, are using linters on the code base or you found no need for it?

44:12Boris Cherny:Yeah, absolutely. Absolutely. Yeah, you want... This is just a... Yeah, we have type checkers. We have linters. We run the build. Cloud is actually so good at writing lint rules. So actually what I do now, I used to tally stuff up in the 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 something like this. You can do this in Claude code and it'll install the GitHub app, which then makes it so you can tag at Claude on any pull request, any issue.

44:45Boris Cherny:I use this every single day. So very, very useful. So you want these deterministic steps. Also, though, there are there are ways to get Claude to be a little bit more deterministic. So, for example, you can do best event. And you can have it do multiple passes. And this is actually quite easy to do. So, you know, for example, the code review skill that we use internally, it's open source. 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 deduping agents to check for false positives. But essentially, best event, the way you implement it is all you say is, quad, start three agents to do this.

45:23Boris Cherny:And that's it. Or just talks about building that enterprise infrastructure layer. the auth, 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 seasoned sponsor, WorkOS. If you're building any SaaS, especially an AI product one, then authentication, permissions, security, and enterprise identity can quietly turn into a long-term investment. SAML 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.

45:55But you don't have to. WorkOS provides these building blocks as infrastructure, so your team can stay focused on what actually makes your product unique. That's why companies like Antrofic, OpenAI, and Cursor already run on WorkOS. Great engineers know what not to build. If identity is one of those things for you, visit workos.com. And with this, let's get back to building Cloud Code with Boris. How does Cloud Code work in terms of architecture? So as an engineer, how can I imagine it's set up? But we covered some of this in 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.

46:33Boris Cherny:Yeah, yeah. It's very simple. Like, you know, there's not much to it. There's like there's a core query loop. There's a few tools that it uses. We delete these tools all the time. We had 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 2E part of it. and then there's actually a ton of different pieces around security and making sure that everything that Quadco does is safe and that there's a human in the loop for when it happens. And by safety, do you mean as a user when it's doing stuff on my computer or also as entropic monitoring use cases that could be deemed unsafe?

47:14Boris Cherny:Yeah, there's kind of a couple versions of this. 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 WebFetch. So CloudFetch is a URL and it reads the contents of that web page and then it does something in quad code.

47:47Boris Cherny: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. So we think about this in a number of ways. 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.

48:19Boris Cherny:And we just make the model try again. And then the third layer is for something like WebFetch, we actually summarize the results in using a subagent. 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 a layer. And by having a bunch of these different layers, it just reduces the probability a lot. One interesting technical choice that you also mentioned is using RAG or not, RAG retrieval augmented generation. And you mentioned how in the earlier version of Cloud Code, you use a local vector database to get some, to speed up search and you layer through this away.

48:59Can you talk about how this one, because this was another example where, I guess, did the model get better?

49:04Boris Cherny: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. Even something like the spinner in Cloud Code, I think it's gone through like 100 iterations, I want to say. Oh, 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 because 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.

49:35Boris Cherny:So for something like RAG, we tried a bunch of different approaches early on. So the first one was RAG for retrieval, because 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 and so the way i did it was it was like a local vector database i think it was like written in typescript and you just lived on the user machine and then i was using some like embedding model that was in the cloud to compute the embeddings before storing it and that worked like pretty good but there's a lot of issues with rag so for example i was finding that the code drifted out of sync.

50:10Boris Cherny: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. 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. And so we just decided like it was sort of working, but it also has a lot of downsides. And so we tried a bunch of other stuff.

50:42Boris Cherny:One of them was just using the model to kind of index everything recursively. That was kind of a cool idea. There was another version where we just tried glob and grep. We tried a bunch of different stuff. It turned out that agentic search just outperformed everything. And when I say agentic search, it's a fancy word for glob and grep. That's all it is. Nice. So the model both got good enough and you realize that it can use these tools pretty efficiently. Yeah. And this was, it was partially inspired, honestly, by my experience at Instagram. Because at Instagram, click to definition didn't work because the dev stack was just borked like half the time.

51:17Boris Cherny:And I think now it's better. And so what engineers learned to do instead is, let's say you're looking for the definition of the function foo. 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 foo per opening parentheses. And this worked pretty well. and it's funny because like this works for the model pretty well too. Interesting how one idea from one area can come to the other. One of the more advanced parts of cloud code that we also previously talked about is the permission system. Can you talk about what was complex about it and also you recently opened for sandboxing, right?

51:58Boris Cherny:Permissioning is really complex. 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. 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, some standard Unix utilities, we pre-allow because we know they're read-only because we know they can't expel tree data or anything like this. So 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 like system flags that you can use for this.

52:43Boris Cherny:Or even something like the sed 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. 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 these patterns are allowed, these patterns are not allowed. And so we let you define that, and we also check this allow list to make sure that it's safe. Yeah, and then you have this 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 the session or whatever it makes sense, or just globally allowed going forward, right?

53:22Boris Cherny: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 even be solved. And so there was actually a lot of pushback internally from safety teams because they were like, OK, like you can't just 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 brainstormed with Ben Mann and Ben was he started the labs team.

53:54Boris Cherny:He's one of the founders at Anthropic. he's actually he's the person that hired me to Anthropic we just came up with permission prompts as the way to do this you put the if you're not sure just ask the human and then they can decide no I want to ask you about how software engineering is done in general in terms of Anthropic 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 Anthropic has the same title member of technical staff why did this happen and what does this result in this kind of like everyone there are 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 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.

54:55Boris Cherny:They might be writing their own product requirements. They might be writing software and also, 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 think member of technical staff just kind of encodes this 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's a software engineer. And then I'm like, well, okay, I guess you're like, you're the coding person.

55:26Boris Cherny:And so 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 a way, it's kind of this like optimism built into the, built into the structure. I think it's also a glimpse of the future because 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 software engineering. And I heard this funny comment by Mark Andreessen, how he said that there's this Mexican standoff happening in the tech world where the designers are saying that they're actually now doing like PM and engineering work.

56:10The engineers are saying that we're doing design 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. But 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 you've said.

56:28Boris Cherny:I remember back in June or July of last year, I walked into the office and there's a row of data scientists that's right next to the quad code team, at least at the time. And I walked in and our data scientist for the quad code team had quad code up on his monitor. And he was using it. And I was like, this is interesting because you're a data scientist. Did you like, why are you using a terminal? Like you didn't have Node.js installed because we depended on Node.js back then. I was like, are you dogfooding it? Are you just trying to figure out how this thing works or something? He's like, no, no, I'm using it to run queries.

57:03Boris Cherny:He was just using it to run SQL. And it had little ASCII visualizations in the terminal. And then the next week, the entire row of data scientists had quad code running on their computers. And this expanded. And so if you look at the team today, on the quad code team, everyone codes. The engineer's code, our engineering manager codes, designer's code, data scientist code, 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 code base. You can just like dive in and kind of make small changes quite easily.

57:43Boris Cherny:But I think another thing is people are able to use quad code to do their jobs more, whether it's, you know, financial forecasts 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 Kat, who was talking about, she is, I guess, the title is the same, but people might gravitate for a role a little 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 Entrophing.

58:15And PRDs, 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.

58:30Boris Cherny:Some of this, I think, is because Anthropic is still, you know, it's still a startup. So 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. But yeah, also part of it is, you know, like Kat used to be an engineering manager. She's extremely technical. And I think this is the way that, you know, our product team thinks about it too, is, you know, better just send a PR. You're doing a lot of prototyping instead. So like that's also something where when we talked about how you were building CloudCode early on, you were showing actually you had a whole thread about the number.

59:02I think you did like 15 or 20 prototypes for the to-do list and all of them interactive, working. And what surprised me compared to my past experience, and you said that, well, you did this in like a day and a half, 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. So like, are you seeing this? Is there an increase in prototyping and building and showing instead of writing things?

59:30Boris Cherny: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 reflect back on the time before, because I think now just prototyping everything is so baked into the way that we build. Just everything is prototyped multiple times. Like, you know, we launched agent teams earlier this week. This is our implementation of swarms. It's very exciting because it just lets Claude do more work for longer, more autonomously. You have a bunch of different uncorrelated context windows, and you have this kind of communication between agents. They can just do more.

1:00:02Boris Cherny:This is something that Daisy and Suzanne and other folks on the team and Karen, 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. 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 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's very hard to course correct you can only take so few shots But now it's changed.

1:01:06Boris Cherny:The cost of building is very low, 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. And I get feedback from others as well sometimes. times. That's right. It's like, I have to try it myself and then I have to see what others think because, you know, my intuition does not always match others.

1:01:36When you were showing these prototypes of just how 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.

1:02:06Boris Cherny:Yeah. And there's a lot of examples of this. Like we launched this kind of condensed view for file reads and file search just because 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, 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 so much effort to make that feel really good and clean. We rolled it out to employees at Anthropic for about a month and we had everyone dogfooded and I fixed another probably dozen bugs, dozen tweaks based on all this feedback.

1:02:40Boris Cherny: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. And so on the GitHub issue, I was just going back and forth with people to be like, you know, like, what don't you like and people give 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'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 get it right some of the time.

1:03:08Boris Cherny:We have to learn from our users. We want to hear from people so we can get it right. Do you use ticketing systems for your work where, you know, where you capture like, all right, here's the work I want to, or do you just pretty much do the work as it comes in? So at Anthropic, we leave it up to teams. On the Quadco team, we leave it up to every person. Different people use this differently. For example, I don't use a ticketing system. Some people like to use Asana or Notes or something like this. One of the coolest things that I saw, this was maybe like three months ago or something, we launched plugins.

1:03:38Boris Cherny:And the way we launched that is Daisy for a weekend. She had a very early version of Swarms and she let the Swarm run and she told her, your job is to build plugins. You have to come up with a spec. Then you have to make an Asana board and split up into tasks. And then all the different agents have to build it. And 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 a hundred tasks on the Asana board and then they implemented it. And that's pretty much the version of plugins that we shipped. These kind of coordination systems they used to be for humans, but I think nowadays it's just as much for models.

1:04:17Boris Cherny:Let's talk about Cloud Cowork. It's one of the very impressive things about us. It looks great. So I tried it out. It's inside Cloud. You have the Cowork tab there and you can, I feel it's a lot more visual way of running agents, interacting with them. One of the surprising things I heard that it was built in 10 days. Can you take us through like what it took to build it and what does it actually mean? Was it from the idea or like from the decision of building it and how big was the team building it? 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.

1:04:54Boris Cherny:The reason we felt this is for a long time, people that were using quad code are non-engineers. 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 QuadCode to monitor his tomato plants. I just I love this. It was like get like a webcam set up and the quad was like, oh, my God, I'm so happy that our plant is budding. And because it had like a webcam and just like every day was like monitoring it.

1:05:28Boris Cherny:And it was so happy that the tomatoes were growing. There was someone that was using QuadCode to, you know, recover photos off of a corrupted hard drive. And it was like his wedding photos. Wow. You know, like I said, our entire finance team at Anthropic uses QuadCode. Our sales team uses quad code. So there's just all these people that are non-engineers that were using it. And at that point, quad code is available in a lot of form factors, right? Like we started in a terminal, then we expanded and we added support for IDEs. So we have extensions for, you know, every VS Code-based IDE, every JetBrains-based IDE.

1:06:02Boris Cherny:There's also iOS and Android apps. There's the desktop app. There's web. So then there's like Slack and GitHub apps. So we kind of expanded to all these places to make quad code easier for engineers. But ultimately, none of these are built still for non-engineers. And so quad 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 of 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 at some guardrails?

1:06:35Boris Cherny:So, for example, co-work ships with a virtual machine. this is one of the many ways that we make sure it's really safe especially for non-technical 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 until end or something it was just fully built with quad code and then we shipped it and can you give us a sense of like the complexity behind an app like this and 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?

1:07:08That's, you know, like, I don't know, like a few hundred lines of code. I'm just being obviously I'm provocative here or behind the scenes. It's actually a 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 work there and I know it's really, really complex because you don't see a lot of the complexity. There's a lot of regional things. There's a lot of backend things that are all hidden. So just from looking at it, Cloud Co-Work, it's hard to tell how much of this 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 model.

1:07:41Boris Cherny: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 because it's just the Cloud desktop app. So, you know, you download the Cloud app. 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're 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 non-technical and so we just want to make sure they have a good experience.

1:08:16Boris Cherny: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 level integrations to make sure people don't accidentally delete things.

1:08:47Boris Cherny:So just around safety, there's a lot there. And then we also have to rethink the permission system because we inherit the permission system from quad code. But also for Cowork, actually a big part of the value is not just running locally, but it's using all of your tools the way that QuadCode uses it. But the thing is, for non-technical 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 Cowork 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 project management for the team.

1:09:21Boris Cherny: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 Asana 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 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.

1:09:51Boris Cherny:And then it'll just start messaging engineers in Slack. And it just one-shots it. There's like one engineer's name for some reason it can't autocomplete. But 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 feels smooth. And what's the tech side behind this? I assume a lot of it will be similar to the the cloud app but is it is it electron typescript those kind of things or something else 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-work he was a really early engineer on electron and he helped build it 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:10:46Boris Cherny:Yeah. So Windows coming soon. I think probably by the time this podcast comes out, we will have Windows support. We just wanted to start early and start learning, you know, like everything we do at Anthropic, 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.

1:11:20Boris Cherny:This is the way that we build a product. And so we always launch a little bit before it's ready. We did this for QuadCode. When we launched QuadCode, 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 QuadCode supports every single stack, you know, like Windows, whatever weird Linux distro you use, macOS, we support everything. And so for Cowork also, we just wanted to launch early. We wanted to start with Mac because that was just the starting point. But yeah, it's going to support everything.

1:11:50One thing you mentioned is getting feedback. I'm curious, both for Cloud Code and for Cloud Cowork, how do you go about things like observability, monitoring? When you're rolling out, do you use any feature flags? And I'm more interested in like, did you build custom tools for this or did you decide to use certain vendors? Because especially for observability, I'm sure that this is both important, but it also sounds like pretty high scale in terms of the number of users that we can derive or this will not be a small operation.

1:12:20Boris Cherny:Yeah, there's some off-the-shelf vendors that we use. There's some custom code that we use. So it's actually, it's a mix of both. There's nothing too surprising about it. There's one thing about Anthropic 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. And so, you know, like if someone reports a bug, 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. This is just very important to the way that we operate.

1:12:50For Co-Work, what kind of learnings have you had so far? It's been out for, I think, a few weeks now. Did you see something unexpected? Are you shaping the product based on feedback that you're getting?

1:13:02Boris Cherny:Yeah. 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 QuadCode first came out, it actually wasn't an overnight hit. This is something people think it was, but it was sort of a slow takeoff 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.

1:13:32Boris Cherny:It took a little while. For Coerc, it's a much steeper growth trajectory than QuadCode was at the beginning. So it's just been an instant hit. And that's actually been very surprising. 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 as I understand the idea with what Agent Teams, Agent Swarms, instead of single agent, you can have a lead agent and it can delegate to its different teammates. How do you start experimenting with this? and how did you decide to ship it now?

1:14:07Boris Cherny:We're always doing experiments, right? There's all sorts of ways to get more mileage out of quad code. One way you can do it is by extending context. Another way is auto-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. 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. The idea is you have multiple context windows, but they essentially start fresh.

1:14:43Boris Cherny: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. And in this case, the second task knows about the first one because it's in the same window. But for something like a subagent, it's uncorrelated because the main agent prompts the subagent, but the subagent's 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, for example, like subagents versus skills.

1:15:12Boris Cherny:Because when you run a skill, you know, or a slash command, it sees the parent context window versus for a subagent, it doesn't. So it's uncorrelated. There's some cases where you want that context. There's some cases when you don't. 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. 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.

1:15:47Boris Cherny: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 improve with Opus 4.6 with Teams.

1:16:18Boris Cherny:And that's why we felt it's the right time to release it. We also wanted to be careful. And the reason you have to opt into it, the reason it's a research preview is it uses a ton of tokens because it's just a bunch of clods that are running. Not everyone wants this all the time. So just excited to see how people use it and to hear the feedback. It's something you want for fairly complex tasks. You don't probably want this for every task. The main clod decides the roles for the subclods. 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.

1:16:50Boris Cherny: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-size-fits-all. Have you seen use cases even in, even, I know it's still research, but have you seen use cases where it could look, it looks promising, this approach, this swarm approach? Well, you know, like I said before, plugins were fully built with swarms. There's a bunch of other features since that were built in this way. So, yeah, I think for anything where you see a single clod struggling, swarms can help.

1:17:21Boris Cherny:It's interesting to look at. talking about change in in general with andre carpenter 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 share the story about how you started to debug a memory leak the old-fashioned 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 ever really shifted. How did you, I guess, come to terms with this or start to embrace this change?

1:18:00This is something I really struggle with.

1:18:02Boris Cherny:The model is improving so quickly that the ideas that worked with the old model might not work with the new model. The things that didn't work with the new model might work or with the old model might work with the new model. And it's weird because there's just not a lot of other technologies like this. So 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, I'm using the word humility a lot, but you always just have to bring this kind of intellectual humility because just all of these ideas that were bad before are now good and the inverse.

1:18:45Boris Cherny:I think that's honestly it. it's something 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? Yeah, yeah. You should learn. This used, I mean, we used to call it 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 microservices? And someone said, we tried it and it didn't work. And if you tried it a year or two or three years ago, it was kind of valid, right?

1:19:14Because not much has changed.

1:19:15Boris Cherny:Yeah, that's right. That's right. And it's something like Microsoft. It's funny because it's like every 10 years it goes in and out of style. But yeah, 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 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 I do. 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 example of this is, you know, 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.

1:19:54Boris Cherny:But recently, Tariq, our, you know, our dev role guy, he actually codes a lot. He's amazing. And he just started automating this. So he's having like quad code generate its own videos 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 one thing that i i felt like just a bit like odd about and i think a lot of developers kind of 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.

1:20:36And I realized that I don't think I will handwrite the code when I want to get stuff done. 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 remember when I was learning, when I started from like kind of hacking around to go into university to learning C and C++, and it was just bloody hard. And actually, you know, going through 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.

1:21:11That'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 had talked with managers of what we need to screen for. And we talked 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 identity coding because 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 the sense of of grief how How did you think about it?

1:22:00Because again, you're an example of, you wrote so much code at Facebook, also outside of it. I know it was just a tool of doing it, but not many people could do what you did. And now the models can also work as good as you have, or if not better.

1:22:15Boris Cherny:That's the challenge. Yeah, I think 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 tools themselves. And at some point I kind of fell down this rabbit hole. I wrote this, like, I wrote, I wrote a book about, you know, a programming language. TypeScript. You were the first ever TypeScript book with O 'Reilly.

1:22:49Boris Cherny:Yeah, yeah, yeah. That's right. It was funny. Actually, there was this like, there was this amazing moment for me in my little town in Japan. And I went to the bookstore and I found that book translated in Japanese. No. In this tiny town. And that was just like the coolest moment. And then I actually realized I don't remember TypeScript at all because I was only writing Python for a couple of years at that point. Yeah. And like at some point I started the first, the biggest TypeScript meetup in the world. That was in SF. And I got to meet kind of a lot of my heroes. There was like Chris Kowal who wrote like general theory of reactivity.

1:23:19Boris Cherny:There was Ryan Dahl, the guy that made Node. One of the first times that I went really deep into this community and just the language itself and the tools themselves. And for something like TypeScript, there's this beauty in the type system because Heilsberg is just brilliant. The idea of conditional types and just anything can be a literal type. And 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 Anders just took it and he pushed it much further than it 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.

1:24:04Boris Cherny:And I think for them, it was also very practical, right? Because they had these large on-type JavaScript code bases. How do you gradually migrate it to something typed? And you have to come up with these very beautiful ideas to do this. For me, Scala was another kind of rabbit hole that I fell into and 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's what matters is 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 an art to it for sure.

1:24:34Boris Cherny:But in the end, it's a practical thing. And in the end, this is a thing that we use to build things. And, you know, it's a means. It's a means to an end. It's not an end to itself. I think one metaphor I have for kind of this moment in time that we're in is the the printing press in you know like the the 1400s or whatever because at that moment it was actually quite similar right like there was a group of scribes that you know knew how to write. And it was, as I understand, of course, we never lived it. But as I imagine, it was a hard process to learn. You needed to learn. You needed to get the equipment.

1:25:11You probably needed some sponsorship or being selected. Yeah, yeah. 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 within the printed press came along. Yeah.

1:25:26Boris Cherny:Yeah. And at least in Europe, like you have to like a lord or a king or something 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 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? And so the cost of printed material went down something like 100x over the next, I think, 30 years, 50 years or something.

1:26:02Boris Cherny: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 went up to something like 70%, but that took like another 200 years, 300 years. Because learning to read is just very hard. Learning to write is hard. It takes a lot of effort. It takes education system. It takes, you know, infrastructure to have paper and ink and the free time to do this instead of working on a farm. So it kind of it took early stage of industrialization to actually get there. 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.

1:26:41Boris Cherny:This is just, you know, like none of the things around us would exist today without this. Like if we weren't literate, if the people that built this microphone weren't literate, it would have just been very hard to have a modern economy. None of these things would exist. And 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 just feel like this is the best analog for the moment that we're in right now. And 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 they are employing software engineers because they themselves cannot write code.

1:27:29And I think we like to mock the CEOs who are coming there, coming to the team. 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. But there seems to be a bit of analogy 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 the king could actually read or write their own letters, they wouldn't need that middleman.

1:28:03And things become more efficient. I mean, of course, for the scribe, it's not the best news necessarily, but smart scribes can also do. So someone needs to write the books, run the press, et cetera.

1:28:14Boris Cherny:Yeah, exactly. 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 expanded a ton. And I guess also if we think about like back then, a scribe'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 they could imagine. There's new careers that exist because of that. Yeah. I love the analogy. And the most exciting thing for me is it's just so impossible to say today what will happen after this happens.

1:28:56Boris Cherny:and after this transition happens, just, you know, the economy, as we know it, would not have existed without it. So what's next? Like, what is the thing that we can't even predict today that will exist because anyone can do this? 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 Centrofic, who are software engineers 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 how have they changed the way they work?

1:29:34Boris Cherny:It's hard to name individuals because honestly, this is just the strongest. 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. So take something from zero to 0.5. Just, you know, figure out like, what are some cool ideas? What did the technology unlock? There's other people that are amazing at finding product market fit. So kind of 0.5 to 1 or maybe 0 to 1. There's other people that span different disciplines. And I'm just seeing more and more of these people. Like I said, like people that span product engineering and infrastructure engineering or, you know, product and design or design and engineering.

1:30:11Boris Cherny:I think I'm just seeing a lot more of these of these hybrids. What's a belief that changed from last year to this year? Something that, you know, like you either believed or a conviction that you had that you've either revised or completed through away? I think one thing I wasn't sure about is how big a problem is safety, to be totally honest. I joined Anthropic because, like I said, I read a lot of sci-fi and I know how bad this thing can go if it goes bad. It wasn't something I was sure about, 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.

1:30:50Boris Cherny:So I think 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? I think it's safe to say you were a really great software engineer even before all the AI things started. And you seem to be a very productive engineer, of course, part of the team as well, but also individually. What are some skills of like, before being a software engineer that are still as valuable or maybe even more valuable than before? And what are ones that are maybe just not as much and they're best left behind? Probably, okay, so the stuff that's left behind is maybe like very strong opinions about like code style and languages and things like this.

1:31:33Boris Cherny:Like I can't wait to get past like these endless language debates and framework debates and all this 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 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. But it also matters for engineering day-to-day, something like debugging.

1:32:05Boris Cherny:You just have to be very methodical about it. And the model can do this and it can help a lot. But I think still we're in this transition point where you still need to have the skill. I don't know if you're still going to need to have it in six 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 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.

1:32:56Boris Cherny:Like it's people are going to become more and more multidiscipline and this will become more and more rewarded. So in some ways, I think this will be the year of the generalist. I think the other skill that's actually been rewarded a bit is having a short attention span. I was being rewarded now. Oh, yeah. It's, you know, like teenagers are using, you know, like TikTok and all this stuff. And I think in some ways it's kind of dangerous for society because like you want people that can think deeply and can contemplate ideas and 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.

1:33:33Boris Cherny:It's like the year of ADHD. Because the work for me has become jumping between quads. It's become managing quads. 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. Could I add that from what I understand, what all you said, maybe we could add one thing, which is adaptability. Because you're saying, of course, that ADHD and you can jump across. But of course, earlier, you were 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're just kind of very open to adapting your working style and seeing what works well for this stage, especially when things are changing.

1:34:16I 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? Yeah. And as closing, what's a book or books that you would recommend?

1:34:28Boris Cherny:I've gone down a Xi Jinping rabbit hole. So he's the three-body problem guy, but he actually has like a lot of other really great books. I really love his short stories. 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, I really love Accelerando by Strauss. This is a book I would totally recommend. It's like essentially the product roadmap for the next 50 years. It starts with takeoff kind of starting to happen and kind of AI singularity. And then it ends up with like these kind of like group lobster consciousnesses orbiting Jupiter.

1:35:04Boris Cherny: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 Scala, 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. 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.

1:35:36Boris Cherny:And it's just amazing. 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. Boris, thank you so much. This was awesome. Yeah. Thanks, Gergay. This was a really interesting conversation. And the thing that I keep coming back to is to Boris's printing 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 printing press is arriving.

1:36:10But 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 pull requests a day without editing a single line by hand.

1:36:43And there are different verification systems in place. Clock code reviewing its code, automated lynch 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 see you in the next one.