Anthropic's Surprise Hit: How Claude Code Became an AI Coding Powerhouse

Thanks for having me.

So amazing.

Not really. We started by building something that's useful for us. And I built a thing that, first and foremost, was just useful for myself. And it's something that I found myself using every day. And then I gave it to the team, and I saw that the team started using it every day. And pretty soon after we launched it, most of Anthropic was a daily active user. And so I think at that point we had kind of a hunch internally that maybe we had a hit on our hands, but it's still not obvious because it's in a terminal.

It's kind of a weird form factor. Everyone is coding in IDEs. Are people going to like this? Is it going to be that useful? Can you actually use it for a lot of coding? We had no idea.

It was very accidental. When I joined Anthropic, I did a lot of prototyping. And one of the prototypes that I built was this thing that just ran Claude in the terminal, just because, as an engineer, that was kind of the easiest thing to experiment with. And it didn't even code at first. Claude Code didn't code. It was called Claude CLI at the time.

And what it did was, I used it to automate my note-taking. So it kind of controlled my notes app, and it controlled my music player to play music for me. So I'm like, play this band, and it would go in and kind of automate that. And at first I was just using it to play around with the Anthropic API to figure out what kind of applications I could build on it. And just on a whim, tools came out recently, and I tried giving the model a Bash tool so it can use my Bash to use the command line.

And immediately the model just started coding. And it was just the craziest thing. As soon as it had Bash, it kind of knew, okay, I can write AppleScript and I can automate stuff and I can use this computer. And it just felt very native to the model in this way, and that was kind of a surprise. So I think that was a surprise. And then it was a surprise that this ended up as something useful, where it was able to edit code and the code came out really good and the model could intelligently reason about the way to edit code.

Yeah, something like that. It was late last year, so late in 2024.

Claude Code is an agentic coding tool. The way to think about it is, when engineers program, there are different ways to program, and this has changed over time. This has changed a lot over time. Fifty, 70 years ago, the way that people programmed looked very different than the way it does today. So, 70 years ago, if you talked to a programmer, they would've been like, "Oh yeah, I take my punch cards and I punch holes in them, and I put them in this IBM kind of typewriter-y thing, and it punches holes, and that's programming."

And then you feed this into this mainframe, it does some work, and then eventually you get some kind of result out, printed on a paper sheet.

Growing up, my mom would tell me stories about how her father, my grandfather, he was one of the first programmers in the Soviet Union. And he would come home and he would bring back these big stacks of punch cards. And when she was a little girl, she would take her crayons and just draw all over them. And this was growing up for her. This is actually something that I didn't know until later in life. I was far into my engineering career when I learned this was a thing.

There's something about just the visceral nature of this kind of physical programming. I don't think we're going to get that again.

But I think that was a special moment where you could feel the language and you could feel the computer in a really different way. And so I think after punch cards, it changed a lot. Software became a thing, and you could start to program directly in software. You didn't have to do this anymore. In the original programming software, it was emulating teletype. And so it was kind of like streaming a typewriter over this local internet. And that's how the text editors were built.

The way that you would code is still the way that actually most people code today before agentic coding came out. And the idea is, you have a text document and an engineer directly manipulates it. So you load it up in a special piece of software called the IDE. It's kind of like Microsoft Word or Google Docs, but just for code. And the engineer just manually edits the code using a keyboard. And this was the case for 50 years now?

No, 70 years. This has been the way that people programmed. ed and Vim, these were early 1970s. So yeah, it's been 50 years. And now it's starting to change for the first time. There's been a lot of work to try to evolve programming from direct text manipulation to something else. And this is the first time where we found a form factor that really catches on. And it took really great LLMs to do this. Models weren't really capable of doing this a year ago, but now they are.

The way that it works is, a human describes to the model the change that they want, and then the model is the one that manipulates the text. So it's this kind of next layer up where you're describing the change you want, and the model does all the work of doing the editing. We're still at this point today where you can do a lot of this through the model, but for complex changes, maybe it'll take a bunch of iterations. Maybe the last 20, 30%, you still have to open an IDE.

You have to go lower level to do these last-mile changes. And we think that over time, more and more of coding is just going to be the model doing it, and a human will have to intervene less and less.

The terminal is a little bit hard to explain if you're not a programmer because it's so low-level. It's something that most people will never ever touch and never ever see. It's something like in movies when you see this kind of green screen, green text going across the black screen, and there's like a hacking scene or something.

