Building Claude Code with Boris Cherny

And the teacher was like, what's going on? Eventually, she realized it. She was like, OK, you get away with it once and knock it off. But for me, it was very practical. So, you know, in school, I studied economics. I actually dropped out to start 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 make useful things. This startup, 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 dispensaries, 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. And then I actually got more interested in, 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. And I was the first hire of this YC startup up in Palo Alto after. How did you decide to go to one startup after the other? Kind of vibes. Vibes, I'd say. Because, you know, like, you know. 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 always try a thing, but the idea is always a hypothesis. And then almost always you have to pivot once, twice, three times.

You know, at this 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 clinical decision protocols that vary a lot, hospital or hospital. And our idea was there was one hospital in Chicago that had a really great protocol specifically for cardiac symptoms. outcomes and so we're like wouldn't outcomes be great if every hospital in the u.s 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 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 like the internet explorer six days that's what hospitals were using and i wrote this like SVG render because it was this visual decision tree and we launched it and then we had a DAU chart and the DAUs 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 Palo Alto we were piloting it with

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 this. And I realized that actually doctors don't have time to sit down and use a computer because you're seeing a patient. Then you have maybe five minutes until the next patient. And in those five 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 three minutes. Then you open up in our 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 five minutes are up you don't even have time to use it and so we reroute 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're like okay so maybe the doctor isn't the target user actually we want it 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 hypotheses you you follow it down 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 sort of 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 the 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 You're not using it, getting ideas.

I feel this is what makes a great software engineer back then and even today. It doesn't seem to me that you were focused on the technology. You were focused on the outcome, no? Yeah, I mean, look, there's different kinds of engineers and there's different ways to do it. And even on our team right now, I look at an engineer like Jared Sumner 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 SonarCube. As a critical verification layer for the AI enabled world, Sonar ensures that speed and volume with AI does not compromise your code base. 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 a SonarCube MCP server. This tool acts as a universal translator between AI applications and the SonarCube platform. By using the model context protocol, it gives AI tools like Cloud Code, GitHub Copilot, and Cursor direct access to SonarCube's analysis capabilities. Instead of context switching, your AI agent becomes a full-fledged code review and quality assurance copilot capable of analyzing code snippets 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 agenda 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 slash 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 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 was very practical, right? Because it's like, when you're in this kind of setup, you have to do the engineering, you have to do kind of the accounting, you have to do 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 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 do you take away from that that experience yeah so i started on facebook groups that was the first time i worked on uh vlad kolesnikov uh hired me i think i think he's actually still a 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 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 which was the software it was the framework that powered ads manager which later became react.js i kept crossing paths with these people and later on for yeah later on there was a bunch more people like this but anyway so i was working on facebook of groups. I was really excited about it 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. And honestly, I was always kind of embarrassed about it because I thought it was this nerdy thing. And I thought it was kind of 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 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 some way. So I worked on Facebook groups for a while. And then, you know, there's a bunch of different projects. I have to kind of get into details for any of these. Eventually, I became the tech lead for Facebook groups and kind of grew into this. And the org grew. The work really changed. It changed from kind of building to a lot of like doc 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 gonna 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 nara and i was like where's that and uh nara is like rural japan and this was a different time zone as well different time zone yeah this was 12 hours or something different or something like that something like that yeah it was like 2021 and then I tried to kind of find a team that would sponsor me because 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 co-located with and so on and so there was a little kind of nascent team for Instagram in Tokyo and Will Bailey was running this team he was also the guy that made Instagram stories and so he was my manager for a while and so we decided to grow that team together and I worked remotely from Nara and then most of the team was in Tokyo and uh during this time 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 and react it was just amazing there's no other dev stack 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 fork of, you know, the Cython runtime and just nothing really worked. And so I came to Instagram, I joined the labs team, you know, 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'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 graphkill and uh these projects 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 yeah with with these tools that we have, the AI tools.

And migrations are a pretty good use case for them, though. Yeah, it's like the, it's the perfect use case for it. And then 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 DevInfra and kind of leading a bunch of these migrations. That's also where I intersected with Fiona Fung, who is now the manager for the QuadCode 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 also started working on code quality.

And so the work on Instagram kind of expanded a bit. And 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 was this program called Better Engineering.

And then you joined Anthropic. And I've heard the story, which you can confirm or give more color to it, that your first pull request was rejected by Adam Wolf. He was my ramp-up buddy. So I joined Anthropic. I was trying to figure out kind of like what to do next. And, you know, 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. 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. That's definitely my genre. I'm a big reader. I have a 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 can we do to make this thing go better. So when I joined Anthropic, I did a bunch of ramp-up projects, just various stuff that I was hacking on. And I wrote my first pull request by hand because i thought that's how you write code that used to be how you write code that used

to be how you write code but even at the time at anthropic 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 a research code it was not 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.

But then it sped out a working PR. It just one-shotted it. And this was like 2024, It's like September 2024 or August, something like that. And I think for me, this was my first field AGI moment at Anthropic because I was just, oh my God, like I didn't know the model could do this. Like I was used to these like kind of tab completions, line level completions and 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 a 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 Statsig 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 Atlassian use Statsig. Statsig has a generous free tier to get started, and pro pricing for Teams starts at $150 per month. To learn more and get a 30-day enterprise trial, go to statsig.com slash pragmatic.

And with this, let's get back to Boris and the origin story of CloudCode. And then when you joined Entrofic, we've covered this in a deep dive, but we could recap briefly on how CloudCode came to be out of what seemed like a side project or just a cool hack. So yeah, I started hacking on a bunch of different stuff. I was working on some things in product. I worked on reinforcement learning for a little bit just to kind of understand the layer under the layer at 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 work at the layer that you actually work at.

