Building Claude Code with Boris Cherny

You wrote the first ever TypeScript book with O’Reilly.

Yeah. I found that book translated into Japanese in this little town in Japan. That was just the coolest moment. Then I realized I didn’t remember TypeScript at all.

Now we’re at the point where Claude Code writes, I think, something like 80% of the code at Anthropic on average. I wrote maybe 10, 20 pull requests every day. Opus 4.5 and Claude Code wrote 100% of every single one. I didn’t edit a single line manually.

Andrej Karpathy posted that he’s never felt as much behind as a programmer as he does now. This is something I really struggle with. The model is improving so quickly that the ideas that worked with the old model might not work with the new model.

One metaphor I have for this moment in time is the printing press in the 1400s, because there was a group of scribes who knew how to write. Some of the kings who employed the scribes were illiterate. If you think about what happened to the scribes, they ceased to be scribes, but now there’s a category of writers and authors. These people now exist, and the reason they exist is because the market for literature expanded a ton.

How did you get into tech, software engineering, and coding in general?

It starts a while back. I think there were 2 parallel paths that crossed. When I was maybe 13, I started selling my old Pokémon cards on eBay. I realized that on eBay, you can actually write HTML. I was looking at other people’s Pokémon card listings, and I realized some of them had big colors and fonts and stuff like this.

Then I discovered the blink tag.

What was the name? Was it the blink tag?

I put the blink tag on it, and I could sell my card for 99 cents instead of 49 cents or whatever.

The second thing was—this was also, I think, sometime in middle school. We had these old TI-83 graphing calculators. We used them for math. What I realized was that I could get a better answer on the math test if I programmed the answers to the math test into my calculator. So I wrote these little programs.

You just program the answers, and then the test got harder, so I had to program 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 assembly to make the program run a little bit faster.

Oh, so in high school you dropped down to assembly?

I think this was middle school or high school. It may have been 8th or 9th grade or something like this.

Then I realized that everyone in my class was starting to realize that I had the solver, and they got kind of jealous. So I bought this little serial cable so I could give it to them, too. Then, on the next math test, everyone in the class just got A’s. The teacher was like, “What’s going on?” Eventually, she realized it. She was just like, “Okay, you get away with it once, and knock it off.”

But for me, it was very practical. 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.

The first startup was—I think my friends and I were trying to get weed. So we started this weed-review startup. We made a website. We called different dispensaries, I think, and then we tried to get weed samples so we could review them for them. It actually kind of blew up.

Then I got more interested because, at the time, no one was testing this stuff. So I got into chemical testing and chemical analysis. After this, I did a bunch of other startups. Then I joined Y Combinator pretty early, and I was the first hire of this Y Combinator startup up in Palo Alto after that.

How did you decide to go from one startup to the other?

Kind of vibes, I’d say. Startups are never a linear path. You always 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 things, but the idea is always a hypothesis, and then almost always you have to pivot once, twice, or 3 times.

At this medical software company, this was called Agile Diagnosis. This was an early Y Combinator company, back in maybe 2011 or 2012. It was medical software for doctors. The idea was that there were clinical decision protocols, and they varied a lot from hospital to hospital.

Our idea was that there was 1 hospital in Chicago that had a really great protocol specifically for cardiac symptoms. So we thought, wouldn’t outcomes be great if every hospital in the US used the same protocol? We tried to standardize it, and we made this decision-tree software for doctors to use.

I wrote some of the software. The team was just a few of us. It was a pretty small team. The software ran in a web browser, and I remember this was back in the Internet Explorer 6 days. That’s what hospitals were using. I wrote this SVG renderer because it was a visual decision tree.

We launched it, and then we had a DAU chart. The DAUs were flat, and we couldn’t figure it out. We were piloting it with a few hospitals at the time. We were based in Palo Alto, and we were piloting it with a few hospitals, including UCSF.

I rode a motorcycle at the time, so I rode up to UCSF and shadowed doctors for a couple of days just to see how they actually used this. I realized that doctors didn’t have time to sit down and use a computer because you’re seeing a patient, and then you have maybe 5 minutes until the next patient.

In those 5 minutes, you have to walk down the hall, go to the computer station, and open up this totally legacy computer. By the time it boots up, that’s 3 minutes. Then you open up Internet Explorer 6. That takes 30 seconds. Then you have to open up this app that we built and sign in. Your 5 minutes are up. You don’t even have time to use it.

So we rewrote everything to run on Android, and they still weren’t using it. The thing we realized was that doctors were walking around with a bunch of residents behind them. In this kind of situation, it’s a social situation. The thing that matters is that they’re seen as an authority. They don’t want to be seen on their phones.

Then we pivoted again. At that point, we thought, okay, maybe the doctor isn’t the target user. Actually, we wanted it to be used by maybe nurses or X-ray technicians or something like this. At that point, I left because this was actually pretty far off from what I wanted to do.

The most fun thing for me is finding product-market fit because it’s always surprising. You can’t have 1 big idea because the idea is probably going to be wrong. So you form hypotheses, follow them down, and see what’s right.

I find it so interesting how you’re telling us this story, because behind a lot of success stories, we hear the success story, and 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 that you were hired as a software engineer, right?

This was back before product engineers or anything was a thing, which we’re now talking about. But you just rode your motorcycle, went there, shadowed the people, understood how they were using it and why they weren’t using it, and got ideas.

I feel this is what makes a great software engineer, back then and even today, right? You weren’t focused on the technology; you were focused on the outcome, though.

Yeah. Look, there are different kinds of engineers, and there are different ways to do it. Even on our team right now, I look at an engineer like Jarred Sumner, and he’s just an incredible technical mind. He understands systems better than anyone I’ve met. You need people like this.

You need people with this kind of depth. For me, engineering has always been a practical thing. For me, I've always been a generalist. It doesn't matter if I'm doing design, engineering, user research, or whatever.

My first job ever was when I was, I think, 16. I just wanted to buy an electric guitar, so I started freelancing. I was like, “Okay, I guess I'll make websites.” I think Fiverr wasn't a thing back then, so there were some other freelancing websites. I put up a website and started bidding on stuff. My first paycheck, I spent the entire thing on an electric guitar.

But it was very practical, right? When you're in this kind of setup, you have to do the engineering, the accounting, and the design, and you have to talk to customers. It's just always been like that for me.

1. Lessons from Meta

After a couple of these startups, you ended up at Facebook, now called Meta. You spent 7 years there. Can you just talk us through what you worked on there and what you learned there? You've also had a very remarkable career growth, in terms of 4 promotions over 7 years. What do you take away from that experience?

I started on Facebook Groups. That was the first team I worked on. Vlad Kolesnikov hired me. I think he's actually still at Facebook. I think he's on some other team now. It was cool, actually. There was a big group of people I worked with who were these early JavaScript people, too.

I did a bunch of JavaScript stuff, and it's funny—I kept crossing paths with these people. Vlad worked on Bolt.js, which was the framework that powered Ads Manager and later became React.js. I kept crossing paths with these people, and later on there were a bunch more people like this.

Anyway, I was working on Facebook Groups. I was really excited about it because of this mission of connecting people to their community. This was the thing that drew me in. At the time, I was a big Reddit user. I became a Reddit user when I was a teenager because I didn't know anyone else who coded. Even in college, I didn't really know anyone who coded.

Honestly, I was always kind of embarrassed about it because I thought it was this nerdy thing. 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 was very nerdy. At some point, I discovered there was a programming community on Reddit, and I was just shocked. There were other people who were into this thing. It was such a weird hobby, so niche. It was just so exciting to find like-minded people like this and get this connection.

I wanted to work on this. I wanted to contribute to this in some way. So I worked on Facebook Groups for a while. There were a bunch of different projects, and I'm happy to get into the details for any of these. Eventually, I became the tech lead for Facebook Groups and grew into this as the work grew.

The work really changed from building to a lot of document writing, coordination, and delegating to others. The culture was changing at the time, so this early Facebook culture was disappearing. Documents were coming in, alignment meetings were coming in, and there was a lot more work around foundational things like privacy and security. Honestly, early on, a lot of corners were cut in order to grow, but at some point you just have to pay that debt. That was the time when that happened.

Then I spent a few years at Instagram afterward. That was also a funny story. My wife got a job offer, and she was really excited about it. She came to me and said, “Hey, I got this offer, but we're going to move. Is that okay?” I said, “Yeah, that's fine. I work in tech. We can work remotely anywhere. Where's the job?” She said, “It's in Nara.” I said, “Where's that?”

