Building Claude Code with Boris Cherny

What happens when you join one of the top AI labs in the world, and your first pull request gets rejected, not because a code was bad, but because you roll it by hand. This is exactly what happened to Boris's journey when he joined Antropic. Boris is a creator and engineering lead behind Claude Code. Before joining Antropic, he spent seven years at meta where he left Gold Quality Cross, Instagram, Facebook, West Admin, Messenger, and was one of the most prolific code authors and code reviewers at the company. In today's episode we cover how Claude Code went from a side project to one of the fastest growing developer tools and the internal debate on the traffic, whether it's to release it at all.

Boris's daily workflow of shipping 20, 30 pull requests a day with zero hand written code and how code review works when AI writes everything. Why Boris believes we're living through a time-ass transformative as a printing press, and which engineering skills matter more now, and which ones do not? If you want to understand how one of the people closest AI coding agents actually build software today, and what that means for the rest of us engineers, this episode is for you. This episode is presented by Statsig, the unified platform for flags, analytics experiments, and more. Check out the channel to learn more about them and our other season sponsors, Sonar and Workless.

How did you get into tech, software engineering, and coding in general? It starts a while back. I think there was two terrible paths that crossed. So when I was maybe 13 or something like this, I started selling my old Pokemon cards on eBay. I realized that on eBay, you can actually write HTML.

I was looking at other people with Pokemon card listings, and I realized some of them have big colors and fonts and stuff like this. Then I discovered the Blink tag. I really was a Blink tag. If I put the Blink tag on it, I could sell my card 99 cents instead of 49 cents or whatever. I learned about HTML this way, then I got an HTML book and learned about HTML.

The second thing was this was also, I think, sometime in middle school, we had these old TI-83 graphing calculators, and we used them for math. I realized I can get a better answer on the math test if I just program the answers to the math test into my calculator. I wrote these little programs. These program the answers, and then the test got harder, so then I had to program the solvers instead of the actual questions because I didn't know what the coefficients and stuff would be ahead of time. Then the math got more advanced the next year. So I had to drop down from basic to just make the program run a little bit faster.

Oh, I was going to high school. You dropped out to assembly. I think it's like middle school or high school. It would be like eight or nine three or something like that. Then the thing I realized is everyone in my class was starting to realize that I had a solver and they got a gel list.

I bought this little serial cable so I can give it to them too. The next math test everyone on the class just got is, and the teacher was like, what's going on? And then she realized it was like, okay, you get away with it once and knock it off. For me, it was very practical. So 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 sort of, 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 a website. We called different dispensaries, I think. And then we just tried to get weed samples so we could 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 testing this stuff.

And so I got into the chemical testing and chemical analysis. And then after this, I did a bunch of other startups and then I joined YC pretty early. And that was the first hire of this YC startup up in Palo Alto after. How do you decide to go to one startup after the other? Kind of vibes vibes, vibes I'd say. Because 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 thing, but the idea is always a hypothesis. And then almost always you have to pivot once, twice, three times.

At this medical software company, this is called Agile Diagnosis. This was kind of an early YC company. This was back in 2011, 2012, something like that. It was medical software for doctors. And the idea was there's these clinical decision protocols.

There's very a lot of hospital hospital. And our idea was there was one hospital in Chicago that had a really great protocol, specifically for cardiac symptoms. And so we were like, wouldn't outcomes be great if every hospital in the US would use the same protocol. And so we tried to standardize it. And we made this decision tree software for doctors to use.

And I wrote, you know, the software, it seems like it was just a few of us. It was a pretty small theme. And I wrote the software. It was in a web browser. And I remember this was back in the internet for six days.

That's what hospitals were using. And I wrote this SVG render because it was this visual decision tree. And we launched it. And then we had a DAU chart. And the use 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 a few hospitals including UCSF. And I wrote a motorcycle at the time. And so I wrote my motorcycle up to UCSF and I shadowed doctors for a couple days just to see how did 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 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 rewrote everything to run on Android. And they still weren't using it. And the thing we realized is doctors are walking around with a bunch of residents behind them. In this kind of situation, it's like a social situation. The thing that matters is they're seen as an authority.

They don't want to be seen on their phones. And then we pivoted again. So at that point we were like, okay, so maybe the doctor is in the target user. Actually, we wanted to be used by maybe nurses or X-ray technicians or something like this. At that point I left because I was like, this is actually pretty far off from what I wanted to do.

This is like the most fun thing for me is finding 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 can form hypotheses. You follow it down and you see what's right.

And also I find it so interesting how you're telling us this story. Because I feel behind a lot 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 were hired as a software engineer. And this was back before product engineers or anything was a thing which we're not 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. 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 be that you were focused on technology. You were focused on the outcome.

There's different kinds of engineers and there's different ways to do it. Even on our team right now, I look at an engineer like Jared Sumner. And he's just incredible technical mind. He understands this system is better than anyone I've met. And you need people like this. You need people with this kind of depth.

For me, engineering has always been a practical thing. And for me, I've always been a generalist. It doesn't matter if I'm doing design or if I'm doing engineering or use a research or whatever. The investment thesis for AI and software engineer 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 Kercer direct access to SonarCube's analysis capabilities. Instead of context switching, your AI agent becomes a full-fledged code review and quality assurance co-pilot, capable of analyzing code snippets for issues, filtering bugs by severity, and even checking your project's quality gates data before you ever commit code. Whether you're working with coding assistants or scaling up with full-agent workflows, Sonar provides the automated verification that 75% of the Fortune 100 rely on.

It's about giving your developers a 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 started freelancing.

And so I was like, okay, I guess I'll make websites. And I think fiber was not a thing back then. So there's some other freelancing websites. 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 engineering, you have to do 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 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 seven years. And what do you take away from that experience? Yeah, so I started on Facebook groups. That was the first time I worked on Vlad Kolesnik, of, I think he's actually still at Facebook. I think he's on some other team now.