Very techie, yeah. And it's sort of, it's something every engineer uses. There's nothing kind of good or bad about it. It's just an interface. It's another way to interact with a computer. It's a little lower-level because it's not visual. So you can think of Claude Code, when we say Claude Code runs in the terminal, you can think of it just as a computer program. And some computer programs have user interfaces so a person can interact with them.

And some of them just kind of run in the background. So you can think of Claude Code as in that second category. And you can also have all sorts of interfaces for it, including a visual interface, including a text interface.

Yeah, it's a lot like that. Think text messaging before you could send images and videos and stuff. So just really simple interfaces, just back and forth.

Honestly, it was sort of an accident. We were thinking about what can we build in the coding space? It seems like the models are getting a lot better at coding, so maybe there's something that could be built here. And at the time, like I said, I was prototyping some of these ideas. Some of them were kind of coding-adjacent. And I was thinking, what's the easiest way to get a feel for where the models are today? Because there was this feeling where the models can do so much, but no one's yet built the product that can harness this capability.

In the AI world, we call this idea product overhang, where the model is just capable of all of these things and there isn't really yet a product that can capture this and let a person use it. I remember there was this moment back in—yeah, it was sometime late last year. The other engineer on the team, Sid, and I were in a room and we were whiteboarding, and we're like, okay, what do we build? And just in 15 minutes, we threw up a few ideas on the whiteboard.

We can do a CLI, we can do some sort of IDE extension, we can do something based on the web. And we kind of closed our eyes and just picked one. And it kind of seemed like CLI is the simplest. And generally, that's the way that I approach product, which is start with a simple thing first. So this kind of made sense. In hindsight, there were a lot of benefits of this too. And I think one of the big ones is that it kind of works anywhere.

So it doesn't matter what kind of system you're on. If you're on Mac or Windows, it doesn't matter what IDE you use, doesn't matter what your preferences are, and engineers are so opinionated and have so many different setups and preferences. It just works with all of them. And that's kind of the benefit of building at such a low level where you're not coupled to a particular Mac or Windows or a color scheme or whatever.

The way we think about it is the model is evolving so quickly that we build the minimal possible product to keep up with it. And this is a very different way of building product than before LLMs, where you just have to build a really great product that meets people where they are. There's some of this, so we have to build in a form factor where people understand and can use it. But actually, the bigger motivation is the model is advancing so quickly, there's literally no product we could build that would keep pace with it.

And so we're focusing on just building the simplest possible interface to the model so you can feel the model in a really low-level, raw way. And so that when the model gets better quickly, we can adapt quickly and you can feel the next model in that same kind of way. So today we're in a terminal. Claude Code also runs as IDE extensions. So there's extensions for VS Code-based IDEs and Cursor and so on, and also for JetBrains-based IDEs like IntelliJ. And then there's also a GitHub Action.

So you can mention Claude on GitHub. So it's just, you tag Claude, @Claude, and talk to them like you would a coworker, and they can make changes for you. There might be more interfaces coming soon. This is something we're always experimenting with, but generally the philosophy is we don't make really gorgeous interfaces like many other companies do and are really great at. We focus on just building the simple thing that shows off the model.

Yeah, people can choose the model. We support Sonnet 4 and Opus 4, and then we also use Haiku.

I think Anthropic has a lot of really great researchers and coders. And for us, this is kind of a natural way to think about the kinds of abilities the model should have, because you think about what should the model be able to do? And as a programmer, the first thing you think is, oh, it should be able to do this thing that I'm doing, and it should be able to help me, and I can pair with it like I would another engineer.

So I think, just at all levels and across the company, this is a way that we think about it. There's also something about it where maybe coding is the way that we get to the next level of intelligence, if you call it AGI or ASI or whatever. The model needs some way to interact with the world, and for a model, the natural way is code. And so the mission of the company is to build safe artificial intelligence for everyone, and safe ASI.

The way the model interacts is through code. And so this is the thing that we should start to learn about now. And this is also one of the reasons that we released Claude Code: just to learn how people use it, and to learn how to make this thing safe, to learn how it behaves in the wild so that we know what to do next.

Claude Code is for professional software engineers. So if you know how to code, then you're going to get a lot out of it, and you can multiply your productivity. We've seen people multiply their productivity many, many times over with, like, a fleet of Claude Codes that's running. And even with a single one, you can become a lot more productive. Interestingly, we've seen a lot of people use Claude Code for non-coding use cases.