Nara is rural Japan, and this was a different time.

Different time zone, yeah.

This was 12 hours or something of a difference.

Something like that, yeah.

It was like 2021.

Wow.

Then I tried to find a team that would sponsor me, because there were these arcane HR rules about the time zone you had to be in, the team you had to be colocated with, and so on. There was a little nascent team for Instagram in Tokyo. Will Bailey was running the team. He was also the guy who made Instagram Stories, so he was my manager for a while. We decided to grow that team together, and I worked remotely from Nara while most of the team was in Tokyo.

During this time, I was hacking on Instagram, and the stack was just insane. Facebook had the single best web-serving stack in the world. The way that everything was optimized—from the Hack language to the HHVM runtime, to GraphQL as the transport layer, to the client libraries like Relay and all the rest of the stuff—it was just amazing. And React. There was no other development stack in the world that was this good. It was just fully optimized.

Then I went to Instagram, and it was Python, where the type checker didn't work. Click-to-definition didn't work. It was this hacked-together Django, and then a fork of the CPython runtime. Nothing really worked.

I joined the Labs team in Japan. The idea was to find the next big thing for Instagram. We tried some stuff, but what I very quickly realized was that I was just not effective at working on the stack because it was such a terrible stack. So I went and started working on Dev Infra because we needed to fix it.

There were a few projects that we worked on. One was migrating from Python to the big Facebook monolith. Another one was migrating Instagram to GraphQL. These projects are actually in progress. They're things that involve hundreds of engineers and many years of work. It's a big codebase. It's a big migration.

Now it's faster with the tools that we have—the AI tools—and migrations are a pretty good use case for them, though.

Yeah, it's the perfect use case for it.

I started getting deeper into this. By the time I left Instagram, I was working on Dev Infra and leading a bunch of these migrations. That's also where I intersected with Fiona Fung, who is now the manager for the Claude Code team. I worked with her, and she was such an amazing leader. She had this incredible depth and history in tech. I thought, there's no better manager for this team.

Then I also started working on code quality. The work on Instagram expanded a bit, and by the time I left, I was leading code quality for all of Meta. I was responsible for the quality of the codebases across Instagram, Facebook, Messenger, WhatsApp, Reality Labs—kind of all these codebases.

At Meta, it was a program called Better Engineering. The idea was—I think it started in 2016 or 2018 or something—but Zuck mandated that every engineer at the company spend 20% of their time fixing tech debt.

Oh, interesting.

Mhm. Some of this is bottom-up, where a team knows best the tech debt that it has to fix. Some of it is top-down, where you need to do very big migrations, migrate to new language features or new frameworks, and things like this.

And at Facebook scale, there are tens of thousands of these migrations every year. I was leading all this, and I realized very quickly that it just needed a little bit more order to it. There were no goals, no one knew what the outcomes were, and there wasn't any tracking. So we developed a bunch of stuff. One of the ideas was a centralized way to prioritize the different 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 did you find there?

There was a bunch of stuff. I think some of this has been published. I don't know if all of it has, but essentially, you try to do causal analysis and causal inference. This is the methodology. You try to figure out what the factors are that make engineers more productive. Some of it is code quality, and some of it is outside of code quality.

For example, Meta returned to the office instead of working from home. That was partially driven by this, because we found some fairly strong correlations that we thought were causal. Code quality actually contributes double-digit percent to productivity. It turns out even at the biggest scale.

Yep.

About this, code quality actually contributes double-digit percent to productivity. It turns out even at the biggest scale.

This is 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. When you have a clean, modular codebase, it can get easier to work with, and I think reasoning could also be easier for LLMs to work with it. My hunch would be yes, it should be, right? But I think there's just very little data. That's the feeling that I would have.

Yeah, I think a lot of the big companies have published about this. I think Facebook published something, Microsoft publishes a bunch about this, and Google does, too. If every time that you build a feature, you have to think about whether you use framework X, Y, or Z, these are all options that you can consider because the codebase is in a partially migrated state where all of these are around the code somewhere, you're going to have a bad time as an engineer. As a new hire, you're going to have a bad time. As a model, you might just pick the wrong thing, and then the user has to course-correct you.

Actually, the better thing to do is just always have a clean codebase. Always make sure that when you start a migration, you finish the migration. This is great for engineers, and nowadays, it's great for models, too.

2. Joining Anthropic

And then you joined Anthropic, and I've heard the story—which you can confirm or give more color to—that your first pull request was rejected by Adam.

He was my ramp-up buddy. So, I joined Anthropic. I was trying to figure out what to do next, and I met a bunch of people at all the different labs. Anthropic was just the obvious choice for me because of the mission. This is the thing that, personally, I know that I need the most. Also, just seeing all this change that's happening, it's important to have some sort of framework to think about this and to think about our role in it.

I'm also a really big sci-fi reader. That's definitely my genre. I'm a big reader. I have a giant bookshelf at home and stuff. I just know how bad this thing can go. I felt like this is a place that has serious thinkers. People are taking this very seriously and thinking about what we can do to make this thing go better.

When I joined Anthropic, I did a bunch of ramp-up projects, just various stuff that I was hacking on. I wrote my first pull request by hand because I thought that's how you write code. That used to be how you wrote code. But even at Anthropic at the time, there was this thing called Claude, and it was the predecessor to Claude Code.

It was super janky. It was Python, it took 40 seconds to start up, it was research code, and it was not agentic. But if you prompted it very carefully and held the tool just right, it could write code for you. Adam rejected my PR, and he was like, “Actually, you should use this Claude thing for it instead.”

I was like, “Okay, cool.” It took me half a day to figure out how to use this tool because you had to pass in a bunch of flags and use it correctly. But then it spit out a working PR. It just one-shotted it.

Oh.

This was in 2024—September or August, something like that. I think, for me, this was my first feel-the-AI moment at Anthropic, because I was just, “Oh my God.” I didn't know the model could do this. I was used to tab completions, line-level completions in an IDE. I had no idea that it could just make a working pull request for me.

3. The origins of Claude Code

Yeah, and then when you joined Anthropic, we've covered this in a deep dive, but we could recap briefly on how Claude Code came to be out of what seemed like a side project or just a cool hack.

Yeah, I started hacking on a bunch of different stuff. I was working on some things in product. I worked on reinforcement learning for a little bit just to understand the layer under the layer at which I was building.

This is still advice that I give to a lot of engineers: always understand the layer under. It's really important because that just gives you the depth, and you have a little bit more leverage to work at the layer that you actually work at. This was the advice 10 years ago. It's still the advice today. But the layer under is a little bit different now.

Before, it was, like, understand the JavaScript VM and frameworks and stuff if you're writing JavaScript. Now it's, like, understand the model. So, I was hacking on a bunch of different stuff. Some things shipped, and some things didn't ship.

At some point, I just wanted to understand the public Anthropic API because I'd never used it before. I didn't want to build a UI. I just wanted to hack something up quite quickly because we didn't have Claude Code back then. We were still writing code by hand.

I wrote this little Bash tool, and all it did was hit the Anthropic API. It was essentially a chat-based application, but just in the terminal, because that's what AI used to be. I still think about it: engineers are the first adopters. When we started to move out of conversational AI to agentic AI, it took a little bit, but engineers understood it pretty quickly.

I think now, when you ask non-engineers what AI is, they would say it's this conversational AI. It's a chatbot or something. That's why I'm actually very excited for Claude Cowork, this new product that we launched, because it's going to bring the same thing that engineers saw very early to everyone else.

When I think about Claude Cowork, I think back to this moment that we're talking about, very early on. Claude Code originally wasn't Claude Code. It was a chatbot, because that's what I thought AI was. But we had to figure out what the next thing was.

At the time, I built this chatbot. It was somewhat useful, but it was just a chatbot. The next thing I tried was getting it to use tools. Tool use had just come out, and I didn't know what it was. I was like, “What's the experiment?”

I gave it a single tool, which was the Bash tool, and I didn't know what to do with the Bash tool. I actually didn't know if it could even do this, but I asked it, “What music am I listening to?” It just wrote a little AppleScript program using osascript or whatever to open up my music player and then query it to see what music it was listening to.

It one-shotted this with likely Sonnet 3.5. This was actually my second feel-the-AGI moment very quickly after the first one. The model just wants to use tools. That's just what I realized: if you give it a tool, it will figure out how to use it to get the thing done. And I think at the time, when I think about the way that people were approaching AI and coding, everyone essentially had this mental model: you take the model and you put it in a box.