And it was cool, actually, there's a big group of people that I worked with that were these kind of early JavaScript people. I did a bunch of JavaScript stuff and it's funny, I kept crossing paths with these people. And so Vlad, he worked on BoltJS, which was the software, it was the framework that powered ads manager, which later became ReactJS. I kept crossing paths with these people and later on, yeah, later on, there was a bunch more people like this. But anyway, so I was working on Facebook 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 credit 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 this thing that I knew how to do. But I wanted to be a cool kid and I couldn't tell people that I coded it.

It was very dirty. And at some point I discovered it was some programming community on Reddit. And I was just shocked. There's other people that are into this thing. It's such a weird hobby.

It's so niche. And it was just so exciting to find people like this and get this connection. And so I just wanted to work on this. I wanted to contribute to this in some way. So I worked on Facebook groups for a while. And then there's a bunch of different projects up to get into details for any of these.

Eventually I became the tech lead for Facebook groups. And the work grew. The work really changed. It changed from building to a lot of doc writing and coordination and kind of delegating the culture. The culture was changing at the time. So this early phase culture was disappearing.

The docs were coming in. The alignment meetings were coming in. There was 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. And that was also a funny story. My wife got a job offer. And she was just really excited about it. She came to me and was like, hey, I got this offer. But we're going to have to move. Is that okay?

And I was like, yeah, that's fine. You know, like a 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 NARA is like a rural Japan.

And this was a different time zone as well. Different time zone. Yeah. This was one hour or something. Different sort of something like that. Something like that. Yeah. It was like 2021. Wow. And then I tried to kind of find a team that would sponsor me

because there were these kind of arcane HR rules about 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 the same. She was also like 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 for NARA. And then most of the team was in Tokyo. And during the time I started Hakey on Instagram and the stack was just insane. Like Facebook was the single best web serving stack in the world.

The way that each, everything is optimized, like from the Hack language to the each VM runtime to GraphQL as a transport layer to like the client libraries like Reway and all the stuff. 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 the definition didn't work.

And it was this like kind of hack together Django and then like a fork of, you know, this icon runtime. And just nothing really worked. And so I came to Instagram. I joined the lab's team 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 in front because 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 GraphQL. And these projects, they're in progress. You know, like these are things that involve eight hundred of engineers many years into this.

It's a big cool base. It's a big migration. Now it's much faster. Yeah, with these tools that have AI tools and migration is a pretty good use case for them. Yeah, it's like 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 Dev in front of leading a bunch of these migrations. That's also very intersected with Fiona Fung, who is now the manager for the quad code team. I just worked with her and she was just such an amazing leader. This incredible depth and kind of history and 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 they 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 and Facebook, Messenger, WhatsApp, reality labs, kind of all these code bases. I met at it. It was this program called Better Engineering. And the idea was I think it's sort of like 2016 or 2018 or something.

But Zuck mandated that every engineer of the company 20% of their time has to be spent fixing tech debt. Oh, interesting. And we call this Better Engineering. And some of this is kind of bottom up where, you know, a team knows best the tech debt. They have to fix. And then some of it is top down where you need to do, you know, very big migrations.

You need to migrate to language features and frameworks, things like this. And at Facebook scale, you know, there was tens of thousands of these migrations over here. And so I just sort of we didn't call this. And I realized very quick that it just needed a little bit more order to it. There was no goals. No one knew kind of like what the outcomes were. There was any tracking. And so we developed a bunch of stuff.

One of the ideas was a centralized way to prioritize the different kind of code quality efforts. The second thing was figuring out the impact of code quality on engineering productivity, which turned out to be significant. How did you measure what you find there? There was a bunch of stuff I think some of this have been published. I don't know if all of it has, but essentially you try to do like causal analysis and causal inference.

This is a methodology. You try to figure out like what are the factors that make its own generators more productive? Some of it is code quality. Some of it is outside of code quality. So for example, meta went back to, you know, return to office instead of work from home.

Those were actually driven by this because we just found some, you know, fairly strong correlations that we thought were causal about this. But the quality actually contributes like, you know, double digit percent to productivity. It turns out even at the biggest scale. It's kind of comforting to hear because I think it's rare to have a place where you actually measure this, but I think we feel it. Like when you have a clean code base, modular, or it can get easier to work with. And I think, you know, reasoning could also be easier for LM to work with it.

And my hint would be yes, it should be, right? But I think there's just very little data. But that's a feeling that I would have. Yeah, I think a lot of the big companies I published about this. Like I think Facebook published something Microsoft publishes a bunch about this. Google does.

But yeah, totally. If every time that you build a feature, you have to think about do I use framework X or Y or Z? These are all options that you can consider because the code base is in a partially migrated state where all of these are around the code somewhere. As an engineer, you're gonna have a bad time. As a new hire, you're gonna have a bad time. As a model, you might just pick the wrong thing.

And then, you know, like the user has to work hard to do. So actually, you know, the better thing to do is just always have, you know, a clean code base. Always make sure that when you, when you start a migration, you finish the migration. And this is great for engineers and nowadays it's great for models still. And then you joined Introphic. And I've heard the story, which you can confirm or get more color to add that.

Your first pull request was rejected by Adam Wolf. He was my ramp up buddy. So I joined in the topic. 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 probably was just 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 stiferator. Like that's definitely my genre. I'm a big reader of like, you know, giant bookshelf at home and stuff. And I just know how bad this thing can go.

And I just felt like this is a place that has serious thinkers. People are taking this very seriously and thinking about what can we do to make this thing go better. So when I joined in the topic, I did a bunch of ramp up projects, just, you know, 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.

But even at the time, I don't think there was a thing called Clyde and it was the predecessor to Cloud Code. It was super janky. It was Python, you know, to like 40 seconds to start up. It was research code. It was not agentic. But if you prompt it very carefully and hold the tool just right, it can write code for you.

And so Adam rejected by 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's sped out a working PR. You just one shot at it. Oh, and this was like 20, 24, September, 2024, August, something like that.

