I hope Anthropic doesn't see this. #ai #artificialintelligence #claud...

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, 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 like 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 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 Coo 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 Cloud 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 slash clear and just start over and that clears everything out except for, for instance, cloud.md. Or you can run slash 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. 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, and 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 slash 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 slash 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 while, we've had this 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. We can watch 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 Cloud's going to know what file I'm in, what file am I in. That is not what I meant to say, but Cloud'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 Cloud 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 Cloud Code related. We have it here. I can live demo some stuff if you're interested. Let's do a few. Let's do him first, and then you. Thanks real quick. This might be obvious, but multiple Cloud.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, in the same directory, you couldn't. But you could have one here, and one in a sub-directory, and I think we changed this so that all the sub-directory ones aren't read in, because Anthropic, we have a monorepo, and people would open it at the top and blow up their context with all the Cloud.mds. So we encourage Cloud when it's searching around and it discovers Cloud.md files in child directories that are relevant to be sure to read them. But by default, it just reads the Cloud.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 Cloud.md, you can start referencing other files. So you could, for instance, do something like this with an at sign, if you have other Cloud.md files that you just kind of know you always want to read in, to do something like that. Hi. OK. I have not had luck getting Cloud to respect my Cloud.md. There's one thing in 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 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 pass. 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 prompt 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 Cloud.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 Cloud 4. Now there might be some new weird behavior quirks. But the other thing we made better in Cloud 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 Cloud.md is being followed way more closely. And it might be a good chance to go look in your Cloud.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. 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'd think about trying to write that state to a file and then just kind of count on the model's ability to just read files and make sense of 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 chat.