And you figure out what the interface is. How do you want to interact with this model? What do you need it to do? Essentially, if you have a program, you stub out some module, stub out some function, and say, “Okay, this is now AI.” Otherwise, the rest of the program is just a program.

This is just not the way to think about the model. The way to think about it is that 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.

This is a version of the bitter lesson. The bitter lesson is a very specific framing, but there are many corollaries to it. One of the corollaries is: just let the model do its thing. Don't try to put it in a box. Don't try to force it to behave a particular way.

What were the first ways you saw this? Was it giving it tools, giving it access to Bash, then later to the file system, and then to more tools?

That's right. We gave it Bash, then—I say “we,” but it was just me for the first 3 months. Then the team grew. It was Bash and file edit; that was the second one.

One of the interesting things we talked about last time, in the deep dive, is that when you built it and it started to actually write code with all the tools that you had, there was an internal debate inside Anthropic about whether you should just keep it to yourselves. It was suddenly spreading across engineering and making all of you a lot more productive, right?

Yeah, that's right. In the end, the decision was to release it so that we could study safety in the wild.

When you think about safety—and I keep talking about the word “safety”—the reason Anthropic exists as a lab is safety. This is the reason it was founded. This is the reason it exists. If you ask anyone at Anthropic why they chose it, it's because of safety.

If you think about model safety, there are different layers at which to think about it. There’s alignment and mechanistic interpretability. This is at the model layer. Then there are evals, and this is kind of like putting the model in a petri dish and synthetically studying it in this way.

Then you can study it in the wild and see how it actually behaves. You can see how users talk about it. You can see what the risks are in the wild, and you actually learn a lot this way. By doing this, we've been able to make the model much safer. 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, “Oh, Anthropic released Claude Code. Oh, wow.” For the first release, I think it was with the Sonnet 4 release. Did it come out with Sonnet 4 originally or Sonnet 4.5?

I think it was Sonnet 4. That was the general availability in February, but I think it was a research preview before that.

When it came out, my interpretation was, “Oh, this thing can write code pretty well.” Over time, it became a lot more capable. From our perspective, it was this really capable coding tool that we just started to adopt and use for all sorts of increasingly productive parts of our work.

It has become, I believe, one of the fastest-growing developer tools. I'm always surprised to hear the story that it actually came from research and the goal was to understand how people use the model. On the other hand, some startups have been deliberately trying to build developer tools to get adoption, and yet this research tool is getting a lot more adoption.

Anthropic is a research lab. We're a safety lab. Product is this kind of thing tacked onto the side. Product exists so that we can serve research better and make the model safer. This is how we think about everything.

There was also this funny moment early on when we had this launch review and were deciding whether to launch it. I remember this moment because we were in the room. I think there was Mike Krieger, there was Dario, and there were some other folks in the room. We were deciding what we should do.

We were looking at the internal adoption chart, which was just vertical. It was insane. Nowadays, it's 100%, right? Just 100%. Every technical employee at Anthropic uses Claude Code every day. It's pretty much 100%.

For nontechnical employees, it's also getting quite close to 100%. It's increasing very quickly. Half of the sales team uses Claude Code, and I think that's increasing. It's crazy.

Dario had this question: “How did it grow this fast? Are you forcing people to use it?” I said, “No. We offer this tool. People vote with their feet.” We just let people use the tool that they prefer.

You don't seem like the person who would be forcing people to use your tool.

Yeah. The way we did it, we just launched the thing, listened to the users, talked to people, saw how they used it, followed up, and made it better.

Now we're at the point where Claude Code writes, I think, something like 80% of the code at Anthropic on average. It writes all my code, for sure.

This started for you in November, when it started to write all of your code. When did that switch come, and what happened to make you trust it to write your code? How much do you trust it? How much do you review that code, for example?

The switch was instant when we started using Opus 4.5. This was before it came out; we were dogfooding it for a little bit. It was just right away. It's such a more capable model. I found that I didn't have to open my IDE anymore. I just uninstalled my IDE because I didn't need it at that point.

I actually did that a month later because I didn't even realize that I wasn't using it anymore.

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, if I'm being honest with myself, it actually writes code as good as I would have written in the stack that I'm very familiar with, in my code base and my side projects where I know it—and just a lot better than what I could write for a code base that I'm not as familiar with or technologies that I'm not as familiar with.

Yeah, I'll be honest: it writes better code than I do.

I don't want to go there. I still like to keep my pride, but it's probably true.

Yeah, yeah. I realized this because, in December, I was traveling a little bit. I was on a coding vacation. We were talking about this before, but I went to Europe. We were just in a different time zone, kind of nomading around.

It was so fun because I was just coding all day, every day, which is my favorite thing to do. I wrote maybe 10–20 pull requests every day, something like that. Opus 4.5 and Claude Code wrote 100% of every single one. I didn't edit a single line manually.

I realized at the end of that month that Opus introduced maybe 2 bugs, whereas if I'd written that by hand, that would have been, you know, like 20 bugs or something like that.

4. Boris's Claude Code workflow

Can we talk about your development workflow? You have written some threads about this, which is awesome, on social media, on Threads and on X. Can you tell us how you use Claude Code today in terms of parallelism, and the tips and tricks that you and the team have learned and share across the team?

There's no one right way to use Claude Code. I can share some tips and things, but I think the wrong conclusion to draw would be to just copy these and use them.

The way we built Claude Code is that we built it to be hackable because we know every engineer's workflow is different. There's no one way to do things. There aren't 2 engineers who have the same workflow. Every engineer is different.

Workstation setup, right? Keyboards, monitor placement—all that. Everyone has it differently.

Yeah, it's like we're craftspeople, right? You choose your tools. We care deeply about it. There's no one right way to do it.

For me, the way I generally do it is that I have 5 terminal tabs. Each one has a checkout of the repository, so it's 5 parallel checkouts. Usually, I'll round-robin and start Claude Code in each one.

Almost every time I start in plain mode, so that's Shift+Tab twice in the terminal. I also overflow as I run out of tabs. There's only so many terminal tabs.

I used to use the web a lot for this, so claude.ai/code is the place that I overflow to. Nowadays, I actually use the desktop app. It's more convenient. Claude Code has been in our desktop app for many months. It's just a code tab in the Claude app.

I really like it because it has built-in worktree support. That's existed for a while, and it's quite nice for parallelism. You have multiple—you don't need multiple checkouts. You just have one, and we automatically set up Git worktrees for you, so you get this kind of environment isolation.

The reason I do that is that I really hate fiddling with Git worktrees on the command line because it's kind of fiddly. You need to know to change directories and—

For those of us who aren't as familiar with it, it's when you can check out something and, instead of having a separate local folder, it's almost like checking out a separate branch, right? You can work on it separately without having conflicts, only at merge time.

That's right. Imagine that you have a folder, but maybe Git makes 5 copies of that folder in a way that's very cheap and kind of easy to throw away. So, you get this kind of isolation. You can work in parallel, and the Claude Code sessions don't interfere.

Yeah, so you know how support for this, which I think you recently added, like native support, but for your workflow, you just stuck with the old one of checking out into separate folders, right?

Yeah, exactly. Over time, I'm using the desktop app more and more for this.

Mhm.

I just don't need these separate checkouts, and I have a bunch of Claude Code sessions running in parallel, so I don't have to think about it. The other surprise hit is the iOS app for me. Every day, I wake up and start a few agents on my phone.

Oh, the native one, yeah?

The native one, yeah. It's just the Claude app. It's the Code tab in the Claude app, and it's the same exact Claude Code.

Except it runs in the cloud, right?

It runs in the cloud, yeah, so you have to configure the environment. Your environment's pretty simple, so we just use hooks. You just use the SessionStart hook and configure it. This is kind of one of the benefits of making Claude Code really hackable: it's very easy to do this kind of configuration.

5. Parallel agents

This is something, honestly, I would never have predicted. If you told me 6 months ago that I'd be writing maybe a third, maybe half, something like that, of my code on a phone, that's crazy. But that's what I'm doing today.

And you're using parallel agents. At what point did you start using them, and how has it changed your work?

One thing that I notice about myself is that I don't really use that many parallel agents. I may have 2 at a time, but I'm someone who likes to be in charge, especially with Claude. Claude is a tool that you can follow along with. It tells you what it's doing. You can also have, for example, Learning mode, which shipped a lot earlier, where you can actually follow along. It gives you tasks.

I feel that staying in 1 tab and following along—the model's pretty fast as well—I can kind of keep in touch. I'm assuming at some point you must have done this, but what happened when you changed to parallel? Do you feel you're losing any control, or does it not really matter that much?