And I think for me, this was my first field at H.I. moment. I don't think 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 for me.

So, I'm just going to talk about how he had a true WAMOOMENT at work using their AI model. A very different WAMOOMENT 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 of tooling for experimentation and feature flying 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 out gradually say to 1% or 10% of users at first. You watch what happens, not just data crash, but what did they 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 like Notion, Brex and Atlassian use Statsig. Statsig has a general street here 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 Cloud Code. And then when you joined Intraffic, we would cover this in a deep dive, but we could recap briefly on how Cloud Code 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 something, some products. I worked on reinforcement, running 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 have a little bit more levers to work with the layer that you actually work at. This was the advice 10 years ago, it's still advice today. But the layer under is a little bit different now. Before it was like, if you're writing JavaScript, understand the JavaScript, the Yam and framework and stuff, 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 and the topic API because I never used it before. And I didn't want to build a UI. I just wanted to hack something up quickly because we didn't have Cloud Code back then. We're still running code by hand. And I wrote this little bash tool that I always did was hit the Enthrop API.

It was essentially like a chappy application, but just in the terminal because that's what AI used to be. And I still think about it. 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 what is AI, they would say it's this conversational AI, it's like a chatbot or something.

And that's why I'm actually very excited for, you know, co-work this new product that we launched because it's going to bring the same thing that 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, Cloud Code originally wasn't Cloud 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.

I was like, what'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, 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 of this with Sonic 3.5. This is actually my second agent, field agent moment, very quickly after the first one. And the model just wants to use tools. That's just what I realized. Like this thing, like if you give it a tool, you 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 stop out some module, stop out some function and you say, okay, this is now AI, but otherwise the rest of the program is just a program.

And so this is just not the way to think about the model. The way to think about it is the model is its own thing. You give it tools. You give it programs that it can run. You let it run programs. You let it write programs, but you don't make it a component of this larger system in this way.

And I think there's just like, you know, this is a version of the better lesson. The better lesson is very specific framing, but there's many corollaries to it. This is one of the corollaries is just like the model do it's same. 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? That's right. Yeah, we give it a bash. Then I say we use this for three months, but then the team grew. So it was bash. It was a and file it.

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 the tool that you had. You've had internal debate inside and traffic. Should we just keep it to ourselves? Because suddenly it's right 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 that, 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. The reason it exists. If you ask anyone that anthropic why they chose it, it's because of safety.

And so if you think about model safety, you know, there's different layers, I would you think about it. There's kind of alignment and mechanistic interpretability. This is the model layer. Then there's evil and this is kind of like a kind of putting the model in a petri dish and statically 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 weren't 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 was like, oh, I'm trying to release cloud code. Oh, wow. This for the first release with, I believe it was with Sonat 4 release. Did it come out with Sonat 4? I think it was 4.

That was the general availability. And everybody was researching for 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 at the other hand, some startups have been trying to build developer tools deliberately to get adoption. And yet this research was getting a lot more adoption. I mean, this is a, you know, in the topic where we're a research lab where a safety lab and, you know, product is this kind of thing tacked onto the side. 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 my quicker. There was Mario. There was mother folks and everyone were deciding what should we do. We were looking at the internal adoption chart, which was just vertical.

It was insane. It was, you know, like, now it is just 100%. It was 100%, right? Just 100%. Like, now it is everyone at an ever technical employee on the topic uses quad code every day. It's pretty much 100%.

And on technical employees, it's also like, it's actually getting quite close to 100%. It's increasing very quickly. Like, you know, like half the sales team uses quad code. And I think that's increasing. It's crazy.

Dario had this question about like, how did it go 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, it's like, let people use the tool that they prefer. You don't seem like the person who's acting exactly forcing people to use their tool. Yeah. I mean, the way we did it, we just, we launched the thing and then we just like listened to the users and we talked to people.

We saw how they use it. We followed up. We made it better. And yeah, I mean, now we're at the point where quad code writes, I think, like, 80% of the code and the topic 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 would happen to me? You trust it to write your code? Or how much you trust it? How much you reviewed that code, for example?

So this was instant when we started using opus 4.5. This was before it came out. We were dog-fitting 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 ID anymore.

I just uninstalled my ID because I just didn't need it at that point. I actually did that like a month later because 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 public. 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. Yeah. I'll be honest, it's a better code than I do. I don't want to go there. I still like to keep my pride, but probably true.

Yeah. I realized this because also in December I was traveling a little bit. I was on a coding vacation. I was just talking about this before, but I went to Europe. We were just in a different time zone, no matting 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 10, 24 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 at the end of that month, opus introduced me two bugs. Whereas if I'd written that by hand, that would have been 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. Can you tell us how you use today, cloud code in terms of your parallelism and tips and tricks that you and the team have learned and share across the team? Yeah. I mean, look, there's no one right way to use quad code. So I can share some tips and things, but I think the wrong conclusion to draw would be to just copy, copy these and use it.

The way we build cloud code is we build it to be hackable because we know every engineer's workflow is different. There's no one way to do things. There's no two engineers that have the same workflow. It's just every engineer is the same. It's the same with workstation setup, right? Like a keyboard is monitored place.

But all that has a different way. It's like where it graphs people, right? You choose your tools. We care deeply about it. So there's no one way to do it.

So for me, the way that I do it generally is I have five terminal tabs. Each one of them has a checkout of their repository. So it's five-carole checkouts. And usually all kind of round robin and start quad code in each one almost every time I start in plain mode. So let's shift tab twice in the terminal.

And I also overflow as I run out of tabs because there's only so many little tabs. I used to use web a lot for this, so like quad.ai slash code. That's the place that I overflow to. Now it is actually the desktop app. It's more convenient. So quad code, you know, it's been in our desktop app for many months. It's just the code tab in the quad app.

And I actually really like it because it has built in a work tree support. So that's existed for a while. And that's what it's for parallelism. So you have multiple, you don't need multiple checkouts. You just have one and then we automatically set up Git work trees for you.