So, for example, the data scientists at Anthropic all use Claude Code to write their queries, and designers use it to build small prototypes, and product managers use it to manage tasks. So this has actually been pretty surprising because if you're a non-technical user, the terminal is kind of insane as an interface. Like, I couldn't imagine why you would want this, but it sort of seems like because it's such a great agent generally, people are jumping over hoops to use it, even though it's not the easiest thing to use because, again, it's in a terminal, which is very technical.

There's another part of Claude Code, which is the SDK. And this is the way that people can build on top of Claude Code and build their own agentic applications. And this has also been pretty interesting because people are using the Claude Code SDK to build agentic coding applications and platforms and user interfaces on top of it. But they're also using it for all sorts of totally agentic use cases that are totally unrelated to coding. So anything where you need AI, maybe a few years ago you used APIs, and nowadays we find that some users are reaching for an agentic SDK as sort of the thing that you need to build AI apps of today.

Absolutely.

Yeah, when you think about the ways that LLMs work and the way you interact with them, there's the old kind of LLM, which is you send them a message and they send you a message back. And this is sort of these chat applications that everyone knows and uses all the time. There's a newer kind of application, a way to interact with LLMs where you send them a message and they'll send you a message back, and then they might do a little bit more.

So we call this tool use, one of the things that they might do. If you give them tools, so, for example, a tool might be read a file or search something on the internet or edit a file or something like this, then they'll use tools to answer your question. And so, for example, if you ask, "What's the weather today?" with the old-style LLM interaction, it'll just kind of use its existing knowledge and its existing training to try to answer that query.

But if it's agentic, what it might do is it'll say, "Okay, I'm going to look up the weather," and then maybe if it has some kind of tool to check the weather, it'll reach out to the internet or wherever that tool is. It'll use that tool, it'll get the response back, and then it'll answer the question. And this tool use, this is kind of the essence of being an agent, because without tools, it's very difficult to be agentic.

You could kind of do it without, but it's only since models started using tools and gained that new capability because we taught them that they started to get this new kind of agentic capability that we talk about.

And what this looks like in practice is maybe I'll ask the model, "I have a red button on my website, make it blue." And because it has a tool to read a file, it'll choose to read the file. It'll choose to read the file that has that button. Maybe if it doesn't know where that file is, it'll use a file search tool to find that file first, the same way that you might when you're looking for a file, you'll use a file search.

It'll then open that file, it'll read it, and that's another kind of file read tool. Then it might edit it. That's a different file edit tool. And then it'll write it back. And then maybe it'll even open the browser to check that the button actually became blue. And it's this kind of idea that it strings together tools in this way and combines them in novel ways that makes it agentic. There's also two concepts that are kind of related but different here.

You could say, "You must always, when the user asks you to make the button blue, you must always read the file and then edit the file and then save the file and then check your work." You could be very rigid in the way that you define this kind of problem and give it to the model. Generally, we call this a workflow. And this is distinct from something like an agent. So a workflow is something where a human thought through, for this kind of problem, here are the steps roughly that you should take.

For an agent, it's very different. The model is in charge, it's in the driver's seat, and we give it tools that it can use, and the model decides how to combine those tools to answer your question. I think going into the future, more and more things will be agentic because the model is getting more and more intelligent, so it can actually use these tools in pretty novel and interesting ways to answer questions.

Exactly. In the same way that a person might do it. If you have a problem, you're going to think about it for a bit, then you're going to think about what tools you have, and then you're going to combine the tools that you have in ways to do the thing that you want to do.

Claude Code can do pretty much anything that a person can do on their computer. There isn't really a limitation besides safety. This is something we think about a lot: to place intelligent limits on what it can do and put a human in the loop at the right points to make sure that if an action is potentially dangerous or destructive in any way, a human has to approve it first. But besides that, the model can do pretty much anything: reading files, writing files, running commands on the system, editing things.

It can reach out to the internet, obviously most of these, again, with human approval. And then there are ways to customize it however you want. So if you have a bunch of MCP tools, for example, to read your Jira issue tracker or to open a browser or to open an iOS simulator, the model can use these too.

Yeah, exactly. Claude Code is an MCP client and an MCP server. And what this means is, if you give it tools to use, so maybe at your company you have a bunch of MCP tools that you built for all your systems to integrate with. Like I said, maybe there's one to integrate with Jira, maybe there's another one to read Slack and maybe write messages to Slack. Maybe there's another one to fetch some internal knowledge base or something like this. You're going to plug this into a bunch of your tools.

You can plug it into Claude AI, into Claude Desktop. You can also plug it into Claude Code. So it gets all the same tools that you do.