Yeah, I think there are kind of 2 modes to think about, or 2 workflows to think about. When you're new to a codebase, Learning mode is awesome. I highly recommend it. For people who are onboarding to the Claude Code team, and people who onboard to Anthropic, the thing that we recommend is: for people who haven't tried it, you do /config.

In Claude Code, you pick the output style, and you can do Learning or Explanatory. We usually recommend Explanatory because that tends to be better for new codebases that you haven't been in before.

For me, once you're familiar with a codebase, you just want to be productive, right? You just want to ship as much as you can and be effective doing that. So, the role really switches. I don't really go deep into tasks anymore. I start a Claude Code session in Plan mode and have it kick something off.

With Opus 4.5, I think it got there. With 4.6, it just really, really does it. Once there's a good plan, it will one-shot the implementation almost every time. So, the most important thing is to go back and forth a little bit to get the plan right.

What I do is I start one. I enter Plan mode. I give it a prompt. As it's chugging along, I go to my second tab and start the second Claude, also in Plan mode. I get it chugging along, then go to the third tab, then the fourth one. Then maybe I'll go back to the first one when I get notified that it's done, and I'll keep track of that.

Do you keep notifications on, or do you turn them off?

I actually operate in both modes. Sometimes I use Focus mode on the Mac, so I just have it off, but also sometimes I use the system notifications.

And you're very, very productive with PRs. I think it was very visible even around the holiday breaks on social media. You actually responded to, I think, someone who reported a bug or feature request. I'm not sure which one it was. Then an hour or 2 later, it was done because you did it.

You've also talked about the number of pull requests you've done in a day, not to show off, but just as context. What does a pull request typically involve in terms of complexity? Are some super trivial, or are some actually larger pieces of work as well?

Yeah, pull requests each vary 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 2, maybe top 3 most productive engineers at Instagram just by volume of code written.

I've always coded a lot. Coding is a way that I can express myself, and it's a way that my brain thinks, also. Now I just get to do it. But I think with Claude Code, the kind of code that you write if you are very productive is such that the number of PRs sort of undersells what's happening.

I think people who used to be very productive in the old days, before AI assistants, wrote a lot of code that maybe was code migrations or something like this. People who shipped 20 or 30 PRs every day, a lot of it was pretty much a one-liner, or kind of migrating A to B or whatever. Nowadays, I ship 20 or 30 PRs every day, but every PR is just completely different. Some of them are thousands of lines, some of them are hundreds, some of them are dozens, and some of them are one-liners.

6. Code reviews

None of these are code migrations, because Claude Code just does those, and I don't need to be part of that.

When you're shipping this much code into production, the obvious question that comes up for any, I guess, software professional is: well, what about the review?

The way teams used to work—and I'm not sure if Instagram did this, but a lot of other companies did this—is you make a pull request, you put it up there, and there's a mandatory human reviewer. At Google, there are actually 2, because there's 1 on code quality as well. How has this workflow changed? How does the Claude Code team think about code review, and how has it changed over time?

I'll start by talking about how code review used to work for me. I also used to be one of the most prolific code reviewers.

Oh, okay. So, both.

Yeah, writers and code reviewers. That's actually one of the benefits of being in a different time zone. I'm not superhuman; I just didn't have any meetings.

The way that I approached code review was that every time I had to comment about something, I would drop it in a spreadsheet. I would describe the issue. So, let's say someone named a parameter badly in a function, I would put that in a spreadsheet. If someone used a bad React pattern or something, I would put that in a spreadsheet.

Over time, I would tally up the spreadsheet, and anytime that a particular row had more than 3 or 4 instances, I would write a lint rule for it. So, I would just automate it with static analysis.

For me, I've always tried to automate myself away because there are just so many things to do. There are very few other fields where you're able to do this. This is something we're uniquely able to do. I've always enjoyed it because it gives me more free time, and I get to do the work I actually enjoy.

Today, the way this looks is a little different, but it mirrors this a little bit. When Claude Code writes code, generally it'll run tests locally, and this is something Claude often decides to do when it's relevant, or it'll write new tests. So, you get this kind of verification.

When we make changes to Claude Code, Claude will also test itself. It'll launch itself in a subprocess, verify itself, and test itself end to end.

This is for your internal Claude Code implementation? So, you have this test suite so it can test itself?

Yeah, that's right. That's right. But it'll literally launch itself just in a Bash process and kind of just see, “Hey, do I still work?”

So, it'll do this. This is something that we just didn't code in. With Opus 4.5 especially, it just started spontaneously doing this. It just wants to kind of check.

So, we do this, and then we also run `claude -p`. This is the Claude Agent SDK in CI. Every pull request at Anthropic is code-reviewed by Claude Code. That actually catches maybe 80% of bugs, something like this.

It's the first round of code review. Claude will automatically address some of these. Some of them it'll leave to a human because it's not sure what to do. There's always an engineer who does the second pass of code review, and there always has to be a person in the loop approving the change.

I think it depends 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 not have reviewed it. You just trust yourself, or you ship to production or SSH into production and make some changes. You get that kind of stuff, right?

Exactly. The very first versions of Claude Code that were internal, I committed straight to main. But then, as soon as you have users—and for Anthropic, our main customer base is enterprises, and 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. 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's known about LLMs is that they're nondeterministic. By putting an LLM as a reviewer—Claude doing a review—it will give good feedback, but how would you deal with the fact that you can't be sure it's always going to give that feedback? You cannot be sure that even if it's capable of catching an issue, it will necessarily catch it. Are you doing anything in this loop to do deterministic things?

For example, linting is very deterministic, as you very well know. Have you thought of marrying some of these ideas? Are you using linters on the codebase, or have you found no need for them?

Yeah, absolutely. We have type checkers, we have linters, and we run the build. Claude is actually so good at writing lint rules. What I do now—I used to tally stuff up in a spreadsheet—is, when a coworker puts up a pull request and I'm like, “This is lintable,” I'll just ask Claude, “Please write a lint rule for this,” in that PR, on their PR.

You can run `/install-github-app` or something like this in Claude Code, and it'll install the GitHub app. Then you can tag @Claude on any pull request or any issue. I use this every single day. It's very, very useful.

You want these deterministic steps. Also, though, there are ways to get Claude to be a little bit more deterministic. For example, you can do best of N; you can have it do multiple passes.

Mhm.

And this is actually quite easy to do. For example, the code review skill that we use internally is open source, and it's available in the Claude Code repo. All we do is launch parallel agents to do stuff, and then launch parallel deduping agents to check for false positives.

Essentially, best of N—the way you implement it is, all you say is, “Claude, start 3 agents to do this.” And that's it.

How does Claude Code work in terms of architecture? 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. There's not much to it. There's a core query loop, and there are 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.

There's kind of this core agent part of it. Then there's the TUI part of it. And then there's actually a ton of different pieces around security, making sure that everything Claude Code does is safe, and that there's a human in the loop for when it happens.

And by safety, do you mean, as a user, what it's doing on my computer, or also Anthropic monitoring use cases that could be deemed unsafe?

Yeah, there's kind of a couple of versions of this. Safety—there are just many, many layers. For things like safety and security, there's no one perfect answer. It's always a Swiss cheese model. You just need a bunch of layers, and with enough layers, the probability of catching anything goes up. You just have to count the number of nines in that probability and pick the threshold that you want.

For something like prompt injection, for example, we do this generally at 3 different layers. Let's think about something like web fetch. Claude fetches a URL, reads the contents of that web page, and then does something in Claude Code. One of the risks for something like this is prompt injection. Maybe there's an instruction on that website saying, “Hey, Claude, delete all the folders,” or something like that.

We think about this in a number of ways. The most basic way is that it's an alignment problem. Opus 4.6 is the most aligned model we've ever released because we've taught the model how to be more resistant to prompt injection. You can read about this on the model card, and I think it was part of the release.

The second part is that we have classifiers at runtime. If there's a request that seems to be prompt-injected, we block it, and we make the model try again. The third layer is that, for something like web fetch, we summarize the results using a subagent and then return that summary to the main agent.

Again, this reduces the probability of prompt injection. You can see how this isn't just one mechanism. It's a layer, and by having a bunch of these different layers, it just reduces the probability a lot.

One interesting technical choice that you also mentioned is using RAG or not—retrieval-augmented generation. You mentioned how, in the earlier version of Claude Code, you used a vector database to speed up search, and you later threw this away. Can you talk about how this worked? This was another example where, I guess, the model got better?