So you get this kind of environment isolation. The reason I do that is I actually just really hate fiddling with Git work trees on the command line. Because it's kind of fiddling. You need to know the CD. You need to know the good work tree for those who are not as familiar with it. It's when you can check out and instead of having a separate local folder, it's almost like checked out a separate branch, right?

And then you can work on it separately, but not have the complex only have like merge time. 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 on 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 a separate folder. Yeah. 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 and, you know, I just have a bunch of clouds running and I don't have to think about it. The other surprise hit is 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. It's just like, it's the quad app. It's the code tab and the quad app. And it's the same exact code.

Except it's like, it runs in the cloud, right? It runs in the cloud. Yeah. So you have to kind of configure the environment. Well, your environment is pretty simple. So, you know, and we just use hooks for it. So you just use the session startup and configure it.

This is kind of one of the benefits of making quad code really hackable. 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 quote on a computer. If you told me six months ago, I'd be writing, I don't know, a third, I haven't put the data to do like a third half, something like this on my code on a phone. That's crazy. But that's what I'm doing today.

And you're using parallel agents. What point did you start using them and how has it changed your work? Because one thing that I know is on myself, I don't really use that many parallel agents. I may be like two at a time, but I'm someone who 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 a task. 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 in control or it doesn't really matter.

Yeah, I think there's kind of like two modes to think about or kind of like two kind of work goes to think about. So when you're new to a code base, highly recommend it. For people that are onboarding to the quad code team, people that are onboarding to the topic, the thing that we recommend is so you do for people that haven't tried it, you do slash config in part 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 a code base, you just want to be productive, right? You just want to ship as much as you can and you want to be effective doing that.

So the role really switches. I don't really go deep into tasks anymore. I start a quad in plan mode. I'll have it kick something off. With open 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 together plan, right? So what I do is I start one, I enter plan mode, I give it a prompt as it's talking along, I'll go to my second tab and I'll start the second quad. I'll also play mode, get it talking along, then go to third tab, go to the fourth one. Then maybe I'll go back to the first one when I get notified that it's done. And then I'll do it on or turn them off.

I actually operate in both modes. Sometimes I do focus mode on Mac, so I just have it off. But also sometimes I use this as notifications. And you're very, very productive with PRs. I think it was very visible. Even around the holiday breaks on social media, you were actually responding to someone reporting a bug or a feature request.

I'm not sure what one it was. And then an hour or two later, it was done because you did it. You've also talked about number of progress you've done on a day not to show up, but just as context. What does a pull request typically involve in terms of complexity? Are these are some super trivial or some actually larger pieces of work as well?

Yeah, but each one varies a lot. Sometimes it's a few lines, sometimes it's a few hundred or a few thousand lines. They're all just very, very different. It's changed so much. 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 for me, I've always just coded a lot. 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 just the number of PR sort of undersells what's happening.

Because I think people that used to be very productive in the old days before AI assistance, a lot of the code maybe was code migrations or something like this. So people that shipped 20, 30 PRs every day, a lot of it was like pretty, you know, like a one line or kind of migrating A to B or whatever. Nowadays, I ship 20, 30 PRs every day, but every part is 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 code migrations because actually cloud just does those. And I don't need to be part of that. Shipping this much code or this much more productive obvious question that comes up for any self-refreshional as well. So I'm not sure if Instagram did this, but a lot of other companies.

This is you make a full request, you put it up there. There's a mandatory human reviewer at Google. There's actually two because there's one on cool quality as well. How does this workflow change? How does the poll code team think about code review and how has it changed over time?

Yeah, I'll start by thinking. I'll start by talking about how code review used to work for me. So the way that I used to do it is every time I also used to be one of the most prolific code reviewers. Oh, okay. So both. Yeah. Yeah. Right. That's actually, that's one of the benefits of being in a different times.

I'm like, I'm not super human. I just didn't have any meetings. 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 someone named a parameter in a function that would put that in a spreadsheet.

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 tell me out the spreadsheet. And any time that a particular row had more than three or four instances, I would write a link for it. So just automate it with kind of something else. 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 were able to automate all of the tedious work. There's very few other fields where you're able to do this thing. This is a thing you need, 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 it. And so today, the way this looks is a little different, but it mirrors this a little bit. So when quad code writes code, it generally will run tests locally. And this is something called 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 quad code, quad will also test itself. So it'll launch itself kind of in a sub process. It'll verify itself and it will test itself end-to-end. This is for your internal quad code implementation. So you have like this test suite so they can test itself.

Yeah, that's right. But it'll literally launch itself just in a batch process and kind of just see like, hey, do I still work? Okay. So it'll do this. And this is something that we just didn't code in. Like it just was 4.5, especially. It just sort of spent seriously doing this.

It just wants to kind of check. So we do this. And then we also run quad dash p. So this is the quad agent SDK in CI. So every pull request item topic is code reviewed by quad code. And that actually catches maybe like 80% of bugs, something like this.

And it's the first round of kind of code review. Quad will automatically address some of these, some of them will leave to a human because it's not sure what to do. There's always an engineer that does the second passive code review. And there always has to be a person to 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 think I'm code review, would you do this for every type of project? Or this is specifically because you know that this actually has real world impact. People depend on it. There's a lot of users. Let me put it the other way around. Can you see places where you would just not have an engineer review code?

What's the issue? What would that be? I think it depends on how it's used. Yeah, I'd agree with that. If you're building some personal side project, you can just yolo straight to main.

Even before AI, you would have gone through. You just trust yourself or just shipped a production or a session to production and do some changes. Exactly. The very first version of Quad code that we're internal, like committed straight to main. But then as soon as we have users and for the main customer base enterprises, this is what we care about the most.

For us for safety reasons, security is really important and 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. 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 of the lenses are non-deterministic. And by putting the LMSR reviewer called doing a review, it will give good feedback. But how do 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 catch that.

