Let's get started. Welcome, everyone, to Cloud Code Best Practices. In this talk, I'm going to talk about kind of what Cloud Code is at a high level. Then we'll peer under the hood a little bit to kind of understand how Cloud Code works. And then knowing that, because it's useful to kind of know how your tools work, we're going to talk about good use cases for Cloud Code and also best practices we've figured out, both internally and from our users, for getting the most out of this tool.

But before I get started, I'd like to introduce myself real quick and talk about how I ended up on the stage. So my name's Cal. And I joined Anthropic about a year and a half ago to help start up a team we call Applied AI. And it's the Applied AI's kind of mission-- our team's mission is to help our customers and partners build great products and features on top of Cloud.

So what that really means is I spend a lot of my day prompting Cloud to get the absolute best outputs out of these models. That said, I also love to code, and I'm definitely one of those coders that starts a lot of projects, has some crazy idea, and then just never finishes them.

So I have this graveyard of just like code that I started, never really finished. But I'm always spinning new things up. And then late last year, I was in Slack, and I was hearing about this new tool that a few people are using. They were saying it was really cool.

And so on a Friday night, I downloaded the tool that would become Cloud Code, and I threw it at this kind of new note-taking app that I wanted to build. And that whole weekend just kind of totally changed the way that I code and think about software engineering. I was carrying around my laptop with me all weekend.

I was super addicted to just watching Cloud Code work. And I would press enter, and I'd switch over to my browser and refresh. And I watched this huge, powerful application come together in front of my eyes. And I got way farther into this thing than I ever would have on my own.

And it just blew my mind. And while I was doing this, I was a little worried. I was like, you know, I kind of know how these things work. So I'm like, man, I'm using a lot of tokens. I hope I don't get in trouble or anyone notices. I'm not really contributing to Anthropic Code.

But what I didn't know is that the Cloud Code team had built this internal leaderboard, tracking how much all the Anthropic employees were using this. And over the weekend, I had shot to the top. And so through that, I got to meet Boris and Kat and some of the early Cloud Code team.

And I was able to start talking to them and say, hey, I love this tool. I also know a lot about prompting. Can I help you all out? And so through that, I got involved. And now I'm one of the core contributors on the team. And I do a lot of-- I work a lot on the prompting, the system prompts, how the tools work, the tool descriptions and tool results, as well as I work on how we evaluate this tool.

So when we think about changing the prompts, how do we know we made things better or the same, and we didn't totally ruin Cloud Code? So with that said, let's kind of dive in. So here's my current mental model of Cloud Code and how I describe it to people when people ask me.

Cloud Code is like that coworker that does everything on the terminal. It's the sort of person that just never touches the GUI. They're a whiz. I think of when I was a junior engineer, I had this mentor. And I would walk over his desk and I would say, hey, Tony, can you help me with this bug?

And he would whip it over his terminal. And he'd be doing all these crazy bash commands and changing things around at Vim. And I'd always walk away thinking, wow, that was crazy. I should learn how to do that. I never did. But having Cloud Code on your computer is kind of like having Tony next to you all the time.

So how does Cloud Code kind of work under the hood? At Anthropic, we try to always do what we call the simple thing that works. And what that means for Cloud Code is it's what we would consider a very pure agent. And Anthropic, when we talk about agents, what we really mean is some instructions, some powerful tools, and you let the model just run in a loop until it decides it's done.

And that's really what Cloud Code is. So it's tools, powerful tools, and the tools that someone that was really good at a terminal would be able to use. Tools to create and edit files, to use the terminal, and then you can also do things like pull in other things with MCP.

Now, on top of that, there's how Cloud understands the code base. And if you're going to build a coding agent or a coding tool a year ago, you'd probably have ideas like, well, OK, I'm going to get this user message about something about this code base, and I'll need to figure out which files are relevant.

So maybe I'll index the whole code base and embed it and do this fancy, like, kind of rag retrieval thing. That is not how Cloud Code works. We don't do any sort of indexing. Instead, Cloud kind of explores and understands the code base how you, if you were new to a team and new to a code base, would explore a code base.