Yeah, I mean, this is one of those things where we try so many different things. We try so many different tools, and statistically, most of them we throw away. Even something like the spinner in Claude Code, I think it's gone through like 100 iterations, I want to say. Just the spinner. Out of those, we landed maybe 10 or 20 in production, and 80 of them I probably just threw away because they didn't feel good enough.

Statistically, almost all the code we write, we throw away, because it's just so easy to write this code, try stuff, and see what feels good. For something like RAG, we tried a bunch of different approaches early on. The first one was RAG for retrieval, because I was just reading up on how people were doing retrieval, and it seemed like all the papers were talking about RAG.

The way I did it was like a local vector database. I think it was written in TypeScript, and it just lived on the user's machine. Then I was using some embedding model that was in the cloud to compute embeddings before storing it. That worked pretty good, but there are a lot of issues with RAG.

For example, I was finding that the code drifted out of sync. 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 how exactly the index is permissioned. Who can access it? I can access it, but then how do we encode that in permission policies? How do we make sure no one else can access it? How do we make sure that, if there's a rogue IT person within the company, they can't access someone else's data? This is really, really important for us to think about.

And so we just decided it was sort of working, but it also had a lot of downsides. We tried a bunch of other stuff. One of them was just using the model to index everything recursively. That was kind of a cool idea. There was another version where we just tried glob and grep. We tried a bunch of different stuff. It turned out that Agent-X search just outperformed everything.

And what is Agent-X search?

It's just a fancy word for glob and grep. That's all it is.

Nice. So, the model both got good enough, and you realized that it can use these tools pretty efficiently.

Yeah. And this was partially inspired, honestly, by my experience at Instagram. At Instagram, click-to-definition didn't work because the dev stack was just broken like half the time. I think now it's better. And so what engineers would do instead is, let's say you're looking for the definition of the function `foo`.

7. Permissions and sandboxing