Are you doing anything in this loop to do deterministic? For example, linting is very deterministic. You will very well know. Have you thought of marrying some of these ideas or using for example, or using linters on the code base where you found no need for it? Yeah, absolutely.

This is just a gift. Yeah, we have that checkers. We have linters. We have linters on the build. Quad is actually so good at writing lin roles.

So actually what I do now, I used to tell you stuff in this spreadsheet. Now what I do is when a coworker puts up a poor request and I'm like, this is a little bit of the ad quad, please write a word for this in that PR on their PR. And we have, you know, you just run like, slash, I think it's like setup, or something like this. You can do this in quad code and it will install the GitHub app, which then makes it so you can tag ad quad on any board request, any issue. I use this every single day. So very, very useful.

So you want these deterministic steps. Also, there are ways to get quad to be a little bit more deterministic. So for example, you can do best of end, you can have it do multiple passes. And it's 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 want your parable agents to do stuff, and then we want your parable to do big agents to check for false positives. But essentially best of end, the way you implement it is all you say is cloud start three agents to do this. And that's it. Word 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 season sponsor WorkOS. If you're building any SAS, especially AI product one, then authentication, permission, 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 Antrific, OpenAI, and Kercer 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? 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 career 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 the score, kind of the agent part of it. Then there's the two-e part of it. And then there's actually a ton of different pieces around security and making sure that everything that Cloud Code does is safe and that there's a human in the loop for what happens.

And by safety, do you mean as a user, what one is doing stuff on my computer, or also as an user?

One interesting technical choice that you also mentioned is using RAG or not RAG-RACHEE, retrieval-argument generation. And you mentioned how in the earlier version of Cloud Code, you use a local batch of database to get some speed up search. And you layer through this away. Can you talk about how this one gives us another example where the model gets better? 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 spitter in Cloud Code, I think it's gone through like a hundred iterations, I would say. Oh, just a spinner. And out of those we landed maybe like ten or twenty in production and 80 of them probably just threw away because it didn't feel good enough. So statistically almost all the code we write with were away because it's just so easy to write this code and try stuff and see what feels good.

So if it's something like RAG, we tried a bunch of different approaches early on. So the first one was RAG-RACHEE because I think I was just reading up how people were doing retrieval and seeing all the papers were talking about RAG. And so the way it was a local vector database, I think it was written in TypeScript and used it on the user machine. And then I was using some embedding model that was in the Cloud to compute the embeddings before storing it. And that worked pretty good. But there's a lot of issues with RAG.

So for example, I was finding that the code drifted out of sync. Like if I make a local function, it's not yet indexed and so RAG isn't going to find it. There's also this question of like, how exactly is the index permissions? 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 one else's data? This is really, really important that we think about this. And so we just decided it was sort of working, but it also has a lot of downsides.

So trying a bunch of other stuff, 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 write glob and grep. We tried a bunch of different stuff. It turned out that agentix search just outperformed everything.

And when it's agentix search, this is a fancy word for glob and grep. That's all it is. So did the model both cut good enough and you realize that it can use these tools pretty efficiently? Yeah. And this was partially inspired by my experience at Instagram.

Because at Instagram, click the definition didn't work because the DevStack was just borked like half the time. And I think that was better. And so what engineers were into instead is, let's say you're looking for the definition of the function foo. Instead of click the 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 for opening parentheses. And this worked pretty well.

And it's funny because this works for the model pretty well. Interesting. 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're using 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 that command is safe. And there's also static analysis that we do to make sure that 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 ex-ultradate 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 like system flags they 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 very conservative about what we allow by default. As a user though, you can configure and allow list. So you can say for example, like these patterns are well, these patterns are not well.

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 size to run it once, or run it for either the session or whatever it makes sense or just globally allow it to go forward, right? That's right. This is a funny artifact. This was actually in the very, very first version of quad code.

This is the way permissions worked. This is the very first release. This was like September 2024, the first internal release. I remember at the time we weren't sure whether agent 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 brainstorm with Ben Mann and Ben was he started the WAP team. He's one of the founders and another topic.

He's actually he's the person that hired me to another topic. We just come up with permission problems as the way to do this. But if you're not sure it just has the human and they can decide. No, I was asking about how software engineering is done in general in terms of and traffic and one of the first questions, which is a more formal one or from the outside is titles or lack of them. Everyone at and traffic has the same title member of technical staff. Why did this happen? And what does this result? This kind of like everyone basically no title, right?

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 kind of quite generalist. 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 performance.

They might be writing software and also doing research. They might be writing product code and also infrastructure code. I don't think there's a lot of generalists. This is also from a background. This is one of the reasons that I gravitated towards it. And I think a 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 the title, the default would have been I see your name on Slack and under your name as a software engineer. And then I'm like, well, okay, I guess you're right. I'm not going to ask you product questions. But when everyone's title is a number of technical staff, by default, you assume everyone does everything. And so it kind of inverts this relationship between people, even if you don't know each other well yet. In a way, it's kind of this optimism 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, common by Mark and Jason, 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 engineering are saying we're doing design and 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 in reality, everyone's role is expanding. Most of it makes it easier for an engineer to do product work or product person to engineer work and so on. So it's what you said. I remember back in June or July of last year, I walked into the office and there's a role of data scientist that sits right next to the quad-coutine. I walked in and our data scientist for the quad-code team had quad-code up on his monitor.

He was using it and I was like, this is interesting because you're a data scientist. Why are you using a terminal? You didn't have no JS installed because we depended on no JS back then. Are you dog-fooding it? Are you trying to figure out how this thing works?

He was like, no, no, I'm using it to run SQL and it has little ASCII visualizations in the terminal. And then the next week, the entire role 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 are engineering manager codes, designers code, data scientist code are 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 dive in and 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 financial forecasts or data science or whatever. And by doing this, it's actually quite 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 Katu was talking about. She is, I guess, the title is the same, but people might gravitate for a role a bit more. I understand she's a little bit more on a product role. But you said that PRDs are just not really written inside and dropping a PRDs product requirement document.