And that is through agentic search. It's the same sort of search tools you or I would use, things like glob and grep and find. And it can work its way through a code base and understand what's going on. And when we talk about a genetic search, that really means the model can go do some searches, and then it can look at the results and say, hmm, maybe I need to figure out a few more things.

I'm going to go do some more searching and then come back. And then on top of these primitives, on top of this agent, we have a few things. We have a very nice, light UI layer where you're going to watch Cloud Code work. You see all the text fly by.

And we have this nice permission system that allows the agent to work and allows and kind of forces the human to butt in when the agent is doing something dangerous. And then on top of that, we also care a lot about security in this tool. And so because Cloud Code is just such a lightweight kind of layer on top of the model, and the fact that our model is available not just behind Anthropic APIs, but also with our cloud providers, AWS and GCP, it's very easy and native to point Cloud Code at one of these other services if you feel more comfortable consuming Cloud that way.

Now, a lot of people ask me, hey, Kel, what can I use Cloud Code for? Like, what is it good at? Where is it interesting? And the reality is, it's kind of great at everything. So let's start with discovery. Oftentimes, in your career, you will be dropped into a new code base, whether that means you're switching teams, you're switching companies, I don't know, you're starting to work on some sort of open source project.

And probably when you're first getting started and getting familiar, not very productive, because you're just trying to figure out where things are in the code base, what patterns kind of the team is using, things like that. And Cloud Code can kind of help supercharge that onboarding process. You can ask Cloud, hey, where is this feature implemented?

Or since it's great at the terminal, you can say, hey, look at this file, and look at the Git history, and just kind of tell me a story about how this code has changed over the past couple of weeks. One thing you can use Cloud Code for-- and I think this is underrated-- is instead of just diving in and starting to work, you can use Cloud Code as a thought partner.

So oftentimes, when I'm working with Cloud, and I want to implement a feature, or we're going to change something up, I'll open up Cloud, and it'll say, hey, Cloud, I'm thinking about implementing this feature. Can you just kind of search around and kind of figure out how we would do it, and maybe report back with two or three different options?

Don't start working. Don't start writing any files yet. And Cloud will go off and use those agentic search capabilities and come back with a few ideas. And then I can work with Cloud to kind of validate things, and then we can jump into the project. Of course, Cloud Code is great at building and writing code.

And I would say this on two different fronts. One, it can do the zero to one sort of stuff. You drop it in an empty directory, and you say, hey, build me an app, build me a game. That demos very well. It's very fun to do. It's very gratifying.

Of course, in reality, what really matters is Cloud Code good working in existing code bases. And this is primarily what we focus on. And the Cloud Code team, we have in our code base abnormally high, I would say, unit test coverage. And that's because Cloud Code makes it so easy and just straightforward to add unit tests.

So we have great code coverage. And then the other thing we have in Cloud Code, in our own code base, is we have great commits and PR messages. Because when we finish working, we'll just say, hey, Cloud, write the commit for me. They write the PR message for me.

We also see great opportunities to use Cloud Code in kind of the deployments and in other parts of the lifecycle. And this is-- a few other people have talked about this. But this is using the Cloud Code SDK. So using it headlessly, using it programmatically, being able to sprinkle in a coding agent anywhere.

And so that's things like sprinkling it into CI/CD to use it in GitHub, for instance, to help people programmatically. And then finally, it's great kind of with support and scale. It can help you debug errors faster. One thing that we saw when we started giving Cloud Code to customers and talking to them about it, we didn't totally predict this.

It was a lot of customers or potential customers said, hey, we've been kind of putting off this large code base migration, people that are on old versions of Java trying to get to a new one, or a team that's on PHP and they're trying to get to React or Angular.

We've talked to multiple teams like this, and having a tool like Cloud Code makes projects like that a little more digestible when you go to your team and you say, hey, we're going to spend a month of refactoring or rewriting large parts of the code base. And then on top of that-- and this kind of matters across all these-- is once again, remember, Cloud is great at the terminal.

