- Claude Code employs a strong "dog-fooding" strategy, where internal engineers prototype and validate features, enabling rapid development and shipping of new functionalities.
- The tool's terminal-based design and flexibility allow for extensive customization through slash commands, scripts, and a "memory" file, catering to diverse developer workflows.
- The Claude Code SDK provides a powerful framework for building and customizing general-purpose AI agents across various domains, streamlining agent development for users.
Building and prototyping with Claude Code
- Claude Code's rapid feature development is driven by product-minded engineers who prototype new features for internal "Ants" (Anthropic employees) before external release.
- The design leverages the familiarity of the terminal, making new feature onboarding straightforward through primitives like slash commands and custom
hooksthat are essentially scripts. - Small companies and indie developers frequently use
auto-accept modefor autonomous edits andmulti-Claudingto run multiple Claude Code sessions concurrently. - Engineers at larger companies benefit from
plan mode, which instructs Claude Code to analyze the codebase and formulate an engineering plan for complex tasks. - Customization is achieved by investing in the
CLAUDE.md file(to provide context and memory), creatingcustom slash commands(for recurring prompts), and addingcustom hooks(for event-driven automation). - The Claude Code
SDKoffers core agent building blocks, including system prompts and custom tools, handling the agent loop, permissions, and API interactions to accelerate agent prototyping. - To get the best results from Claude Code, clearly communicate your goals, expected output, and any design constraints, treating the interaction like working with another engineer.
- If Claude Code produces unexpected results, asking it "why" it made a specific decision can serve as a debugging technique to understand its reasoning.
multi-Clauding — The practice of running multiple independent Claude Code sessions simultaneously, often for different tasks or within separate workspaces.
dog-fooding — An internal development strategy where a company uses its own products or services to test and improve them before wider release.
agentic tool — A software tool designed to act as an intelligent agent, capable of understanding context, making decisions, and performing tasks autonomously.
auto-accept mode — A Claude Code setting that allows the agent to make code edits without requiring manual approval for each change.
plan mode — A feature in Claude Code that enables the agent to analyze a codebase and generate a comprehensive engineering plan before initiating code modifications.
CLAUDE.md file — A Markdown file used by Claude Code as its "memory," where developers can store project goals, architectural details, best practices, and important context.
slash commands — Custom commands, prefixed with a slash, that users define in Claude Code to quickly trigger specific actions or frequently used prompts.
hooks — Customizable scripts or functions that can be configured to run automatically in response to specific events within Claude Code, such as before a commit or after task completion.
SDK — Software Development Kit; a collection of tools, libraries, and documentation that enables developers to build applications for a specific platform or system.
These developers tend to like to run multiple Claude sessions at once, and they've started calling this multi-Clauding. So you might see sessions where people have like six clouds open on their computer at the same time. Hey, I'm Alex. I lead Claude relations here at Anthropic. Today we're going to be talking about Claude Code, and I'm joined by my colleague, Kat. Hey, I'm Kat. I'm the product manager for Claude Code. Kat, I want to kick this off just talking about the insane rate of shipping in Claude Code. It feels like literally every time I open it up in my terminal, there's a new product, or a new feature, something for me to use. Can you walk me through what the process looks like of the team going from an idea to actually shipping something to end users? Yeah, so the Claude Code team is full of very product-minded engineers, and a lot of these features are just built bottoms up. It's like you're a developer, and you really wish you had this thing, and then you build it for yourself. And the way that our process works is, instead of writing a doc, it's so fast to use Claude Code to prototype a feature that most times, people would just prototype the feature, and then they ship it internally to Ants. And if the reception is really positive, then that's a very strong signal that the external world will like it to. And that's actually our bar for shipping it externally. And then of course, there's always features that aren't exactly right, then need some tweaking. And if we feel like, okay, Ants aren't really using it that much, then we just go back to the drawing board, and we say, okay, what else could we change about this? And when we say ANC, we mean anthropic employees. Yes, yes. That's really fascinating. I've never seen a product have as strong of a dog-fooding loop as Claude Code. Do you think that's something we purposely did, or that just naturally arise from the product itself? It is quite intentional, and it's also a really important reason why Claude Code works so well. Because it's so easy to prototype features on Claude Code, we do push people to prototype as much as possible. But it's hard to reason about exactly how a developer will use a tool, because developers are so heterogeneous in their workflows. So oftentimes, even if you theoretically know you want to do something, even if you theoretically know that you want to build an IDE integration, there's still a range of potential ways you could go about it. And all of them prototyping is the only way that you can really feel how the product will actually be in your workflow. So yeah, it's through the process of dog-fooding that we decide what version of a feature we decide to ship. I see. And there's something about almost the flexibility, but also the constraints of the terminal two that allows for easy addition of new features, which I've kind of noticed, where it's like because we have the primitives built out of like slash commands and things, it's easy to add another one on top of that. Yeah, it's totally designed to be customizable. Yeah. And because so many developers are familiar with the terminal, it makes like new feature onboarding super straightforward. Because for example, for a feature like hooks, which lets you add a bit of determinism around Claude Code events, because everyone, every developer knows how to write a script. And really, at the end of the day, all hook is a script. And so you don't need to learn a new technology to customize Claude Code. You write this script that you already know how to do, and then you add it to one of the Claude Code events, and now you have some determinism. We're really trying to meet customers or developers where they are, I guess, but this tool. Yeah. Switching gear slightly, so alongside this insane rate of shipping is also the insane growth rate of Claude Code with developers everywhere. Can you walk me through what that's been like to kind of be on this rocket ship? And how are we seeing various developers, whether it's at startups or individuals, or even large enterprises use Claude? So one of the magical things about Claude Code is that the onboarding is so smooth. After you do the NPM install, Claude Code kind of just works out of the box without any configuration. And this is true whether you're an indie developer, through to, if you're an engineer at a Fortune 500. I think this is the magic behind Claude Code because it has access to all of the local tools and files that you have. You have this very clear mental model for what Claude Code is capable of. Would you see different case patterns, though, between smaller companies and larger ones? We find that engineers at smaller companies tend to run Claude more autonomously using things like auto-accept mode, which lets Claude make edits by itself without approval of each one. We also find that these developers tend to like to run multiple Claude sessions at once. And they've started calling this multi-Clauding. So you might see sessions where people have like six Claudes open on their computer at the same time. Maybe each of them are in a different Git workspace or in a different coffee of the Git repo. And they're just like managing each of them. Whenever anyone stops and asks for feedback, they'll jump in there and then send it off and let it continue running. And on the other end of the spectrum for larger companies, we find that engineers really like to use plan mode. So plan mode is a way for developers to tell Claude Code to take good second, explore the code base, understand the architecture, and create an engineering plan before actually jumping into the code itself. And so we find that this is really useful for harder tasks and more complex changes. So going back to multi-Clauding just because I think that's a fascinating concept. I'm sure we kind of imagined a folks wanting to do things like that, but maybe it was somewhat surprising. Is there other things in that domain of like, oh, wow, this is a usage pattern that we really did not expect that have kind of popped up organically? And we've shifted our roadmap around a little bit? Yeah, I think multi-Clauding is the biggest one because this is something that we thought was just a power user feature that like a few people would want to do. But in fact, this is actually a really common way in which people use Claude. And so for example, they might have one Claude instance where they only ask questions and this one doesn't edit code that way they can have another Claude instance in the same repo that does edit code and these two don't interfere with each other. Other things that we've seen are people really like to customize Claude Code to handle specialized tasks. So we've seen people build like SRE agents, on Claude Code, security agents, incident response agents. And what that made us realize is that integrations are so important for making sure Claude Code works well. And so we've been encouraging people to spend more time to tell Claude Code about, hey, these are the CLI tools we commonly use. Or to set up remote MCP servers to get access to logs and ticket management software. When these engineers are customizing Claude Code, does that mean they're creating sub-angents or they creating markdown files like CLAUDE.md files? How exactly are they creating these different types of agents? Yeah, I think the most common ways that we've seen people customize is by investing a lot into the CLAUDE.md file. So the CLAUDE.md file is our concept of memory. And so it's the best place for you to tell Claude Code about what your team's goals are, how the code is architected, any gotchas in the code base, any best practices. And investing in CLAUDE.md, we've heard dramatically improves the quality of the output. The other way that people customize Claude Code is by adding custom slash commands. So if there's a prompt that you're always typing, you can add that into the custom slash command and you can also check these in so that you share them with the rest of your team. And then you can also add custom hooks. So if, for example, you want Claude Code to run lints before it makes a commit, this is something that's great for a hook. If you want Claude Code to send you a Slack notification, every time it's done working, this is actually the original inspiration for making hooks. And so these are all customizations that people are building today. Tell me more about what is the Claude Code SDK? The Claude Code SDK is a great way to build general agents. Claude Code SDK gives you access to all of the core building blocks of an agent, including you can bring your own system prompts, you can bring your own custom tools. And what you get from the SDK is a core agent loop where we handle the user turns and we handle executing the tool calls for you. You get to use our existing permission system so that you don't need a build one from scratch. And we also handle interacting with the underlying API. So we make sure that we have back off. If there's any API errors, we very aggressively prompt cash to make sure that your requests are token efficient. If you're prototyping, building an agent from scratch, if you use the Claude Code SDK, you can get up and running with something pretty powerful within like 30 minutes or so. We've been seeing people build really cool things with it. We open sourced our Claude Code on GitHub integration, which is completely built on the SDK. And we've seen people build security agents on it, SRE agents, incident response agents. And these are just within the coding domain. Out of the coding, we've seen people prototype legal agents, compliance agents. This is very much intended to be a general SDK for all your agent needs. The SDK is pretty amazing to me. I feel like we've lived in the single request API world for so long. And now we're moving to next level abstraction almost where we're going to handle all the nitty gritty of the things you mentioned. Where is the SDK headed? What's next there? We're really excited about the SDK as the next way to unlock another generation of agents. We're investing very heavily in making sure SDK is best in class or building agents. So all of the nice features that you have in Claude Code will be available out of the box in the SDK. And you can pick and choose which ones you want to keep. So for example, if you want your agent to be able to have a 2D list, great. You have the 2D list tool out of the box. If you don't want that, it's really easy to just delete that tool. If your agent needs to edit files, for example, to update its memory, you get that out of the box. If you decide, OK, mine won't edit files or edit files in a different way, you can just bring your own implementation. OK, so it's extremely customizable. Basically, general purpose in the sense that you could swap out the system problem through the tools for your own implementation. And they just nicely slot in to whatever thing you're building for, whether it's in an entirely different domain than code. Yeah, totally. I'm really excited to see what people hack on top of this. I think especially for people who are just trying to prototype an agent, this is like, I think, by far the fastest way to get started. We really spent almost a year perfecting this harness. And this is the same harness that Claude Code runs on. And so if you want to just jump right into the specific integrations that your agent needs, and you want to jump right into just working on the system prompt to share context about the problem of space with the agent. And you don't want to deal with the agent loop. This is the best way to circumvent all the general purpose harness and just add your special sauce to it. All right. Well, you heard it here. You got to go build on the SDK. Before we wrap up here, I'm really curious to hear your own tips for how you use Claude Code. And what are some best practices we can share with developers? When you work with Claude Code or any agentic tool, I think the most important thing is to clearly communicate what your goals are to the tool. I think a lot of people think that prompting is this magical thing, but it really isn't. It's very much about, OK, did I clearly articulate what my purpose is, like what my purpose with this task is, how I'm evaluating the output of the task, any constraints in the design system. And I think usually, when you can clearly communicate these things, Claude Code will either be able to do them or just tell you that, OK, this thing, I'm not able to do because ABC and you want to try DEF instead. So it's all about the communication, just as if you were working with another engineer. Yeah, totally. And another thing is, if you noticed that Claude Code did something weird, you could actually just ask it why I wanted to do that. And it might tell you something like, OK, there was something in the CLAUDE.md that said this, or I read something in this file that gave me this impression. And then that way, you could actually use talking to Claude as a way to debug. It doesn't always work, but I think it's definitely we're trying, and it's a common technique that we use. Use Claude Code to debug Claude Code. Yeah, yeah. Like the same way that you, when working with a human, if they say something that you didn't expect, you might feel like, oh, interesting. Like, what gave you that impression? Or why did you think this? And I think you can do the same with the agency. Yeah, it's fascinating. Well, Cat, this has been great. We really appreciate the time. Thanks for having me.
TL;DR
- Claude Code employs a strong "dog-fooding" strategy, where internal engineers prototype and validate features, enabling rapid development and shipping of new functionalities.
- The tool's terminal-based design and flexibility allow for extensive customization through slash commands, scripts, and a "memory" file, catering to diverse developer workflows.
- The Claude Code SDK provides a powerful framework for building and customizing general-purpose AI agents across various domains, streamlining agent development for users.
Takeaways
- Claude Code's rapid feature development is driven by product-minded engineers who prototype new features for internal "Ants" (Anthropic employees) before external release.
- The design leverages the familiarity of the terminal, making new feature onboarding straightforward through primitives like slash commands and custom
hooksthat are essentially scripts. - Small companies and indie developers frequently use
auto-accept modefor autonomous edits andmulti-Claudingto run multiple Claude Code sessions concurrently. - Engineers at larger companies benefit from
plan mode, which instructs Claude Code to analyze the codebase and formulate an engineering plan for complex tasks. - Customization is achieved by investing in the
CLAUDE.md file(to provide context and memory), creatingcustom slash commands(for recurring prompts), and addingcustom hooks(for event-driven automation). - The Claude Code
SDKoffers core agent building blocks, including system prompts and custom tools, handling the agent loop, permissions, and API interactions to accelerate agent prototyping. - To get the best results from Claude Code, clearly communicate your goals, expected output, and any design constraints, treating the interaction like working with another engineer.
- If Claude Code produces unexpected results, asking it "why" it made a specific decision can serve as a debugging technique to understand its reasoning.
Vocabulary
multi-Clauding — The practice of running multiple independent Claude Code sessions simultaneously, often for different tasks or within separate workspaces.
dog-fooding — An internal development strategy where a company uses its own products or services to test and improve them before wider release.
agentic tool — A software tool designed to act as an intelligent agent, capable of understanding context, making decisions, and performing tasks autonomously.
auto-accept mode — A Claude Code setting that allows the agent to make code edits without requiring manual approval for each change.
plan mode — A feature in Claude Code that enables the agent to analyze a codebase and generate a comprehensive engineering plan before initiating code modifications.
CLAUDE.md file — A Markdown file used by Claude Code as its "memory," where developers can store project goals, architectural details, best practices, and important context.
slash commands — Custom commands, prefixed with a slash, that users define in Claude Code to quickly trigger specific actions or frequently used prompts.
hooks — Customizable scripts or functions that can be configured to run automatically in response to specific events within Claude Code, such as before a commit or after task completion.
SDK — Software Development Kit; a collection of tools, libraries, and documentation that enables developers to build applications for a specific platform or system.
Transcript
These developers tend to like to run multiple Claude sessions at once, and they've started calling this multi-Clauding. So you might see sessions where people have like six clouds open on their computer at the same time. Hey, I'm Alex. I lead Claude relations here at Anthropic. Today we're going to be talking about Claude Code, and I'm joined by my colleague, Kat. Hey, I'm Kat. I'm the product manager for Claude Code. Kat, I want to kick this off just talking about the insane rate of shipping in Claude Code. It feels like literally every time I open it up in my terminal, there's a new product, or a new feature, something for me to use. Can you walk me through what the process looks like of the team going from an idea to actually shipping something to end users? Yeah, so the Claude Code team is full of very product-minded engineers, and a lot of these features are just built bottoms up. It's like you're a developer, and you really wish you had this thing, and then you build it for yourself. And the way that our process works is, instead of writing a doc, it's so fast to use Claude Code to prototype a feature that most times, people would just prototype the feature, and then they ship it internally to Ants. And if the reception is really positive, then that's a very strong signal that the external world will like it to. And that's actually our bar for shipping it externally. And then of course, there's always features that aren't exactly right, then need some tweaking. And if we feel like, okay, Ants aren't really using it that much, then we just go back to the drawing board, and we say, okay, what else could we change about this? And when we say ANC, we mean anthropic employees. Yes, yes. That's really fascinating. I've never seen a product have as strong of a dog-fooding loop as Claude Code. Do you think that's something we purposely did, or that just naturally arise from the product itself? It is quite intentional, and it's also a really important reason why Claude Code works so well. Because it's so easy to prototype features on Claude Code, we do push people to prototype as much as possible. But it's hard to reason about exactly how a developer will use a tool, because developers are so heterogeneous in their workflows. So oftentimes, even if you theoretically know you want to do something, even if you theoretically know that you want to build an IDE integration, there's still a range of potential ways you could go about it. And all of them prototyping is the only way that you can really feel how the product will actually be in your workflow. So yeah, it's through the process of dog-fooding that we decide what version of a feature we decide to ship. I see. And there's something about almost the flexibility, but also the constraints of the terminal two that allows for easy addition of new features, which I've kind of noticed, where it's like because we have the primitives built out of like slash commands and things, it's easy to add another one on top of that. Yeah, it's totally designed to be customizable. Yeah. And because so many developers are familiar with the terminal, it makes like new feature onboarding super straightforward. Because for example, for a feature like hooks, which lets you add a bit of determinism around Claude Code events, because everyone, every developer knows how to write a script. And really, at the end of the day, all hook is a script. And so you don't need to learn a new technology to customize Claude Code. You write this script that you already know how to do, and then you add it to one of the Claude Code events, and now you have some determinism. We're really trying to meet customers or developers where they are, I guess, but this tool. Yeah. Switching gear slightly, so alongside this insane rate of shipping is also the insane growth rate of Claude Code with developers everywhere. Can you walk me through what that's been like to kind of be on this rocket ship? And how are we seeing various developers, whether it's at startups or individuals, or even large enterprises use Claude? So one of the magical things about Claude Code is that the onboarding is so smooth. After you do the NPM install, Claude Code kind of just works out of the box without any configuration. And this is true whether you're an indie developer, through to, if you're an engineer at a Fortune 500. I think this is the magic behind Claude Code because it has access to all of the local tools and files that you have. You have this very clear mental model for what Claude Code is capable of. Would you see different case patterns, though, between smaller companies and larger ones? We find that engineers at smaller companies tend to run Claude more autonomously using things like auto-accept mode, which lets Claude make edits by itself without approval of each one. We also find that these developers tend to like to run multiple Claude sessions at once. And they've started calling this multi-Clauding. So you might see sessions where people have like six Claudes open on their computer at the same time. Maybe each of them are in a different Git workspace or in a different coffee of the Git repo. And they're just like managing each of them. Whenever anyone stops and asks for feedback, they'll jump in there and then send it off and let it continue running. And on the other end of the spectrum for larger companies, we find that engineers really like to use plan mode. So plan mode is a way for developers to tell Claude Code to take good second, explore the code base, understand the architecture, and create an engineering plan before actually jumping into the code itself. And so we find that this is really useful for harder tasks and more complex changes. So going back to multi-Clauding just because I think that's a fascinating concept. I'm sure we kind of imagined a folks wanting to do things like that, but maybe it was somewhat surprising. Is there other things in that domain of like, oh, wow, this is a usage pattern that we really did not expect that have kind of popped up organically? And we've shifted our roadmap around a little bit? Yeah, I think multi-Clauding is the biggest one because this is something that we thought was just a power user feature that like a few people would want to do. But in fact, this is actually a really common way in which people use Claude. And so for example, they might have one Claude instance where they only ask questions and this one doesn't edit code that way they can have another Claude instance in the same repo that does edit code and these two don't interfere with each other. Other things that we've seen are people really like to customize Claude Code to handle specialized tasks. So we've seen people build like SRE agents, on Claude Code, security agents, incident response agents. And what that made us realize is that integrations are so important for making sure Claude Code works well. And so we've been encouraging people to spend more time to tell Claude Code about, hey, these are the CLI tools we commonly use. Or to set up remote MCP servers to get access to logs and ticket management software. When these engineers are customizing Claude Code, does that mean they're creating sub-angents or they creating markdown files like CLAUDE.md files? How exactly are they creating these different types of agents? Yeah, I think the most common ways that we've seen people customize is by investing a lot into the CLAUDE.md file. So the CLAUDE.md file is our concept of memory. And so it's the best place for you to tell Claude Code about what your team's goals are, how the code is architected, any gotchas in the code base, any best practices. And investing in CLAUDE.md, we've heard dramatically improves the quality of the output. The other way that people customize Claude Code is by adding custom slash commands. So if there's a prompt that you're always typing, you can add that into the custom slash command and you can also check these in so that you share them with the rest of your team. And then you can also add custom hooks. So if, for example, you want Claude Code to run lints before it makes a commit, this is something that's great for a hook. If you want Claude Code to send you a Slack notification, every time it's done working, this is actually the original inspiration for making hooks. And so these are all customizations that people are building today. Tell me more about what is the Claude Code SDK? The Claude Code SDK is a great way to build general agents. Claude Code SDK gives you access to all of the core building blocks of an agent, including you can bring your own system prompts, you can bring your own custom tools. And what you get from the SDK is a core agent loop where we handle the user turns and we handle executing the tool calls for you. You get to use our existing permission system so that you don't need a build one from scratch. And we also handle interacting with the underlying API. So we make sure that we have back off. If there's any API errors, we very aggressively prompt cash to make sure that your requests are token efficient. If you're prototyping, building an agent from scratch, if you use the Claude Code SDK, you can get up and running with something pretty powerful within like 30 minutes or so. We've been seeing people build really cool things with it. We open sourced our Claude Code on GitHub integration, which is completely built on the SDK. And we've seen people build security agents on it, SRE agents, incident response agents. And these are just within the coding domain. Out of the coding, we've seen people prototype legal agents, compliance agents. This is very much intended to be a general SDK for all your agent needs. The SDK is pretty amazing to me. I feel like we've lived in the single request API world for so long. And now we're moving to next level abstraction almost where we're going to handle all the nitty gritty of the things you mentioned. Where is the SDK headed? What's next there? We're really excited about the SDK as the next way to unlock another generation of agents. We're investing very heavily in making sure SDK is best in class or building agents. So all of the nice features that you have in Claude Code will be available out of the box in the SDK. And you can pick and choose which ones you want to keep. So for example, if you want your agent to be able to have a 2D list, great. You have the 2D list tool out of the box. If you don't want that, it's really easy to just delete that tool. If your agent needs to edit files, for example, to update its memory, you get that out of the box. If you decide, OK, mine won't edit files or edit files in a different way, you can just bring your own implementation. OK, so it's extremely customizable. Basically, general purpose in the sense that you could swap out the system problem through the tools for your own implementation. And they just nicely slot in to whatever thing you're building for, whether it's in an entirely different domain than code. Yeah, totally. I'm really excited to see what people hack on top of this. I think especially for people who are just trying to prototype an agent, this is like, I think, by far the fastest way to get started. We really spent almost a year perfecting this harness. And this is the same harness that Claude Code runs on. And so if you want to just jump right into the specific integrations that your agent needs, and you want to jump right into just working on the system prompt to share context about the problem of space with the agent. And you don't want to deal with the agent loop. This is the best way to circumvent all the general purpose harness and just add your special sauce to it. All right. Well, you heard it here. You got to go build on the SDK. Before we wrap up here, I'm really curious to hear your own tips for how you use Claude Code. And what are some best practices we can share with developers? When you work with Claude Code or any agentic tool, I think the most important thing is to clearly communicate what your goals are to the tool. I think a lot of people think that prompting is this magical thing, but it really isn't. It's very much about, OK, did I clearly articulate what my purpose is, like what my purpose with this task is, how I'm evaluating the output of the task, any constraints in the design system. And I think usually, when you can clearly communicate these things, Claude Code will either be able to do them or just tell you that, OK, this thing, I'm not able to do because ABC and you want to try DEF instead. So it's all about the communication, just as if you were working with another engineer. Yeah, totally. And another thing is, if you noticed that Claude Code did something weird, you could actually just ask it why I wanted to do that. And it might tell you something like, OK, there was something in the CLAUDE.md that said this, or I read something in this file that gave me this impression. And then that way, you could actually use talking to Claude as a way to debug. It doesn't always work, but I think it's definitely we're trying, and it's a common technique that we use. Use Claude Code to debug Claude Code. Yeah, yeah. Like the same way that you, when working with a human, if they say something that you didn't expect, you might feel like, oh, interesting. Like, what gave you that impression? Or why did you think this? And I think you can do the same with the agency. Yeah, it's fascinating. Well, Cat, this has been great. We really appreciate the time. Thanks for having me.