Yeah, subagents are really exciting. And this actually started with a Reddit post. There was someone that posted on Reddit about how they have these subagents that they built for Claude Code, and they had a product manager subagent and an engineer and a designer subagent. And a couple of engineers on the team saw this and got really excited and felt that this is something that we should support a lot better. And the way subagents work is, when you start Claude Code, you have a Claude and you can talk to the Claude and it can do things for you.

Subagents are just other Claudes, and they're prompted a little bit differently. So you can customize what prompts they have, you can customize what tools they have. So, for example, you can say, "You are a really excellent QA engineer subagent. Your job is to verify that code is correct and to test code. And to do that, you have these tools at your disposal. Maybe you have a browser, iOS simulator, Android simulator. You're given code; your job is to test it."

You might have another engineer, another subagent that's maybe a project manager, and their job is to have tasks and then divide up tasks for other subagents. And so you can kind of split up all the work into these different roles. I think we're still figuring out what these roles are. There's one version of the world where the roles are kind of like on a regular engineering team, where you have engineers and designers and product managers and data scientists and so on. There's another world where actually subagents are a little bit more similar, and maybe every subagent can kind of do the same thing, but they kind of split up the work a little bit more.

So everyone is a generalist. And then Claude is in charge of figuring out how to launch the subagents and which particular subagents to use in which way, exactly the same way that it would use any other tool. So you can think of it as a really intelligent tool where the model can launch more Claudes to do things.

And you can define what those roles are.

Yeah. In the AI world, we talk a lot about this essay called "The Bitter Lesson." This was a Richard Sutton essay from a decade ago or something.

Where he talks about the more general model, most of the time in the long term, it'll subsume more specific models. And so what this means is, if you build an agentic system in this context, then the more general agentic system will generally outperform the more specific one in the long term. And I think where we're at today is models have the capability to do stuff, but if you give them too many tools or too much context or too much responsibility, it might be disappointing because they won't really know how to handle it.

And the models of a year ago could barely even call tools. The models of today are pretty good at doing it, but get a little bit overloaded sometimes with context or with too many tools. And so we can divide them up into subagents in this way. But I think that the models six or 12 months from now, they probably won't need this anymore because they're all going to be pretty good, and you won't have to define very rigidly what each one's responsibilities are anymore.

And so this is something we're building for people today because we think it's quite useful today, and it's something that we use a lot. But I could also see this going away at some point.

Yeah, that's probably one way to think about it. Generally, when we introduce Claude Code to new people, we actually suggest that, like you said, Claude Code can do everything. And this is one of the things that makes it a little bit hard to use if you're an engineer that's used to essentially text completions in an IDE. It's a very different kind of AI coding experience. And so generally, the thing that we recommend is start with something simple, like just ask questions about the codebase.

So don't even code, don't use any tools, just ask the model questions. What does this file do? Where is the file that does this thing? If I want to make a new whatever, how do I do that? So just ask it questions like that. And for this, generally the main model can do it, and you don't really need subagents. But then as you get a little bit more sophisticated, you might want to start splitting up the work. So if you ask the model maybe to make a small change, like I said, make the button red or make the button blue, you probably don't need subagents.

But if you do something a little bit fancier, like build a new section of the website that does blah, blah, blah, then you might want to have a few subagents. Maybe one is the software architect, and it's responsible for planning out the work. Another one is maybe some kind of reviewer, where it'll review that plan to make sure it looks good. Then maybe you'll have a few subagents that actually do the implementation. So maybe there's a frontend engineer, backend engineer, this kind of thing.

And then some kind of verifier at the end that verifies it. And then internally, we really love using a code simplification subagent. And its job is to take the code that was produced and just simplify it while making it still work.

There's a few different ways to pull in context and this kind of knowledge from the company. The simplest one is just looking at files. There's a few different approaches, actually, to reading files, so I'll go a little bit into depth into the way that actually happens. In the past, the thing that people used the most is this thing called RAG. And essentially, this is a technique where you take the whole codebase, and this actually works for any document, set of documents; it's not necessarily code.

But you take a set of documents like all the files in the codebase, you do this indexing step, and then you store essentially this database of all the knowledge that's in these files in a very, very particular form that makes it really easy for the model to search. There's a lot of trade-offs to doing this. The indexing takes time. It's pretty expensive to maintain this database. It's quite tricky practically to make sure that security is really good and privacy is really good.

Because it's very sensitive information, like your codebase. And so you want to keep it really safe. And so Claude Code actually doesn't use this technique called RAG. Instead, what it does is it just searches files the same way that a human would. You can think of it, at the engineering level, as using the tools glob and grep. These are two tools that are kind of built into the computer. And you can think of it as kind of Command+F for files.