It's a well-known artifact across the big tech, 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 then Tropic 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 whatever.

But yeah, also part of it is Kat used to be an engineering manager. She's extremely technical. And I think this is the way that our product team thinks about it too is better to send a PR. You're doing a lot of prototyping and stuff. So 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 15 or 20 prototypes for the two-do lists and all of them interactive working.

And what surprised me compared to my past experience, and you said that while you did this in a day and a half, all 20 tried it out, got a feeling for it, which in conference, 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?

Yeah. So I mean, on our team, the culture is we don't really write stuff. We just 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 prototyping multiple times. Like, you know, we launched agent teams over this week. This is our implementation of swarms.

It's very exciting because it just lets Quad 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. And I think that Daisy and Suzanne and the other folks on the team and Karen, they prototyped this for months and they tried, oh, and 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 static mocks in Figma or if we started with a purity or something like this. It's the thing that you have to build and you have to feel and you have to see how it feels. To me, one of the takeaways even from there was that we probably should prototype more and just be more daring or just really surprires of how long it took to build a prototype or who needed to build back then I was always an engineer that needed to build. But it's probably not true anymore. I mean, we're in this world right now also where we just we don't know where the right answer is.

I think back in the old way of building 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 work. You can only take Sophie 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 bit part of it is humility where personally I'm wrong, like half the time, I'd say like most of my ideas are bad. We have 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. 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 looked at it, you tried it out, you got to 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 naz is going to work. And then sometimes when it felt good, then you share it even broader. So I feel like it doesn't make 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, there's a lot of examples of this.

We want this kind of condensed view for file reads and file search. The model is just so e-genic now. I felt like half the screen is these like file reads and I actually don't care about it. You know, we 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 wrote it out to employees in the topic for about a month and we had everyone talk through it and I fixed another probably dozen, dozen bugs, dozen tweaks based on all this feedback. We want you to exrun away and almost all users liked it.

But there were a few users that didn't because they want more expanded output. And so on the get-out videos just going back and forth with people to be like, you know, like, why 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 to write some of the time.

We have to work from our users. We want to hear from people so we can get to write. Do you use ticketing systems for your work where you capture like right here's the work I want to or do just pretty much do the work as it comes in. So I don't think we would up the teams on the quad code team. We would up to every person.

And different people use this different way. For example, I don't use a ticketing system. Some people like to use a sauna or notes or something like this. One of the coolest things that I saw, this was maybe like three months ago or something we launched 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 you're job is to build plugins. You have to come up with a spec. Then you have to make a sauna 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 went for the entire weekend. It spawned a couple hundred agents. They made a hundred tasks on the sauna board.

And then they implemented it. And that's pretty much the version of plugins that we shipped. These kind of coordination systems that used to be for humans. But I think nowadays it's just as much for models. That's a lot of cloud co-work.

It's one of the very important things about it. It looks great. So I tried it out. It's like you have the co-work tab there. And then you can, I feel it's a lot more visual way of running agents interacting with them.

One of the surprising things I showed that it was built in 10 days. Can you take us through like what it's to build it and what it's actually mean? Was it from the idea or from the decision of building it and how big was it 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 or something that's not. So we felt that there is a product to be built or non-engineers. The reason we felt this is for a long time people that were using quad code or non-engineers. And so in the product world when you see wait and 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 quad code to monitor his tomato plants. I just, I felt this. I was like, get 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.

And it was so happy that the tomatoes were growing. There was someone that was using quad code to recover photos off of a corrupted hard drive. And it was like his wedding photos. Wow. Like I said, our entire financing method is quad code or 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 every VS code base, every JAPRAN space ID. 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 can expand it 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 was a gap and there's a product that could make this even easier for people. And so for the last couple months, the team was kind of hacking around and just saying like, what is the right product? And at some point, someone came up with this idea of like, what if we just take quad code, add some guardrails? So for example, core chips 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's doing.

And they were hacking on this, I think it was something like 10 days and to under something it was just fully built with quad code. And then we should do. Can you give us a sense of like the complexity behind an app like this? And if we can walk through like what parts need it to be built because from the outside is a little bit hard to tell like, is this just a nice UI wrapper? That's, you know, like, I don't know, like a few hundred lines of code.

I'm just being obviously I'm provocative here or behind the scenes, it's actually really complex piece of software. And the reason I ask is like Uber is a great example where people look at the app. It looks really simple. I 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 back-end things that are all hidden. So from just from looking at a cloud code 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. So, you know, you don't know the cloud app. It's a single desktop app.

It has a tab for code, it has a tab for code, it has a tab for chat. So it's 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 code running as 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's not technical and so we just want to make sure they have a good experience. And so for example, if someone launches the app and then, you know, like they delete a bunch of family photos, that's really not good.

And so we wanted to make sure that we protect against this so you can't accidentally do that. And so that's where one of the guard rules 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 prompting checks and 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. 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 code work, actually, a big part value is not just running locally, but it's using all of your tools, the way that quad code uses it. But the thing is, for non-technical users, your tools aren't really available with CLIs.

Some of them are available for MCP. Many of them are available in a browser. And so code work is really, really good when you pair it with a Chrome extension. And this is the way that I usually use it. So, for example, I use it every week to do project management for the team.

We have a spreadsheet that tracks at a really high level what everyone's working on. And this is my personal way of project managing. Like I said, use Asana, other people use nodes or whatever. For my own test, I don't use anything. But for the team overall, I have the spreadsheet.

And I have a core kind of check in. And I just ask a work every week. Hey, can you look at the rows for any status that has not been filled out? Can you just ping the engine on Slack? And so it'll open one tab in Chrome for the spreadsheet.

It'll open another tab with Slack. And then it'll just start messaging engineers in Slack. And it just one shots it. There's like one engineering for some reason they can't auto-compose. But everything else just gets.