And that means it's going to be great at all those different CLI tools, things like Git, Docker, BigQuery, things like that. I never have to worry about, oh, I'm going to get myself-- how do I get myself out of this sticky rebase? I'll just fire up Cloud Code and tell it the situation and be like, hey, can you fix this for me?

It's incredible. Now, let's talk about best practices. And the first one is not going to be a surprise, but the first one is use Cloud.MD files. So remember that Cloud Code, like I said, is an agent, and it has some tools. It has some lightweight instructions in the prompt, but it doesn't really have memory.

And so the main way we share state across kind of sessions or across our team when we fire up Cloud Code in the same code base over and over again is this Cloud.MD file. So when we start Cloud, what happens is if there's this Cloud.MD file in the working directory, it's just plopped into context.

It's plopped into the prompt. And basically what it says is, hey, Cloud, by the way, these are important instructions the developer left for you. Be sure to pay close attention to this. And there's various places you can put the Cloud.MD file. You can put it in a project and check it in so all your teammates share it.

You could put one in your home directory if there's things you just want Cloud to always know about, regardless of what you're working on. And the things you put in here are things like, hey, by the way, maybe this is how you run the unit tests. Or just so you know, to make kind of your searching and life easier, here's just like an overview of kind of how this project is laid out, where the tests live, what different modules are, things like that.

Or here's our style guide, all sorts of things like that to just make Cloud's life a bit easier. And you can build these things up over time. The other thing you can do which is important is permission management. When you're running Cloud code, there's all sorts of different kind of permission things flying by.

Kind of out of the box, what happens when you start our tool is for read actions. If Cloud is searching or reading, we just let it go. But once it starts writing or running bash commands or doing things that could change stuff on your machine, potentially, that's when we kick in this UI and it says something like, yes, yes, always allow this, or no, I want to do something else.

And using that permission management and being smart about it can help you work faster. So there's something called auto accept mode, where if you're working with Cloud code and you press shift tab, Cloud will just start working. There's things you can do like you can configure Cloud in the settings where specific commands, like on bash, like if you just are like tired of saying, yes, run NPM run test, you can just always approve that.

So fiddling with your permission management is a great way to kind of speed up your workflow. Integration setup. So one thing that is going to help you get the most out of Cloud code is remember that it's great at the terminal. And if there's applications that you use which have kind of a way to access them through CLI-- and GitHub is a great example of that, they have a powerful tool called GH-- you can basically give more work to Cloud code.

And you can do that either by just installing more CLI tools or you can attach more MCP servers. I would say just through experience that if you're using something like a CLI tool that's well-known and well-documented and you're trying to choose between the CLI tool and just installing it on your machine and grabbing an MCP server, I would recommend using the CLI tool.

And then also if you internally have your own tools at Anthropic-- we have something called Koo that does a whole bunch of stuff for us-- you can also tell Cloud about that and that's the sort of thing you'd put in Cloud.md. And then context management-- so remember that Claude is an agent.

And what it does, it calls these tools and the context builds up and up over time. And at least for Anthropic, our models have a context window of 200,000 tokens and you can max this thing out. So you kind of have two options when you're in a long session with Cloud and you're working and you're going back and forth.

You'll see in the bottom right, you'll start to get this little warning that'll say, hey, you're starting to fill out the context window. And kind of depending on what's going on, you have two options. You can run /clear and just start over and that clears everything out except for, for instance, Claude.md.

Or you can run /compact and what'll happen is basically it's like a user message is inserted and it just says something like, hey, I need to go summarize everything we've been up to. I'm going to give this to another developer and they're going to pick up where I left off.

And then that summary is what kind of seeds the next session and you can go from there. We spend a lot of time tuning this kind of compact functionality so that as you max out the context window and then run compact, you can start back over and keep going.