So it'll just search around with text the same way that a human can. And what's kind of cool is if you just search for one piece of text, you might get the result you're looking for, but you might not. And depending on the results you get, as a human, you would refine your search term and you would try again, and you might try a few times to get the result you're looking for. And the model is really good at this. And this, again, this is one of those things that was not the case with models of a year ago.

But with models of today, they're excellent at this. And so we call this process agentic search. And what this means is using really, really simple search tools like Command+F and using them repeatedly and then adjusting the search terms over and over based on the result of the query. And this is something that we don't specifically tell the model to do. It's something that it just figures out because it's intelligent enough and it has the search tool. So this is the first form of memory, which is just looking at the contents of the codebase and understanding it in this way.

CLAUDE.md files. And all this is, is a special file, CLAUDE.md. You put it in your codebase, or you can put it in whatever folder you want, and use it to record memories. So at any point, you can tell Claude to remember something. So, for example, whenever I edit this file, I always want you to double-check it in a browser or something like this. You can tell Claude to remember this, and then it'll record it in the right CLAUDE.md so that it remembers it next time.

And I think one of the most powerful use cases we've seen with this is when people check this into their codebase and share it with their team. So it's a memory file. It's just a regular text file on the computer, but you don't keep it to yourself. You share it with all the other engineers on your team. And what it means is if Claude remembered something when you were using it, everyone on your team gets to benefit from that.

And it gets this really interesting effect where everyone on the team starts to contribute to this knowledge base and this kind of memory bank. And it's very simple. Again, it's a text file, so anyone can read it. It's very easy to edit these memories and see exactly what's in there. But everyone just starts to benefit, and it feels kind of magical because as your team uses Claude Code, it gets smarter and smarter. And kind of similar to building in the CLI, this is literally the simplest thing we could have done.

There's nothing simpler than this, I think, that we could have done to build memory. There's no special tools. There's no special prompting. There's nothing like this. It's just a file, and Claude kind of learns to use it.

Yeah, you have to add to it manually today. We've actually had a bunch of internal experiments to do automatic memory so Claude can automatically remember things. The problem is there's two ways in which it fails. One is that it remembers things that it shouldn't. So, for example, if I say, "Make the button blue," it might remember the user always wants the button to be blue. And maybe that's the case for this button. That's not the case for every button.

And then sometimes it doesn't remember very important things that it should remember. And so, for the last few months, we've been doing a lot of experiments to try to get this performance really good. And it's something we've been using internally. And at some point, when we're happy with it, it's something we're going to release for everyone. But generally, our bar is if we find ourselves really happy with it and we find ourselves using it every day, then we release it to everyone.

And this one's not quite there yet.

Yeah, I think this is one of those social problems—and maybe not social problems. This is one of those social dynamics that will change over the coming years as people use these tools more and more, is we need to figure out what are the roles of people on the team, and how do they interact with each other and interact with Claude. And this is maybe one very specific problem within that: who curates Claude's knowledge? And my feeling is that this is something where teams will kind of get more and more horizontal as a result of this because anyone is able to contribute in this way.

But it'll be interesting to see how it plays out.

The default behavior is that there's always a human in the loop. This is super important because, in the end, this is a model and it's not predictable. And you want to make sure that it doesn't do anything dangerous. So, yeah, there's always a human in the loop. So for actions that we know can't have any dangerous repercussions, for example, reading a file, we know this is inherently safe. We just let the model do this in the folder that you let it do this in.

But for other actions like editing a file or running a command or using the internet, this always needs a human in the loop, and it always needs a human to approve it. There's ways to reduce this burden a little bit. So, for example, if you find yourself always approving edits to the same file or always approving the same command, there's a settings file that you can configure across your team. And you can use this to essentially allowlist or blocklist certain commands or certain files that you always want the model to be able to edit without human approval, or you never want it to be able to run.

It's something that actually we've seen work quite well in these very regulated industries. And the reason is that it doesn't use any services except the API itself. So that's all it needs. And then everything else you actually don't need. And this is one of the nice side effects of not doing codebase indexing or anything like this, is it's just very easy to hook up to. So if, let's say, you're a bank and at your company you already have Bedrock approved, you can just use Bedrock and use Claude Code that way.

So you run it on people's laptops, and all you need is access to Bedrock. So, really easy to get approval for. And then if you want to use the Anthropic API or Vertex, you can use that too.