And so this is actually like from a safety point of view, we also thought pretty deeply about this Chrome extension, 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 stack behind this? I assume it a lot of will be similar to the cloud app. But is it electron type script, those kind of things or something else?

Yeah, just electron and type script. Actually, some of the people working on it are early electron folks. So Felix, who's the creator of GoWork, he was a really early engineer on electronic and he helped build it. Oh, amazing. And co-work launched Mac OS only.

What was the reason for both for choosing this platform first and for now only choosing this platform? 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 in Anthropic, it's kind of like the way that I told my own story, one of the things I like about Anthropic is it really, really matches the way that people here think about it.

You know, back to this point where we don't have high certainty about the things that we build. And our intuition is often wrong. And so we just have to learn from users and figure out what people actually want and just spend a lot of time listening to people and understanding the feedback deeply. This is the way that we build product. And so we always want to look before it's ready.

We did this for Cloud Code. When we launched Cloud Code initially, it didn't even support Windows. Also, it didn't support, you know, like a lot of different stacks. And then over the coming weeks, we added support for every stack. Now Cloud Code supports every single stack, you know, like Windows, whatever weird Linux disorder use, Mac OS 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 yeah, it's going to support everything. One thing you mentioned is getting feedback. I'm curious, both for Cloud Code and for Cloud Code 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 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 one will be a small operation. 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 Enthropic that's kind of interesting is because we're an enterprise company and we care a lot about privacy and security. We can't see people's data. And so, you know, like if some reports are 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 co-work, what kind of learning is that 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? 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 Clotical first came out, it actually wasn't an overnight hit.

This is something people think it was, but it was sort of a slow take off at the beginning. And I think the first big inflection was in May when we released Opus 4 and Sonophore. 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 co-work, it's a much steeper growth trajectory than Quatcode was at the beginning. So it's just been an instant hit.

And that's actually very surprising. I didn't really expect that. One of your new releases, which came out just very recently, I think yesterday, the day before when we were recording this podcast was Agent Teams. And as I understand the idea with what Agent Teams agents forms, instead of single agent, you can have a lead agent that can delegate to different teammates. How do you start experimenting with this?

And how do you decide to ship it now? We're always doing experiments. There's all sorts of ways to get more mileage out of Quatcode. 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 subagents. So you have multiple agents working together. There's a lot of different approaches to get a little bit more mileage out of the context window.

There's this one idea called un-correlated context windows. That's what we call it. And the idea is multiple context windows. But they essentially start fresh. So they don't know about each other.

And so an example of this is a correlated context window is if you have one if you have one if you have the model and it does a task and then you have it just do a second task and that's in 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 un-correlated 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. Because when you run a skill or a splash command, it sees the parent context window versus where subagent, it doesn't. So it's un-correlated. There's some cases where you want that context. There's some cases where you don't.

And there's this kind of interesting thing where un-correlated context windows and just throwing the problem and throwing retokens at it. When the windows are un-correlated, it 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. And it really just felt like with Oubus 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 this is 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 builds and very, very complex, something more complex than what a single quad build. And we saw the results just really, really improved with Oubus 4.6 with Teams.

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 because it's a bunch of quads 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 a fair, weak, complex task. You don't probably want this for every task. The main quad decides the roles for the sub-quads. We don't have a kind of a regimented way to do this. It's context-specific.

I wouldn't say there's one right way to do it. I think actually a lot of the magic of this comes out of the city of un-correlated context windows. It's less about the specific configuration of the agents. But it's something that people should experiment with. I don't think there's one size fits all.

Have you seen use cases even in even, I know it's still recent, but have you seen use cases where it could look, it looks promising, there's a form approach. Well, I guess I've heard plugins were fully built with swarms. There's a bunch of other features since they were built in this way. So yeah, I think for anything where you see a single quad struggling, a swarms can help. It's an interesting tool to look at.

Talking about change in general, with Undercarper that you had a really interesting exchange back in December where when he posted that he's never felt as much behind as a programmer as he is now, because of the progress with AI. And then you share the story about how you start to debug a memory leak, the old fashioned way, and then Claude just one shot at it. I think it was a reflection of how everyone is feeling that things are changing so fast. And in the holiday break, I started to feel that things have ever shifted. How did you come to terms with this or start to embrace this change?

This is something I really struggled 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 with the old model might work with the new model. And it's weird because there's 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 have to learn. In a way, 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 all these ideas that work back before are now good and inverse. I think that's honestly it. It's something I constantly have to remind myself about.

And 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 is fun. I mean, we used a little bit of a gatekeeping, but it was somewhat valid where I know with architecture, someone came and said, 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? Because not much has changed. Yeah, that's right. And some of the microservice is funny because it's like every 10 years, it goes in and out of style. But yeah, now I think the first time ever, 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 look at them and I have to learn and I have to adjust my expectations. An example of this is when we release features, sometimes I'll screenshot myself using them on X or on threads or whatever, just to talk about it. But recently, Tarek, our DevRel guy, he actually goes a lot. He's amazing.

And he just started automating this. So he's having co-generated videos for Earth launches and he just started doing this. And this is something I thought would be maybe it's possible. It's not something I would have tried because I wouldn't have thought the model was right, but he just did it and it just kind of worked. One thing that I felt just a bit odd about and I think a lot of developers can relate is I've come to terms with this starting from Opus 4.5 and also similar models.

I think GPT 5.2 gave me similar vibe as well. The models have been just really good at writing code and I realize that I don't think I will hand-write the code when I want to get stuff done. If I actually want to 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 hacking around to go into university to learning C and C++ and it was just bloody hard.

And actually going through my first few jobs where I started getting better at it, debugging, and there's a point where 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 entry manager, when we designed the interview, we had talked with managers of what we need to screen for and we talked about what developers do most of their time, about 50% of their code. Therefore, we placed about 50% of the signal. It was all about coding.