This was the advice 10 years ago. It's still the advice today. 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. Yeah. Now it's like, understand the model. So I was hacking on a bunch of different stuff. Something shipped, something didn't ship. And at some point, I just wanted to understand the public anthropic API because I'd never used it before.

Yeah, we give it, 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 uh and and file edit that was the second one 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 tools that you had you've had an internal debate inside and traffic 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 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.

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 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 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, Antroflik released cloud code. oh wow this you know for the first release with uh i i believe it was with sonnet 4 release was what did it come out with sonnet 4 originally or sonnet 4.5 i think it was it was for that was the general availability in february but i think it was research preview before that yeah 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, like, some startups have been trying to build developer tools deliberately to get adoption, and yet this research tool is getting a lot more adoption. I mean, this is, 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 was this, 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. Like since we released it, it was just insane. It was, you know, like nowadays.

It was 100%, right? Just 100%. Like nowadays, everyone at, every technical employee at Anthropic uses quad code every day is pretty much a hundred percent for non-technical employees it's also like it's actually getting quite close to a hundred percent 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 yeah and they chose it you don't seem like the person who's exactly forcing people to use your tool yeah yeah i mean the way we did it we just we launched a 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 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

happened to made you trust it 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 it came out. You know, we were dogfooting 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 id 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 yeah 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 or technologies I'm not as familiar with. 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 like on a 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 uh 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 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'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 I'll be right back.

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 the 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. But 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 Anthropic, 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 CloudCode work in terms of architecture?

So as an engineer, how can I imagine it's set up? 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. 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 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 TUI 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? 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 and 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 quad fetches a URL and it reads the contents of that web page and then it does something 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. 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. 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

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 the open source sandboxing, right? 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 you 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 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 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 the 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 plot 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 pushback 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 anthropic 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 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 antroffic 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 Antroffic 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 everyone just is figuring stuff out and 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, 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 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 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

software engineering and i've heard this funny uh comment by Mark Andreessen, how we 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. The 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 it easier for an engineer to do product work or for a product person to engineer work and so on.

So it's what you've said. 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 are you dogfooding 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 has like little like 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 engineers code, our engineering manager codes, designers 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. 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 cat who was talking about she is i guess you 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 entropic 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 some of this i think is because entropic 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 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 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 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. So like, are you seeing this? Is there an increase in prototyping and building and showing instead of writing things? 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. 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 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, 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, 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. 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. When you were showing these prototypes of just how the tasks were built, you were telling me that you build 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 share 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 you know you write 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 dog fooded and I fixed another probably 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. And so on the

githubishi 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 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 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 as it comes in so at anthropic we leave it up to teams on the quadco team 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 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 launch plugins 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 that your job is to build plugins you have to come

up with a spec then you have to make a 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 clod in. Dangerous mode. And she let it run for the entire weekend. It spawned a couple hundred agents. They made a hundred tests 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.

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 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 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. 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 destroyer you use, macOS, we support everything. And so for co-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 what 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 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 this is both important but it also sounds like pretty high scale in terms of the number of users that we can derive or it's 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 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, 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. This is just very important to the way that we operate. For Cowork, what kind of learnings have you had so far 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 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 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. It took a little while. For CoWork, 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,

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, the 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 quad struggling, swarms can help. It's an interesting tool to look at. talking about change and in general with under carpet that 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 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? 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. 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. 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 this should learn this 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 microservice 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 Right. Because not much has changed. Yeah, that's right. That's right. And something like Microsoft is 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 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. But recently, Tariq, our, you know, our DevRel 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 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 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 realized that i don't think i will hand write the code when i'm get i want 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 i remember when i when i was learning when i started from like kind of hacking around to go into university to learning c and c plus plus and it was just bloody hard and actually you know going through my first few jobs where i started to become better at it 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 would 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 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 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 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 you did and now the models can also work as good as you have, or if not better. 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 a book about, you know, know a programming language type script you were the first ever type script uh book at with o'reilly yeah yeah yeah that's right um it was it was funny actually there was this like there's this amazing moment for me in my little town in japan i went to the bookstore and i found that book translated in japanese no in this tiny town that was just like the coolest moment and then i actually realized i don't remember type script at all because 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 type script meetup in the world. That was in SF. And I got to meet kind of a lot of my heroes. There was like Chris Colwell, who wrote like general theory of reactivity. 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 like, he's just brilliant. Like the idea of like

conditional types and just like 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 than it had been pushed and you know like Good job. 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 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 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'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 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

what's next like what 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 centrophic 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 and how have they changed the way they they work 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 um so take something from zero to point five just you know figure out like what are some cool ideas what is the technology and walk. There's other people that are amazing at finding product market fit. So kind of 0.5 to one or maybe 0 to one. 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. 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 or a conviction that you

have 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 um 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 So the new risks that have arisen in the last year, it just makes me much, much more worried about it. 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 a team as well, but also individually. Julie, what are some skills of like, you know, 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, OK, so the stuff that's left behind is best left behind is maybe like very strong opinions about like code style and languages and things like this. Like 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 thing is 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. 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 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 like it's people are going to become more and more multi-discipline 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 rewarded of it is uh having a short attention span i was being rewarded now oh yeah it's uh you know like people you know like teenagers are using you know like like tiktok 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 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 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 But 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.

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? Yeah. And as closing, what's a book or books that you would recommend? I've gone down a Xi Xin Liu 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. 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. 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. 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 pull requests a day without editing a single line by hand and there are different verification systems in place clock 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 see you on the next one.