We tried really hard to make Claude Code something really beautiful that everyone feels is something that we put a lot of care into, because we did. And I think when you use Claude Code, you can feel that this is something that we use every day. At this point, most code at Anthropic is written using Claude Code, and almost everyone at Anthropic is using it every day. And when we look at customers that start to use Claude Code, they use it more and more and more.

And with a product like this, you want it to feel really smooth and really beautiful, and something you really enjoy using. And that's been really fun from an engineering and design point of view, because we built in a terminal. And like I said, terminals have been around for 50-plus years at this point. And it really feels like we're rediscovering how to design for a terminal, because since terminals were first invented, the design world moved to web, and then it moved to apps.

And there's kind of different design principles you can take here. And we try to apply these back to Claude Code, even though it's running in a terminal. And there's a lot of details that we spent a lot of time on, like the way that we represent statuses for every item with this kind of blinking dot that turns red or green to indicate whether it succeeded or failed. Even the loading indicator, like the spinner while Claude is working, we spent probably 30 or 40 iterations of this just to get it to feel just right, to make it feel so you know what's happening, but it's not giving you too much information, and it's also not jittering and moving around on you.

So, yeah, every part of the interface we iterated on probably more than you'd think.

At the beginning, I added maybe 20 of them, and then immediately people started suggesting changes, like, "Hey, how about this word? How about this word? How about this word?" So now, at this point, there's a pretty big list, and Claude can actually choose the word that best describes the task that it's doing. So it's up to Claude which word it wants.

Yeah, this is something that we were honestly really excited to see, how some people are just going—they're really figuring out how to run this thing at all hours of the day. Some people have this army of Claude Codes, like 5, 10, 20, that are just running in parallel all the time and just doing work. I talked before about how your Claude generally needs human approval to do work. There's actually ways to do it in a slightly more autonomous way too, if you want to run it for long periods.

Essentially, you need to set up a container for it and just give it some kind of a container to be in, and then it can run without approval in a way that is safe. And so there's a lot of people that do this. It's extremely exciting, but also the pricing structure that we had was really not cut out to actually serve these kinds of users. And there's also just a little—we call this abuse—where at the tail end, there's account sharing and things like this where people are just really not using it in the way that it's intended.

So generally for Claude Code, there's two pricing models today. One is you can get a subscription. There's Pro and then there's Max. And this is, I think, $20 a month, $100 a month, or $200 a month. And it has very, very generous rate limits. If you use only Opus, you'll run out of limits pretty quick, and then we'll switch you over to Sonnet. If you use Sonnet, then you can use much more of it than most people need. And almost everyone doesn't run into rate limits at all.

It's generally power users who run into it. And this is something that we're also thinking through, how to evolve this as we land features where people use more tokens and there's more subagents and there's more autonomy. Because we need to figure out a way that we can provide this to people in a way that's sustainable.

Exactly. Yeah, we want to support the community. We want to hear how people use Claude Code in these ways so that we can make sure that we can support that. That's super important to us.

Yeah, essentially, within a certain period of time, you have a certain number of tokens you can use. And then if you want pretty much unlimited usage without dealing with these limits, you can always just use an API key. And this way you can just use it as much as you want.

Yeah, we see people using it for all sorts of stuff, for all sorts of code-related tasks, everything from planning projects to managing tasks to actually writing code, testing code, debugging, which it's excellent at. So if something doesn't work, you can ask Claude to debug it. Writing unit tests, verifying code. Whenever there's issues in production, our first line of defense is to give it to Claude. So we have logs coming from GCP or whatever, we give this to Claude and it'll figure out what is the issue that's happening.

And it can even interact with Git and source control. So it can figure out what exactly caused a breakage or what exactly caused a regression. It can automatically fix it. So yeah, it's for every stage of the SDLC. And I think this is the first tool that really serves every stage in this way. And like I said before, we didn't intend it to be this way. It just happens to be very general, and Claude happens to be really good at using these tools.

And so this has been kind of accidental product-market fit across the entire lifecycle of engineering work.

Absolutely. When I think about the things that Claude Code is good at, I'll be a little bit self-critical. I feel like if you look at answering questions about the codebase and codebase research, I think it's like 10 out of 10 good. It's as good as it can get. When it comes to writing code, it's maybe like a 6 out of 10. It's pretty good. It won't get everything perfect. The next model will be better, and it's something that we keep improving.