Instead of click-to-definition, what you would do is use the global index, which is quite good at Meta, and then search for “foo(”. This worked pretty well. It's funny because this works pretty well for the model, too. It's interesting how one idea from one area can come to the other.

One of the more advanced parts of Claude Code that we also previously talked about is the permission system. Can you talk about what was complex about it? And you recently open-sourced sandboxing, right?

Permissioning is really complex. Like everything else that has to do with security, it's a Swiss cheese model. There are a number of classifiers that run to make sure the command is safe, and there's also static analysis that we do to make sure the command is safe.

As a user, you can also allowlist particular patterns that you know to be safe. For example, some standard Unix utilities we pre-allow because we know they're read-only, and we know they can't exfiltrate data or anything like this. We just won't prompt you for permission.

But actually, quite a few tools fall into this category because even something like the find command has a way to execute arbitrary code as part of that command. There are system flags that you use for this. Or even something like the set command—there are ways to use this. There's just all this arcana about these various Unix utilities where they're actually not as safe as you think.

We want to be fairly conservative by default about what we allow. As a user, though, you can configure an allowlist. You can say, for example, “These patterns are allowed; these patterns are not allowed.” We let you define that, and we also check this allowlist to make sure that it's safe.

And then you have this neat permission system where every time you run a command that needs permission, you can decide to run it once, to run it for either the session or whatever 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 first version of Claude Code. This is the way permissions worked. This was the very first release, in September 2024—the first internal release.

I remember that, at the time, we weren't sure whether agentic safety could even be solved. There was actually a lot of pushback internally from the safety teams because they were like, “Okay, you can't just let the model run Bash commands. That's unsafe. So what do you do? This is not a solvable problem, so we can't launch this.”

I brainstormed with Ben Mann. He started the Labs team, and he's one of the founders at Anthropic. He's also the person who hired me at Anthropic. We came up with permission prompts as the way to do this: if you're not sure, just ask the human, and then they can decide.

8. Engineering culture at Anthropic

I want to ask you about how software engineering is done in general at Anthropic. One of the first questions, which is, I guess, a more formal one from the outside, is titles, or the lack of them. Everyone at Anthropic has the same title: Member of Technical Staff. Why did this happen, and what does this result in? Everyone basically has no titles, right? Except for one.

I think it's kind of an acknowledgment that everyone is just figuring stuff out. If you kind of squint and look at the work people are doing, it's all quite similar, and it's 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 requirements. They might be writing software and also doing research. They might be writing product code and also infrastructure code.

At Anthropic, there are a lot of generalists. From my background, this is one of the reasons that I gravitated toward it. I think “Member of Technical Staff” just encodes this in the way that people talk to each other, even if they don't know each other.

Without this title, the default would have been that I see your name on Slack and, under your name, it says “software engineer.” Then I'm like, “Okay, I guess you're the coding person, so I'm not going to ask you product questions.” But when everyone's title is “Member of Technical Staff,” by default you assume everyone does everything. It kind of inverts this relationship between people, even if you don't know each other well.

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: toward more of this generalist model.

Definitely, it feels like it in software engineering. I've heard this funny comment by Marc Andreessen, where he said that there's this Mexican standoff happening in the tech world. The designers are saying that they're now doing product management and engineering work. The engineers are saying that they're doing design work. Everyone thinks they're doing the work of the others, and they're kind of standing there saying, “I'm doing your work as well.”

But in reality, everyone's role is expanding, mostly thanks to AI, because it makes it easier for an engineer to do product work, or for a product person to do engineering work, and so on. So, just what you've said.

I remember back in June or July of last year, I walked into the office. There's a row of data scientists who sit right next to the Claude Code team, at least they did at the time. I walked in, and our data scientist on the Claude Code team had Claude Code up on his monitor.

I was like, “This is interesting, because you're a data scientist. Why are you using a terminal? You didn't have Node.js installed, because we depended on Node.js back then.” I was like, “Are you dogfooding it? Are you just trying to figure out how this thing works or something?”

He was like, “No, I'm using it to run queries.” He was just using it to run SQL, and it had little ASCII visualizations in the terminal. The next week, the entire row of data scientists had Claude Code running on their computers.

This expanded. If you look at the team today, on the Claude Code team, everyone codes. The engineers code, our engineering manager codes, designers code, data scientists code, and our finance guy codes. Everyone on the team codes.

Part of it is that Claude Code just makes it so easy. You don't really have to understand the codebase; you can just dive in and make small changes quite easily. But I think another thing is that people are able to use Claude Code to do their jobs more, whether it's financial forecasts, data science, or whatever. By doing this, it's actually quite an easy crossover to just use it to write a little bit of code, too. It's just a way to dip your toe in the water.

One other interesting thing about how you work is that Kat Wu was talking about how she is—I guess your title is the same, but people might gravitate toward a role a little bit more, and I understand she's a little bit more in a product role.

You said that PRDs are just not really written inside Anthropic. PRDs, or product requirement documents, are a well-known artifact across big tech and increasingly 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 any of it.

Some of this, I think, is because Anthropic is still a startup, so you don't actually have to align with that many people. Usually, you can just kind of talk about it or do it in Slack or whatever.

But, yeah, part of it is that Cat used to be an engineering manager. She's extremely technical. I think this is the way that our product team thinks about it, too: it's better to just send a PR. You're doing a lot of prototyping instead.

That's also something where, when we talked about how you were building Claude Code early on, you were showing—actually, you had a whole thread about the number of prototypes. I think you did 15 or 20 prototypes for the to-do list, and all of them were interactive and working.

What surprised me compared to my past tech experience—and you said that you did this in a day and a half—was that you tried all 20 of them out and got a feeling for them, which is incomprehensible to me. It would have taken a week or 2 weeks, and people would not have done 20. They would have done 3.

So, are you seeing an increase in prototyping and in building and showing instead of writing things?

Yeah, absolutely. On our team, the culture is that 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 prototyping everything is so baked into the way that we build. Everything is prototyped multiple times.

We launched agent teams this week. This is our implementation of swarms. It's very exciting because it just lets Claude do more work for longer, more autonomously. You have a bunch of different uncorrelated context windows, and you have this kind of communication between agents. They can just do more.

This is something that Daisy, Suzanne, Karen, and other folks on the team prototyped for months. They tried, all in all, probably hundreds of versions of this before they got a user experience that felt really good.

It was just really hard to get right. There’s just no way we could have shipped this if we had started with static mocks in Figma or a pure PRD or something like this. It’s a thing that you have to build, and you have to feel, and you have to see how it feels. To me, one of the big takeaways from that was that we probably should prototype more and be more daring, or just release your priors about how long it took to build a prototype or who needed to build it. Back then, it was always an engineer who needed to build it, but that’s probably not true anymore.

Yeah, that’s right. I mean, we’re in this world right now where we just don’t know what 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 took your shot. Because after you took your shot, it was very hard to course-correct. You could only take so few shots.

But now it has changed. The cost of building is very low, but also we don’t know where we’re aiming. So we have to try, and we have to see what feels good. It’s very exploratory. I think also a big part of it is humility where, personally, I’m wrong half the time. I’d say most of my ideas are bad. At least half of them are bad, and I don’t know which half until I try them. And then you 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 my intuition doesn’t always match others.

When you were showing these prototypes of how the tasks were built, you were telling me that you built the prototypes, and then your process was always that you first looked at them, tried them out, and got a feel for them. For the ones that you felt were good, you showed them to others, and sometimes they gave you feedback like, “No, this doesn’t work.” Then, when it felt good, you shared it even more broadly. So I feel like it’s a mix, right? Sometimes you can decide already, and sometimes you get feedback, and eventually some good ideas come out of it.

Yeah, and there are a lot of examples of this. We launched this condensed view for file reads and file search because the model is so agentic now. I felt like half the screen was these file reads, and I actually don’t care. I read a thing; I don’t really care what it is. So we condensed this down to make the output a little more readable.

I really liked it after probably 30 prototypes or something like this. It took so much effort to make that feel really good and clean. We rolled it out to employees at Anthropic for about a month, and we had everyone dogfood it. I fixed another dozen bugs and made another dozen tweaks based on all this feedback.

We launched it externally, and almost all users liked it, but there were a few users who didn’t because they wanted more expanded output. On the GitHub issue, I was just going back and forth with people, asking, “What don’t you like?” People gave a lot of feedback. I shipped another version, and then some people liked it and some people didn’t. So I iterated on it again and made it good.

I think it’s actually almost there, where people can configure it the way they want, but the default is still really good. This is just the process: we get it right some of the time, and we have to learn from our users. We want to hear from people so we can get it right.

Do you use ticketing systems for your work, where you capture, “All right, here’s the work,” or do you just pretty much do the work as it comes in?

At Anthropic, we leave it up to teams. On the Claude Code team, we leave it up to every person. Different people use this differently. For example, I don’t use a ticketing system. Some people like to use Asana or notes or something like this.

One of the coolest things that I saw was maybe 3 months ago or something. We launched plugins, and the way we launched them was that Daisy had a very early version of swarms for a weekend. She let the swarm run and told it, “Your job is to build plugins. You have to come up with a spec, then you have to make an Asana board and split it up into tasks. Then all the different agents have to build it.”

She set up a container and set up Claude in dangerous mode, and she let it run for the entire weekend. It spawned a couple hundred agents. They made 100 tasks on the Asana board, and then they implemented them. That’s pretty much the version of plugins that we shipped. These kinds of coordination systems used to be for humans, but I think nowadays they’re just as much for models.

9. Claude Cowork

Let’s talk about Claude Cowork. It’s one of the very important things about this: it looks great. I tried it out. Inside Claude, you have the Cowork tab, and it feels like a much more visual way of running agents and interacting with them. One of the surprising things I heard was that it was built in 10 days. Can you take us through what it took to build it and what that actually means? Was it from the idea, or from the decision to build it? How big was the team building it?

The team was really small. It was just a few people. For a long time, we felt that there was some product to be built for non-engineers. The reason we felt this is that, for a long time, people using Claude Code were non-engineers. In the product world, when you see latent demand—when you see people jumping through hoops to use a product that was not designed for them—that’s a really good sign that it’s time to build another product just for them.

There are all these people on Twitter. There’s this one guy who was using Claude Code to monitor his tomato plants, and I just loved this. He had a webcam set up, and Claude was like, “Oh my God, I’m so happy that our plant is budding.” It had a webcam and was monitoring it every day, and it was so happy that the tomatoes were growing.

There was someone who was using Claude Code to recover photos from a corrupted hard drive, and they were his wedding photos. Our entire finance team at Anthropic uses Claude Code, and our sales team uses Claude Code. So there are all these non-engineers who were using it.

At that point, Claude Code was available in a lot of form factors. We started in a terminal, then expanded and added support for IDEs. We have extensions for every VS Code-based IDE and every JetBrains-based IDE. There are also iOS and Android apps, the desktop app, the web app, and Slack and GitHub apps. We can expand it to all these places to make Claude Code easier for engineers.

Ultimately, though, none of these are built for non-engineers. Claude Code evolved a lot, but it still felt like there was a gap and a product that could make this even easier for people. For the last couple of months, the team was hacking around and just seeing what the right product was.

At some point, someone came up with the idea, “What if we just take Claude Code and add some guardrails?” For example, Cowork works with a virtual machine. This is one of the many ways that we make sure it’s really safe, especially for nontechnical users who don’t want to read Bash commands to figure out what it’s doing. They were hacking on this for something like 10 days or something. It was fully built with Claude Code, and then we shipped it.

Can you give us a sense of the complexity behind an app like this? Can we walk through what parts needed to be built? From the outside, it’s a little hard to tell: is this just a nice UI wrapper, or is it a few hundred lines of code? I’m being provocative here, obviously. Or, behind the scenes, is it actually a really complex piece of software?

The reason I ask is that Uber is a great example. People look at the app and it looks really simple. I worked there, and I know it’s really, really complex because you don’t see a lot of the complexity. There are a lot of regional things and back-end things that are all hidden. So, just from looking at how Claude Code works, it’s hard to tell how much of this is additional business logic that needed to be carefully thought out versus whether it’s actually just a nice, thin wrapper on top of the model.

In some places, I think there’s less complexity than you would think, and in some places there’s more complexity. On the product side, it’s quite simple because it’s just the Claude desktop app. You download the Claude app; it’s a single desktop app. It has a tab for Cowork, a tab for Code, and 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, it’s just the same Claude Code running. It’s the same Claude Agent SDK that powers Claude Code. A lot of the complexity is actually about safety, because, as I said, we know the user is nontechnical and we want to make sure they have a good experience.

For example, if someone launches the app and then deletes a bunch of family photos, that’s really not good. We wanted to make sure that we protect against this so you can’t accidentally do that. That’s where a lot of the guardrails came from. There are a bunch of classifiers running on the back end.

This is for safety and, again, extra mitigations for things like prompt injection and risks like this around security. On the front end, there’s an entire virtual machine that we ship. There are 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.

Then we also have to rethink the permission system because we inherit the permission system from Claude Code. But also, for Claude Cowork, a big part of the value is not just running locally, but using all of your tools the way that Claude Code uses them. The thing is, for non-technical users, your tools aren’t really available as CLIs. Some of them are available over MCP, and many of them are available in a browser.

Claude Cowork is really, really good when you pair it with a Chrome extension. This is the way that I usually use it. 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. This is kind of my personal way of project-managing. Other people, like I said, use Asana, or other people use notes, or whatever.

For my own tasks, I don’t use anything, but for the team overall, I have the spreadsheet. I have Claude Cowork check in, and I just ask it every week, “Hey, can you look at the rows for any status that has not been filled out? Can you just ping the engineer on Slack?” It’ll open one tab in Chrome for the spreadsheet, and it’ll open another tab with Slack. Then it’ll just start messaging engineers in Slack. It just one-shots it.

There’s one engineer’s name that, for some reason, it can’t autocomplete, but everything else it just gets. From a safety point of view, we also thought pretty deeply about this Chrome extension, how it works, and how the permissioning model should interact with this local permissioning model. So there’s also a bunch of code to make sure that feels smooth.

What’s the tech stack behind this? I assume a lot of it will be similar to the Claude app, but is it Electron, TypeScript, those kinds of things, or something else?

Yeah, just Electron and TypeScript. Actually, some of the people working on it are early Electron folks. Felix, who’s the creator of Claude Cowork, was a really early engineer on Electron, and he helped build it.

Oh, amazing. Claude Cowork launched on macOS only. What was the reason for both choosing this platform first and, for now, only choosing this platform?

Windows is coming soon. I think probably by the time this podcast comes out, we’ll have Windows support. We just wanted to start early and start learning.

Everything we do at Anthropic is kind of like the way that I told my own story. One of the things I like about Anthropic is that it really matches the way that people here think about it. We don’t have high certainty about the things that we build. Our intuition is often wrong, and so we just have to learn from users and figure out what people actually want. We spend a lot of time listening to people and understanding the feedback deeply.

This is the way that we build a product. We always launch a little bit before it’s ready. We did this for Claude Code. When we launched Claude Code initially, it didn’t even support Windows. It also didn’t support a lot of different stacks, and then, over the coming weeks, we added support for every stack.

10. Observability and privacy

Now Claude Code supports every single stack: Windows, whatever weird Linux distro you use, and macOS. We support everything. For Claude Cowork, we also 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 Claude Code and for Claude Cowork, how do you go about things like observability and monitoring when you’re rolling out? Do you use any feature flags?

I’m more interested in whether you built custom tools for this or decided to use certain vendors. 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. This will not be a small operation, will it?

There are some off-the-shelf vendors that we use, and there’s some custom code that we use, so it’s a mix of both. There’s nothing too surprising about it.

One thing about Anthropic that’s kind of interesting is that, because we’re an enterprise company and we care a lot about privacy and security, we can’t see people’s data. If someone reports a bug, I actually can’t pull up your logs to see what’s going on. A lot of work goes into 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 Claude Cowork, what kind of learnings have you had so far? It’s been out for, I think, a few weeks now. Did you see something unexpected? Are you shaping the product based on feedback that you’re getting?

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 Claude Code first came out, it actually wasn’t an overnight hit. This is something people think it was, but it was sort of a slow takeoff at the beginning. I think the first big inflection was in May, when we released Opus 4 and Sonnet 4. That’s when it really clicked, and that’s when our growth became exponential.

At the beginning, it was 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 Claude Cowork, it’s a much steeper growth trajectory than Claude Code was at the beginning. It’s just been an instant hit, and that’s actually been very surprising. I didn’t really expect that.

11. Agent swarms

One of your new releases, which came out just very recently—it was, I think, yesterday or the day before when we’re recording this podcast—was Agent Teams. As I understand it, the idea with Agent Teams, or agent swarms, is that instead of a single agent, you can have a lead agent, and it can delegate to its different teammates. How did you start experimenting with this, and how did you decide to ship it now?

We’re always doing experiments. There are all sorts of ways to get more mileage out of Claude Code. One way 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 are just a lot of different approaches to get a little bit more mileage out of the context window.

There’s this one idea called uncorrelated context windows. That’s what we call it, and the idea is that you have multiple context windows, but they essentially start fresh. They don’t know about each other. An example of a correlated context window is if you have the model do a task and then have it do a second task in that same context window. In this case, the second task knows about the first one because it’s in the same window.

But for something like a subagent, it’s uncorrelated because the main agent prompts the subagent, but the subagent’s context window is fresh. Besides that prompt, it doesn’t know what’s in the parent context window. You can see this a little bit, for example, in subagents versus skills. When you run a skill, or a slash command, it sees the parent context window, whereas for a subagent, it doesn’t.

There are some cases where you want that context, and there are some cases when you don’t. There’s this interesting thing where uncorrelated context windows, and just throwing more context and more tokens at the problem, gives you better results when the windows are uncorrelated. It’s actually a form of test-time compute to do this.

For something like Agent Teams, we’ve been experimenting with this for a while, I think since maybe October or September or something like this. It really just felt like, with Opus 4.6, it clicked. The model figured out really how to use this. Sometimes you see these cute exchanges where the agents are talking to each other and discussing something, and it’s very cool to see. It’s very humanistic in a way.

Other times, you just get very good results. We had a bunch of internal evaluations, for example, where we had Claude build something very, very complex—something more complex than what a single Claude would build. We saw the results really, really improve with Opus 4.6 with Agent Teams. That’s why we felt it was the right time to release it.

We also wanted to be careful. The reason you have to opt into it, and the reason it’s a research preview, is that it uses a ton of tokens because it’s just a bunch of Claudes running. Not everyone wants this all the time. So we’re just excited to see how people use it and hear the feedback.

It’s something you want for fairly complex tasks. You probably don’t want this for every task. The main Claude decides the roles for the subagents. We don’t have a regimented way to do this. It’s context-specific, and I wouldn’t say there’s one right way to do it.

I think a lot of the magic of this comes out of the idea of uncorrelated 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 a one-size-fits-all. Have you seen use cases—even though I know it’s still research—where this approach, this swarm approach, looks promising?

Well, I guess I said before that plugins were fully built with swarms. There are a bunch of other features since then that are built in this way. So, yeah, I think for anything where you see a single Claude struggling, swarms can help. It’s interesting to look at.

Talking about change in general, with Andrej Karpathy you had a really interesting exchange back in December. He posted that he’d never felt as far behind as a programmer as he did then because of the progress with AI, and then you shared the story about how you started to debug a memory leak the old-fashioned way, and Claude one-shotted it.

I think it was a reflection of how everyone is feeling—that things are changing so fast—and during the holiday break, I started to feel that things had really shifted. How did you come to terms with this, or start to embrace this change?

This is something I really struggle with. The model is improving so quickly that the ideas that worked with the old model might not work with a new model. The things that didn’t work with the old model might work with a new model. It’s weird because there are just not a lot of other technologies like this, so I don’t really have a lot of experience to draw on to figure out how I should approach this. It’s been this new skill that I’ve had to learn.

In a way, it’s like you just always have to bring this beginner mindset. Honestly, I’m using the word humility a lot, but you always just have to bring this kind of intellectual humility. All of these ideas that were bad before are now good, and the inverse. I think that’s honestly it. It’s something I constantly have to remind myself about.

And back in the old world, when someone tried an idea again and we’d tried it in the past and it didn’t work, usually the feedback was, “Why are you doing this again?” We used to call this a bit of gatekeeping, but it was somewhat valid.

With architecture, someone would come and say, “Why don’t we do microservices?” and someone would say, “We tried it and it didn’t work.” If you tried it a year, 2, or 3 years ago, it was kind of valid, right? Because not much had changed.

Yeah, that’s right. And something like microservices is funny because every 10 years it goes in and out of style. But now, I think it’s the first time ever where it’s actually not crazy to just try the same idea every few months, because the model improves and it just works.

I actually see this with engineers on the team. People who are newer to the team, and people who are newer to engineering, sometimes do things in a better way than I do. I just have to look at them, learn, and adjust my expectations.

An example of this is that when we release features, sometimes I’ll screenshot myself using them on X or Threads or whatever, just to talk about it. But recently, Tariq, our DevRel guy—he actually codes a lot; he’s amazing—started automating this.

He’s having Claude Code generate its own videos for its launches, and he just started doing this. This is something I thought would be possible, maybe, but it’s not something I would have tried because I wouldn’t have thought the model was ready. He just did it, and it just kind of worked.

12. LLMs and the printing press analogy

One thing that I’ve felt is a bit odd, and I think a lot of developers can relate, is that I’ve come to terms with this starting with Opus 4.5. Similar models, like GPT-5.2, gave me a similar vibe as well. The models have just been really good at writing code, and I realize that I don’t think I’ll handwrite code when I want to get stuff done. If I actually want to get the pleasure of writing it, I can still do it.

But one thing I reflected on is that it’s just been so much effort to get good at coding. I remember when I was learning: I started by hacking around, then went to university, then learned C and C++, and it was just bloody hard. Actually, going through my first few jobs, I started to become better at it; I became better at debugging. There was 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 engineering manager, when we designed the interview loop at Uber, we talked with managers about what we needed to screen for, and we said, “What do developers do most of their time? About 50% of the time, they code.” Therefore, about 50% of the signal was all about coding.

There were a lot of things tied into coding because it’s just hard. I think we all know that it takes grit; it takes some level of intelligence to get good at it. There’s a sense of loss: I think it’s great, on one end, that the model can do it, but it feels like something really quickly got taken away that I personally didn’t think would happen this quickly. I think a lot of other people are feeling that.

Some people move on a bit easier, but there’s definitely this sense of grief. How did you think about it? Again, you’re an example: you wrote so much code at Facebook and also outside of it. I know it was just a tool for doing it, but not many people could do what you did. And now the models can also work as well as you did, if not better.

That’s the challenge. I think it’s something that used to be a thing that we did as software engineers; it’s becoming something that everyone is able to do.

When I started coding, it was a very practical thing and a way to get things done. At some point, I just fell in love with the art of coding, and with languages and the tools themselves. At some point, I fell down this rabbit hole. I wrote Programming TypeScript, a book about a programming language.

You wrote 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 found that book translated into Japanese in this tiny town, and that was just the coolest moment. Then I actually realized I don’t remember TypeScript at all, because I was only writing Python for a couple of years at that point.

At some point, I started the first and biggest TypeScript meetup in the world. That was in San Francisco, and I got to meet a lot of my heroes. There was Chris Kowal, who wrote General Theory of Reactivity. There was Ryan Dahl, the guy who made Node.js. It was one of the first times that I went really deep into this community, and into the language and the tools themselves.

For something like TypeScript, there’s this beauty in the types, in the type system, because Anders Hejlsberg is just brilliant. The idea of conditional types, and that anything can be a literal type—there are these very deep ideas that even the most hardcore functional languages do not have. Even something like Haskell doesn’t go this far, and Anders just took it and pushed it much further than it had been pushed.

Joe Pamer and a bunch of other folks explored a lot of these ideas and thought about this. I think for them it was also very practical, right? They had these large, untyped JavaScript codebases. How do you gradually migrate to something typed? You have to come up with these very beautiful ideas to do this.

For me, Scala was another rabbit hole that I fell into—the functional programming world. Still, when I write code and when the model writes code, I always think in the types first. What matters is the type signature. That matters more than the code itself, and getting that right.

So there is this beauty to it. There’s an art to it, for sure. But in the end, it’s a practical thing. 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 this moment in time that we’re in is the printing press in the 1400s or whatever.

Mhm.

Because at that moment, it was actually quite similar, right? There was a group of scribes who knew how to write. It was, as I understand it—of course, we never lived it—but as I imagine it, a hard process to learn. You needed to get the equipment. You probably needed some sponsorship or to be selected. You needed to practice because you had to produce the same thing over and over again, and few people could do that. I assume it was either high-prestige or highly paid, or who knows. Let’s assume it was. But then the printing press came along.

Yeah. Yeah, and at least in Europe, you had to have a lord or a king or something employ you, and then you had to go through years of training. There was this class of scribes that knew how to write. They were employed by someone like this, often the king or queen themselves, who were not literate. So it was this very, very niche skill, and less than 1% of the population was literate in Europe back then.

And then the printing press came out, and what happened? The cost of printed material went down something like 100× over the next, I think, 30 or 50 years, or something. The quantity of printed materials went up like 10,000× in the next 50–100 years. This was the first effect.

Literacy took a little while to catch up. So, I think global literacy went up to something like 70%, but that took another 200 or 300 years, because learning to read is just very hard. Learning to write is hard. It takes a lot of effort. It takes an education system. It takes infrastructure to have paper and ink and the free time to do this instead of working on a farm.

So it kind of took the early stages of industrialization to actually get there. But I think this effect of making it so this thing that was locked away in an ivory tower is now accessible to everyone—this is just… 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 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 analogy for the moment that we're in right now.

And it's interesting that you say that some of the kings were illiterate even though they were employing the scribes, because if we're being honest with ourselves, we have business owners who know what they want to build and are employing software engineers because they themselves cannot write code. I think we like to mock the CEOs who are coming to the scene. They might even have a drawn prototype or a whiteboard and say, “This should be easy,” but of course they don't understand how difficult it is.

But there seems to be a bit of an analogy where there's a person who wants what they want, but until now they needed to hire a software specialist who can build that, and there's always that disconnect between the idea and the person. Just like with the printing press, what would happen if they could actually express themselves? Like, the king could actually read or write their own letters. They wouldn't need that middleman, and things would become more efficient.

I mean, of course, for the scribe, it's not necessarily the best news, but the smart scribes can also do this, 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 ceased to be scribes, but now there's a category of writers and authors. These people now exist. The reason they exist is because the market for literature just expanded a ton.

And I guess also, if we think about back then, a scribe's work was read by a few people, and with the printing press, there are a lot more authors. Some of them are not really read, but some of them have wider reach than they could imagine. There are new careers that exist because of that.

Yeah, I love the analogy. And the most exciting thing for me is that it's just so impossible to say today what will happen after this transition happens. 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?

13. Standout engineer archetypes

We cannot predict, but I think we can look at what is working right now. If you look around in your environment, whether that be the team at Anthropic—software engineers, builders, or members of technical staff, however you call them—who, to you, are standouts? 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, these are the strongest people I've ever worked with in my career. There are all sorts of different archetypes. There are some people that are really amazing prototypers: take something from 0 to 0.5, just figure out what are some cool ideas, what is the technology unlock.

There are other people that are amazing at finding product-market fit, so kind of 0.5 to 1, or maybe 0 to 1. There are other people that span different disciplines, and I'm just seeing more and more of these people. Like I said, 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 hybrids.

What's a belief that changed from last year to this year? Something that you either believed, or a conviction that you had, that you've either revised or completely thrown away?

I think one thing I wasn't sure about is how big a problem safety is, to be totally honest. I joined Anthropic because, like I said, I read a lot of sci-fi, and I kind of 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 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: how do we make sure this thing goes well?

14. What skills still matter for engineers

I think it's safe to say you were a really great software engineer even before all the AI things started, and you seem to be a very productive engineer—of course, part of a team as well, but also individually. What are some skills of being a software engineer that are still as valuable, or maybe even more valuable, than before? And what are the ones that are maybe not as valuable and are best left behind?

Probably—okay, so the stuff that's left behind, or best left behind, is maybe 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. 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 just doesn't matter anymore.

I think something that still matters a lot today is being methodical and hypothesis-driven. This matters both in product design, in this world where everything is being disrupted and we need to figure out what to build next, and this is something everyone is thinking about. But it also matters for engineering day-to-day, something like debugging. You just have to be very methodical about it.

The model can do this and it can help a lot. But I think we're still 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 6 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 Claude Code—whatever the next startup is that becomes the next trillion-dollar startup—might just be 1 person that has some cool idea and whose brain 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 multidisciplinary, and this will become more and more rewarded. So, in some ways, I think this will be the year of the generalist.

I think the other skill that's actually been rewarded a lot is having a short attention span. I've seen that rewarded now.

Oh, yeah. It's like teenagers are using TikTok and all this stuff, and I think in some ways it's kind of dangerous for society because you want people that can think deeply and can contemplate ideas and aren't just moving on to the next idea very quickly.

But in some ways, I think this year is kind of the year that's going to reward it. It's like the year of ADHD. Because the work for me has become jumping between Claudes. It's become managing Claudes. And so it's not so much about deep work; it's about how good I am at context-switching and jumping across multiple different contexts very quickly.

Could I add that, from what I understood from what you said, maybe you could add one thing, which is adaptability? You're saying, of course, that it's ADHD and you can jump across, but of course earlier you were very good at focusing deeply on one thing as well.

What strikes me about you—and maybe this is true for other people as well—is that you're just 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 of is that whatever the next model that comes out, it will change again, and you need to be curious and open to adapting how you work, right?

Yeah.

15. Book recommendations

And as a closing question, what's a book or books that you would recommend?

I've gone down a Cixin Liu rabbit hole. He's the Three-Body Problem guy, but he actually has a lot of other really good books. I really love his short stories. He has a couple of books of short stories. I'm a big fan.

For people who are new to sci-fi and 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, with takeoff kind of starting to happen and kind of an AI singularity. And then it ends up with this kind of group of lobster consciousnesses orbiting Jupiter.

And it’s just amazing, and the thing that I think it really captures is just the pace, this quickening, quickening, quickening pace of how this feels. It really matches the feeling right now. And then on the technical side, I would strongly recommend Functional Programming in Scala. Even if language choice just doesn’t matter as much anymore, I think there is this art to functional programming that just teaches you how to code better.

If you read this book, I think what’s really important is to do the exercises also, and I’ve gone through and done all of them probably like 3 times over, and it’s just amazing. It really just knocks this idea of functional types into your head, and it’s just a thing you can’t stop thinking about.

Boris, thanks so much. This was awesome.

Yeah, thanks, Greg.

This was a really interesting conversation, and the thing that I keep coming back to is Boris’s printing press analogy: the idea that medieval scribes were this tiny elite who could write, employed by kings who themselves were often illiterate, and that we software engineers might be in a similar position today. We are the scribes. We spent years mastering this craft, and now the printing press is arriving.

But what Boris told me is that the scribes did not disappear. They became writers and authors, and the entire market for written work expanded beyond anything anyone could have predicted. I do find this hopeful, and I also appreciate that Boris didn’t sugarcoat it.

16. Claude Code's architecture

The other thing that stuck with me is just how differently the Claude Code team built software. No PRDs, no mandatory ticketing system, designers and data scientists and finance people all writing code and building dozens or hundreds of prototypes before shipping a feature. And Boris is shipping 20 to 30 pull requests a day without editing a single line by hand.

And there are different verification systems in place: Claude Code reviewing its code, automated lint rules, best-of-N passes, and human code review.