Efficient workflows, what can you do with Cloud Code and how do you get the most out of it? So using planning and to-dos, I talked a little bit about this before, but one of the best things you can do is when you open up Cloud Code, instead of saying, hey, I need you to fix this bug, you can say, hey, I have this bug.

Can you search around, figure out what's causing it and just like tell me a plan how we're going to fix it? And this can save you a lot of time because you can verify, you can read Cloud's plan and you can verify what it's going to do. And then the other thing that we have is we have this to-do list feature.

So often when Cloud's working on a big task, it will create a to-do list. And if you're kind of paying attention, you can kind of watch this to-do list. And if you see anything kind of weirder in there or something that doesn't make sense, that's when you can press escape and say, hey, Cloud, let's change the to-do list.

I think you're on the wrong path. Smart vibe coding. So it's very tempting and it's very powerful to just let Cloud work and press Enter and see what happens at the end. I think there's a few things that can help make this better. And there's, I think, a talk later today about just this for 30 minutes.

But doing things like having test-driven development, having Cloud make small changes, run the tests, make sure they pass, always having Cloud do things like check the TypeScript and the linting, and then commit regularly. So that if it's kind of going off the rails, you can always fall back and try again.

You can use screenshots to guide and debug. So Cloud is built on top of our models, which are multimodal. You can always just grab a screenshot, paste it in. Or if you have a file somewhere that's an image, you can just say, hey, Cloud, look at this mock.png, and then build the website for me or whatever.

And then advanced techniques. OK, so as you're getting used to using Cloud, what are some things you can think about to kind of push things to the next level? And one of the things we see both internally and with customers is when you've started to use this tool for a while, it's going to be very tempting to use multiple Clouds at once.

And so I know people at Anthropic and a few customers that run four Clouds at the same time. There's various ways to do this. You can have it in Tmocs or just different tabs, all sorts of crazy things. So I would challenge you to try getting multiple Clouds running at once and kind of be orchestrating all these things.

It's quite fun. I can only do two, but I know people that do four. Use escape. So escape is your best friend. While Cloud is working, you can kind of keep an eye on what it's up to, and you can press escape to stop it and interject and say, hey, I think you're going on the wrong path or I want you to do something else.

Knowing when the right time to press escape is versus just letting Cloud figure it out is key to getting the most out of the tool. And there's a hidden feature. Not too many people know about it, but if you press escape twice, you can actually jump back in your conversation.

You can go back and you can kind of reset. Tool expansion and MCP. So this is taking it to the next level. If you feel like with Bash and with the tools that Cloud has that it still can't do something, this is when you should start looking at MCP servers.

And then headless automation. I think this is the thing we're most excited about, but also we are still trying to wrap our heads around internally, which is how can we use Cloud programmatically? We have that in GitHub Actions. We want to figure out other creative places we can start using it.

I would challenge you all to do the same. So with that said, I'm going to jump over to my computer because there's one other best practice, which is it's always good to stay on top of everything that's new. So we're shipping super fast. I'm just going to go over a few things that are new as of today.

One thing is when you're in Cloud now and you fire it up, you can do /model. You can see what model you're running on. I'm on default, which happens to be Sonnet. We can jump over to Opus. You can do the same thing in /config, switch it here. So that's new.

Make sure you're running the model that works for you. There's another thing that's new about these models, which is you can say something like, "Can you figure out what's in this project?" And for a long time, for a while, we've had this like think hard or extended thinking. Now, this is great, but with our past models, we wouldn't let our model think between tool calls.

And that's probably when the thinking matters most. So starting with Cloud 4, our models now think between tool calls. And we can watch this happen. So we have Cloud in this project. There's a few different files in here. And I'm just going to tell it to think hard and figure out what's in this project.

And we can watch Cloud start to work. And so the way you know you triggered thinking is you'll see kind of this lighter gray text. And then it'll call some file. It'll call some tools. It'll read some stuff. And then we see some more thinking. And this is awesome.