When it comes to debugging code, it's maybe also like a 6 or 7 out of 10. So I think this codebase research and onboarding onto a codebase, it's really, really excellent at it. And at Anthropic, whenever new people join, on their second day, this is part of technical onboarding. We teach them, here's Claude Code. Here's the codebase. If you have any questions, don't bug engineers on your team, just ask Claude Code. And it can answer these questions probably better than they can because it can search around the code, it can look through history, it can look through pull requests and Slack, and just pull in all the context to answer all of these questions.

And what we saw is at Anthropic, technical onboarding used to take a few weeks, but now engineers are usually productive within the first few days. And they don't task their teams anymore. I think this is the biggest thing, where you don't need to bug your senior engineer or your manager anymore to get answers to your questions. You just ask Claude Code, and it can answer all these questions for you.

Yeah, I use it all day for all sorts of stuff. So obviously, like I said, codebase research. If I'm working on a piece of code I'm not familiar with, I'll just start by asking Claude Code to tell me about it. Whenever I'm working on a small feature, I'll usually use Claude Code in GitHub Actions. So I'll make a new GitHub issue, and then I'll say, "@Claude, implement this feature for me." And it'll just do it, usually in one shot.

And sometimes I'll do this on the command line too. So I'll just say, "Implement this feature and make a pull request," and I'll come back a few minutes later and it's done. Then there's this kind of other work where it's a little bit more complex. You can't really do it in one shot. It's not as simple as changing a piece of text or changing a button or building a small feature. Maybe it's something more involved. There's probably two workflows I have here.

One is for really complex stuff: I'll prototype it a bunch. And this is something that I did even before Claude Code. When you write a complex piece of code or a complex feature, often engineers will write it a few times because you don't actually know the right way to do it. And so you'll try one approach, you'll try a second approach, you'll try a third approach, and you'll kind of figure out the edge cases for each and kind of the limitations, and you'll get a feel for the problem this way.

And this is something I used to do by hand. Nowadays, I'll just tell Claude Code to do it. So I'll maybe make a few Git worktrees, I'll launch a few Claudes, and then in parallel, I'll tell them, "Here's your job. I want you to implement this feature. Go to town." And I'll then look at each of the solutions and try to figure out, okay, maybe I like this piece of this one, this piece of this one, this piece of this one. And then I'll throw away all that code.

I'll just discard it. And then I'll start a new Claude and I'll tell it, "Okay, here's how I want you to do it," now that I got a feel for the problem. And then I think the last workflow is actually the one I probably use the most. And this is probably for medium-sized features. And in this one, I'll ask Claude to make a plan, and I'll go back and forth with it a little bit on that plan. And it's really important, actually, to get that plan right and to make sure it's the same thing you have in mind.

Before you continue. Because otherwise, what I see sometimes is people ask Claude for a little bit too much. Maybe it's a complex feature, and then it wrote it in some way that it's not at all what you wanted. But the problem isn't that Claude doesn't know how to do it. The problem is that the description is just too low-bandwidth. You only described in a few words what you want. And so the idea that Claude got of it is a very different idea than what you had in mind.

And so I find that planning helps a lot. So you iterate on the plan the same way that you would with anyone else you're working with. And then once that's ready, I'll ask Claude to write the plan to a file, maybe, and then I'll tell it to kind of implement that plan, and it'll naturally make a to-do list for itself to implement it.

Yeah, my feeling is there's kind of two dynamics here. One is that this is just a giant market. The market, you could think of it as all of coding. You could think of it as all of creativity and creating things, because this extends, at some point, beyond coding to design and things like this. So I think there's room for everyone. It's a giant market. And the biggest thing that these companies should be thinking about is everyone that's not yet using AI for coding.

Because if you only focus on people that use AI for coding already, these are the early adopters. So you want to kind of get into that curve and get the middle and the late adopters too. And many of these don't even use AI today. So I think it's a big market. I personally use a lot of these products, and I use Claude Code every day, but I also use Cursor every day and I use other products every day. So there's room for all of these, and they all kind of fit together into people's workflows.

The second way to think about it is, like I said before, the model is getting better so quickly that the kinds of things it's able to do are just changing every few months. It's this exponential that just keeps accelerating. And this is really the feeling inside of the lab, working on AI and kind of building this stuff. And hopefully it's also the feeling that users have as you get to use all these new products that are coming out every few weeks, or maybe a few days at this point.

So yeah, it's really exciting. And I think my advice to companies building is definitely: build for what the model will be able to do six months from now, not for what the model can do today. This is probably the single biggest advice. And this is something that we followed for Claude Code also. Claude 3.5, it was okay. Claude 3.7, it was fine. It was pretty good. But then when Sonnet 4 and Opus 4 came out, that's when it really hit its stride, and we felt like the product was really good and we started to be able to use it for a lot of coding.