So there was a lot of things that I didn't code because it is just hard. I think we all know that it takes grip. 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 think a lot of other people are feeling a bit easier, but there's definitely a sense of grief. How did you think about it? Because, 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 it, but you did. And now the models can also work as good as you have or it's not better.

That's the challenge. 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 I was able to get things done.

And at some point I just fell in love with 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 a book about, you know, a programming language. TypeScript. You were the first ever TypeScript book with O'Reilly.

Yeah, yeah, that's right. It was funny actually, there was 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 want to re-text script at all because I was only writing a couple years ago. I was like, yeah, at some point I started the biggest TypeScript meet up in the world. And I got to meet a lot of my heroes. There was Chris Colall who were general theory of activity. There was Ryan Dall who got that note.

One of the first times that I went really deep into this community and just the language itself and the tools themselves. And for some of my TypeScript there's this beauty and the types of stuff because Heilzberg is just brilliant. The idea of conditional types and anything can be a literal type. And there's these very deep ideas that even the most hardcore functional languages do not have. Even in something like Haskell, it doesn't go this far.

And Anders just took it and pushed it much further than how it had been pushed. And Joe Pamer and a bunch of other folks explored a lot of these ideas and thought of this. And I think for them it was also very practical. Because they had these large on TypeScript databases. How do you graduate migrate to something type?

And you have to come up with these very beautiful ideas to do this. For me, Scala was another rabbit hole that I fell into and this functional programming world. And still when I write code and when the model writes code I always think of the types first. That's what matters is what is the type signature that matters more than the code itself. So there is this beauty to it.

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 build things. And it's a means to an end. It's not an end to itself.

I think one metaphor I have for the moment in time that we're in is the printing press. The 1400s or whatever. Because at that moment it was actually quite similar. There was a group of scribes that knew how to write. And it was, as I understand, of course we never lived.

But as I imagine it was a hard process to learn. You need to get the equipment. You probably needed some sponsorship or being selected. You needed to produce the same thing over and over again. I assume it was either high-pensities or highly paid.

Or who knows? Let's assume it was within the printed press came along. Yeah. At least in Europe, you have a lord or king or something. You have to go through years of training.

And there were those glass of scribes that knew how to write. They were employed by someone like this. Often the king themselves, the queen was not literate. So it was a very, very new skill. And it was less than one percent of the population was literate in Europe.

And then the printing press came out. And what happened? The cost of printed material went down something like 100x over the next, I think, 30 years or something. The quantity of printed material is one of like 10,000x in the next 50 hundred 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 another 200 years, 300 years. Because we're learning to read this very hard. We're learning to write this hard.

It takes a lot of effort. Education system, it takes infrastructure to have paper and ink in the free time to do this instead of working on a farm. So it took early stages 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. None of the things around us would exist today without this.

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. 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.

And I think we like to mock the CEOs who are coming there, coming to a scene. 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 specialist who can build that. And there's always that disconnect between the idea and the person. And just like with the print express, 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 and things become more efficient.

I mean, of course, for the scribe, it's not the best news necessarily, but I mean, smart scribes can also do. So someone needs to write the books, run the press, et cetera. Yeah, exactly. And if you think about what happened to the scribes, they seem to become scribes, but now there's a category of writers and authors. And these people now exist.

And the reason they exist is because the market or literature just expanded a ton. I guess also if we think about like back then, scribes 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 and after this transition happens. Just, you know, the economy, as we know it would not have existed without it. So what's next? 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 the traffic? Who are software engineers or builders or members of technical staff? How are we calling them? Who do you stand out? What are they doing? What skills have they built up and how have they changed the way 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. So it takes something from 0 to 0.5. You know, figure out 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 product and design or design and engineering.

I think I'm just seeing a lot more of these of these hybrids. What's belief that changed from last year to this year? Something that you either believed or a conviction that you have that you've either revised or completed through a way? I think one thing I wasn't sure about is how big a problem is safety, to be totally honest. I joined on the topic 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. 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, I think 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 code style and languages and things like this.

I can't wait to get past these endless language debates and framework debates and all this stuff because the model can just use whatever language and framework and if you don't like it, it can just rewrite it for you. So it 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. You 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 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 billion dollar product, after quad code, whatever the next startup is that becomes an extra billion dollar startup, it might just be one person that has some co-idea and their brain just is able to think across engineering and product and business or design and finance and something else. People are going to become more and more multi-discipline 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 of it is having a short attention stand. It's being rewarded now.

Oh yeah. You know, like teenagers are using TikTok and all this stuff. I think in some ways it's kind of dangerous for society because you want people to think deeply and contemplate ideas and just moving on to the next idea very quick. But in some ways I think this year is 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 jumping across multiple different contexts very quickly. Could I add that from what I understood what all you said, maybe you 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 focusing deeply on one thing as well. And what strikes me about you and maybe this is 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 that small comes out, they'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 book said that you would recommend? I've gone down the Sichin-Lu rabbit hole because there's three-body problem guy, but he actually has 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 a little bit harder sci-fi, I really love Accelerando by Stross. This is a book I would totally recommend. It's essentially the product roadmap for the next 50 years. It starts with takeoff starting to happen and AI singularity. And then it ends up with this kind of group of lobster or consciousnesses or bidding jubit-er.

And it's just amazing. The thing that I think really captures is just the pace, the 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. Worse. Thank you so much. This was awesome. Yeah. Thanks for your game.

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, employ back kings who themselves were often illiterate, and that we, software engineers might be in a similar position today. We are the scribes. We spend years mastering this craft.

And now the printer press is arriving. But what Boris told me is that the scribes did not disappear. They became writers and authors. And the entire market for written work expanded beyond anything anyone could have predicted. I do find this hopeful and also appreciate that Boris and Sugar Coded.

The other thing that struck with me is just how differently the plot code team built software. No PRDs, no manager 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 link rules, best of end passes and human code review. If you enjoyed this podcast, please subscribe on your favorite podcast platform and on YouTube. Especially thank you if you also leave a rating on the show. Thanks and see you on the next one.