So I encourage you, when you're working on tasks and solving bugs, throw a think hard in there. And then the other thing, and you know what? We'll just throw it up real quick, is I have this in VS Code. But of course, this is in JetBrains as well. But we have these new great integrations with VS Code and JetBrains.

We can do things like, Claude's going to know what file I'm in. What file am I in? That is not what I meant to say, but Claude's going to figure it out. And you can do things like this. So these are the sort of things I would encourage you to stay on top of.

We have a public kind of GitHub project called Claude Code under Anthropic. You can post issues there, but we also post our changelog there. And so I check this once a week and make sure that I'm on top of all the new stuff we're shipping, because even I can't keep up with it.

So with that said, we have like four minutes left. I'm happy to answer questions about anything Claude Code related. We have it here. I can live demo some stuff if you're interested. Let's do a few. Thanks real quick. This might be obvious, but multiple Claude.md files in a project, I presume that's possible and it just figures it out or no?

So there's a few options. Of course, like in the same directory, you couldn't. But you could have one here and one in a subdirectory. And I think we changed this so that all the subdirectory ones aren't read in, because like Anthropic, we have a monorepo. And people would open it at the top and blow up their context with all the Claude MDs.

So we encourage Claude when it's searching around and it discovers Claude.md files in child directories that are relevant to be sure to read them. But by default, it just reads the Claude.md file in the current working directory when you fire it up. And then also you can set one in like your home directory.

There are things you can do, though. We have this new thing. Like in your Claude.md, you can start referencing other files. So you could, for instance, do something like this with an @ sign. If you have other Claude.md files that you just kind of know you always want to read in, to do something like that.

Hi, okay. I have not had luck getting Claude to respect my Claude.md. Like there's one thing particular where I'll ask it to refactor something, and then it will leave inline comments explaining the what of it is. And it's like something that's extremely obvious. Yes. And so I'll tell it like, go and remove any inline comments that describe the what of what's happening.

And then it will remove it and then immediately do it again in like the same path. So do you have any strategies for dealing with that? So there's kind of two things that fix that. So that was actually kind of a model problem. There's nothing in the prompt. We have actually a lot in the prompts for 3.7 that said, whoa, do not leave comments.

And despite that, the model just loves to leave comments. So it doesn't surprise me that your Claude.md didn't help much either. We already did a lot. I did a lot of work to try to tamp it down from what happens out of the box. So we mostly fixed that in Claude 4.

Now, there might be some new weird behavior quirks. But the other thing we made better in Claude 4 is it's just better at following instructions. And we've gotten a lot of feedback from early testers that all of a sudden, whoa, my Claude.md is being followed way more closely. And it might be a good chance to go look in your Claude.md and decide, do I still need this stuff?

Maybe I can take some of it out. Maybe I need to add a few new things. So moving over to the new models might be a good time to take another look at what's in there and see what you need and what maybe can go. For the record, I'm trying to think of something that you might not have thought of.

Yes. We're doing multi-agent execution and parallelization. Can you make it so that for four agents, say, agents two and three use the context from agent one? Maybe agent four uses the context from agent two at a certain point? Yeah. Yeah, et cetera. That's interesting. We're trying to-- so kind of like I said at the beginning, we're trying to do the simple thing that works, which is just one agent that's great at coding and does everything.

I think we want to figure that out. Probably what's going to happen is if you wanted to do that, you would ask all your agents to probably write to a shared markdown file or something like that so they can all kind of check in and communicate. Sometimes I'll be working with Claude and I'll just say, "Hey, I need you to write some stuff in Ticket.md for another developer." And then I'll fire up another Claude code and I'll be like, "Hey, read Ticket.md.

Another developer left this note for you. This is what you're going to work on." So I would think about trying to write that state to a file and then just kind of like count on the model's ability to just like read files and make sense to them. It's probably the best you can do today and maybe we'll figure out clever ways to expose that in the product as something more native.

Cool. All right. And with that said, I have some rare Claude code stickers that I found in my backpack. So come find me. I'll be hanging out over there or something. Happy to share them. Happy to share them.