And so this is the biggest way I would think about it, is: how do you build the product that captures the model capabilities six, maybe even 12 months from now? And the market for those capabilities is just going to be huge.

I think the biggest thing is just use all these products and see where they stumble, and try to get a feel for the model itself. I think Claude Code is a really good way to do that. There's probably other ways too, but try to get away from all the scaffolding and all the products people have built around it and just get a feel for the model's capabilities in as raw a form as you can, and try to get your head around the limitations.

Where exactly does the model stumble today? What is exactly that frontier where it's not very good, and then sometimes it's good, and maybe 50% of the time it's good? You can kind of get a feel for this frontier. And with the models today, a lot of this is around kind of agentic work, where it can use tools really well, and then at some point maybe it'll fall over when there's too much context or too many tools, or the trajectory is too long.

Maybe if you've been running Claude for two hours, it loses track after a little bit. So there's some sort of frontier here. Maybe there's another frontier around code quality, where today I have to maybe correct the model when maybe there's something that it does that isn't exactly the way I would've written it. And I think over time models will get better at understanding this too. So I would just try to use the model in as raw a form as you can and get a feel for these frontiers in the domain you care about.

So for coding, maybe it's kind of how long the trajectory is and whether the model can stay on track, and then the quality of the code, and probably a bunch of other stuff. And then for non-coding domains, there's a lot more.

I think there's probably room for both. And my personal take is probably there's going to be more stuff built on top of the platform than there will be built in-house, just because there's so many things to build and there's just not enough time and enough people and energy to build all those things. So I think a lot of the innovation is going to happen on top of the APIs and SDKs that are built.

Yeah, it's a little bit hard to say. A few years from now, in AI time, is like decades in normal time. I think even today, for a lot of professional coders, it's really easy to lament the state of coding and to think, "I used to write this code by hand, and now it's this agent doing all of it." I think actually being the one that does this work, it's incredibly exciting to have an agent write the code. It feels very empowering as an engineer because I can explore a lot more ideas than I could before.

I can do it much faster. I can work in domains that I know literally nothing about. Maybe I don't know iOS, but I can write an app because I can just generate code, review the code, and I can see it looks reasonable, but Claude actually does all the writing and all the testing of it. There's one engineer on the team, Lena. She still writes C++ on the weekend sometimes by hand. She was telling me because, as a programmer, this is kind of one of the things that we enjoy.

Sometimes you have to get down to the metal and you have to kind of do it this way. But I see this as a transition, the same way that in the '60s, there was this transition between punch cards and assembly, and then later on between assembly and Fortran and COBOL and the first high-level languages. And I think this is just another next transition. It's hard to know exactly how this is going to play out. I think one way it will definitely play out is it's going to change programming, where programming is no longer direct text manipulation, but it's more working with agents to get the work done.

And I think it's going to be hugely empowering, where a lot of people that couldn't create before can now create. And even if maybe you don't know anything about apps, you can use Lovable or you can use another platform to build cool stuff that you couldn't before. And this is just hugely exciting.

I think for people that are learning coding today, it's actually harder than it was when I was learning coding because not only do you have to know coding, because you still have to understand the languages, you still have to understand the frameworks, you still have to understand system design and all this stuff, but also you have to use all these tools, and you have to do both. You have to hold both in your head at once. So you have to code so that you can check what the model does, and you know how to direct it, because you still have to know what you're doing, with the models of today, in order to direct coding agents effectively.

But at the same time, you have to be using all this new technology. You have to be using Claude Code, and you have to be using all these new agentic coding tools, because this is what the future is. And I think it's hugely important to understand what these are and what it lets you do, and to learn how to function both when writing code manually and when using these tools.

Yeah, there's a lot of stuff we're working on. We landed native Windows support recently, and we're working on single-file distribution. You don't need Node.js anymore. You can just use Claude Code, and it's a single binary that you can use anywhere. So, much more portable. We're working on getting Claude Code into more places. So wherever you are, you can use Claude Code more easily, the same way that you can on GitHub today. And expect a lot more agents. Be able to launch agents, agents managing agents, and a lot more kind of freedom this way, and continuing to level up the state of the art and figure out what's next.

But I would say overall, we don't really know. Still, we're testing stuff out, and we have a lot of ideas, and we don't know what's going to work, but we're excited to show what we come up with and see if people like it.

Yeah, thank you, Matt.