StreamSparkAI

speaker 1: Hello everyone, I'm Boris. I'm a member of technical staff here at anthropic and I created quad good and here to talk to you a little bit about some practical tips and tricks for using quad code. It's gonna to be very practical. I'm not gonna to go too much into the history or the theory or anything like this. And Yeah before we start, actually can we get a quick show fans who has used quad code before? Yeah, all right. That's what we like to see for everyone that didn't raise your hands. I know you're not supposed to do this while people are talking, but if you can open your laptop and type this. And this will help you install quad code just so you can follow along for the rest of the talk. All you need is no js. If you have a, this should work. Yeah if have you don't have to follow along, but if you don't have it yet, Yeah this is your chance to install it so you can follow along. So what is quad code? Cloud code is a new kind of AI assistant. And there's been different generations of AI assifor coding. Most of them have been about completing like a line at a time, completing a few lines of code at a time. Qud code is not for that. It's fully agengentic. So it's meant for building features, for writing entire functions, entire files, fixing entire bugs at the same time. And what's kind of cool about quad code is it works with all of your tools and you don't have to change out your workflow. You don't have to swap everything to start using it. So whatever ide use, if you use vs code, or if you use Xcode, or if you use jet brains ids, there are some people had anthropic that you can't prive them from their cold, dead hands, but they use quad code because quad code works with every single ID, every terminal out there, itwork locally over remote ssh, over tmuwhatever environment you're in, you can run it. It's general purpose. And this is something where if you haven't used these kind of free form coding assistance in the past, it can be kind of hard to figure out how to get started because you open it up and you just see a prompt R and you might wonder like, what do I do this? What do I type in? It's a power tool, so you can use it for a lot of things, but also because it can do so much, we don't try to guide you towards a particular workflow because really you should be able to use it however you want as an engineer. As you open up quad code for the first time, there's a few things that we recommend doing to get your environment set up. And these are pretty straightforward. So run terminal seup. This will give you shift enter for new lines so you don't have to do like backsplashes enter new lines. This is, you know, it makes it a little bit nicer to use do slash theme to set light mode or dark mode or deltonzed themes. You can do slash install GitHub app. So today, once we announced a GitHub app where you can mention Claude on any GitHub issue or pull request. So to install, we'll just run this command in your terminal. You can customize the set of allowed tools that you can use so you're not prompted for it every time. This is pretty convenient for stuff that I'm prompted about a bunch. I'll definitely customize it in this way so I don't have to accept it every time. And something that I actually do is for a lot of my prompts, I won't hand type them into a cloud code. If you're on mac os, you can go into your system settings under accessibility as dictation, and you can enable it. And so something I do is you just hit like the dictation key twice, and you can just speak your prompt. And it helps a lot to have specific prompts. So this is actually pretty awesome. You can just talk to quad code and like you would another engineer, and you don't have to type a lot of code. So when you're starting out with cloud code, it's so freeform and it can do everything. What do you start with? The thing I recommend above everything else. So starting with code base Q&A. So just your asking questions to your code base. This is something that we teach new hires at anthropic. So on the first day in technical onboarding, you wern about quad code. You download it, you get it set up, and then you immediately start asking questions about the code base. And in the past, when you're doing technical onboarding, it's something that taxes the team a lot. You have to ask other engineers on the team questions. You have to look around the code, and this takes a while. You have to figure out how to use the tools. This takes a long time. With quad code, you can just ask quad code and itexplore the code base, itanswer these kind of questions. And so ananthropic onboarding use to take about two or three weeks. For technical hires, it's now about two or three days. What's also kind of cool about Q&A is we don't do any sort of indexing. So there's no remote database with your code. We don't upload it anywhere. Your code stays vocal. We do not train generative models on the code. So it's there. You control it. There's no indices or anything like this. And what that means is also, there's no setup. So you start clad, you download it, you start it, there's no indexing. You don't have to wait. You can just use it right away. This is a technical talk. So I'm going to show some very specific prompts and very specific code samples that you can use and hopefully improve and uplevel your quad code experience. So some kind of questions that you can ask is, you know how is this particular piece of code used or how do I instantiate this thing? And qud code, it won't just do like a text search and try to answer this itoften go a level deeper and ittry to find examples of how is this class instantiated, how is it used, and itgive you a much deeper answer. So something that you would get out of a wikier documentation instead of just like command f, something that I do a lot also is ask it about git history. So for example, why does this function have 15 arguments? And why are the arguments named this weird way? And this is something I've bet in all of our code bases, you have some function like this or some class like this, and cloud code can look through git history and itlook to figure out how did these arguments get introduced and who introduced them and what was the situation. What are the issues that those commits linked to and itlook through all this and summarize it. And you don't have to tell with that in all this detail. You just ask it. So just say, look through git history. And I don't know to do this. The reason it knows it, by the way, is not because we prompted it to, there's nothing in the system prompt about looking through git history. It knows it because the motto is awesome. And if you tell it to use git, don't know how to use git. So we're lucky to be building on such a good model. I often ask about GitHub issues so it can use webfetch, and they can fetch issues and woup context on issues too. And this is pretty awesome. And this is something that I do every single Monday in our weekly stand up, is I ask, what did I ship pped this week? And quad code books for the log knows my username. And itjust give me a nice readout of everything I shipped. And I'll just copy and paste that into a doswimer. So Yeah, that's tip number one for people that have not used cloud code before. If you're just showing it to someone for the first time, onboarding your team, the thing we definitely recommend is start with code debased Q&A. Don't start by using fancy tools. Don't start by editing code. Just start by asking questions about the code base and thatteach people how to prompt and itstart, teaching them this boundary of like, what can clad code do? What is it capable of versus what do need to hold this hand with dth little bit more? What can be one shoted? What can be two shotted three shoted? What do you need to use interactive mode for in a reppple? Once you're pretty comfortable with Q&A, you can dive into editing code. This is the next thing. And the cool thing about any sort of agengentic, you know, like using lm in an agenent tic way, is you give it tools and it's just like magical. It figures out how to use the tools. And with quad code, we give it a pretty small set of tools. It's not a lot. And so it has a tool to edit files. It has a tool to run dash commands. It has a tool to search files and itstring these together to explore the code, brainstorm, and then finally make edits. And you don't have to prompt it specifically to use this tool in this tool. And this tool, you just say, you know, do this thing and itfigure out how to do it, itstring it together in the right way. That makes sense for quad code. There's a lot of ways to use this. Something I like to do sometimes is before having Claude jump in to write code, I'll ask it to brainstorm a little bit or make a plan. This is something we highly recommend. And something I see sometimes is people, you know, they take quad code and they ask it, Hey, implement this enormous, like 3000 wine feature. And sometimes it gets this right on the first shot, but sometimes what happens is the thing that a build is not at all the thing that you want. And the easiest way to get the result you want is ask it to think first. So brainstorm ideas, make a plan, run it by me, ask for approval before you write code. And you don't have to use plan mode. You don't have to use any special tools to do this. All you have to do is ask clag and itknow to do this. So just say, before you write code, make a plan. That's it. This is also, I want to think with this one, this commit postsphere, this is a really common incantation that I use. There's nothing special about it, but quad is kind of smart enough to interpret this. So itmake a commit, itpush it to the branch, make a branch, and then make a pull request from your on GitHub. You don't have to explain anything itlook through the code, itlook through the history, itlook through the git log by itself to figure out the commit format and all the stuff, and itmake the commit and push it the right way. Again, we're not system prompting to do this. It just knows how to do this. The model was good. As you get a little bit more advanced, you're going to want to start to plug in your teams tools. And this is where quad code starts to really shine. And there's generally two kinds of tools. So one is bash tools. And an example of this, I just made up this like barley cli. This isn't a real thing, but you can say use the cli to do something, and you can tell quad code about this, and you can tell it to use, for example, like dash dash help to figure out how to use it. And this is efficient if you find yourself using it a lot. You can also dump this into your quad md, which we'll talk about in a bit. So quad can remember this across sessions. But this is a common pattern we follow at anthropic, and we see external customers used too. And same thing with mcp. Quad code can use bash tools. You can use mcp tools. So you just tell it about the tools, and you can add mcp tool, and you can tell it how to use it, and itjust start using it. And this is extremely powerful, because when you start to use code on a new code base, you can just give it all of your tools, all the tools your team already uses for this code base. And cocode can use it on your. There's a few common workflows, and this is the one that I talked about already. So kind of do a little bit of expiration, do a little bit of planning and ask me for confirmation before you start to write code. These other two on the right are extremely powerful when Clauda has some way to check its work. So for example, by writing untests or screenshotting and puppeteer or screenshotting, the iOS simulator, then it can iterate. And this is incredible because if you give it, for example, a mock and you say, build this web ui itget it pretty good. But if you had to iterate two or three times, often, it gets it almost perfect. So the trick is give it some sort of tool that it can use for feedback to check its work, and then based on that, it will iterate by itself and you're going to get a much better result. So whatever your domain is, if it's unit test or integration test or screenshots for apps or web or anything, just give it a way to see its result and ititerate and get better. So these are the next tips, teach quad how to use your tools and figure out the right workflow. If you want quad to jump in a code, if you want it to brainstorm a little bit, make a plan, if you want to iterate, kind of have some sense of that. So you know how to prompt quad to do what you want. As you go deeper beyond tools, you want to start to give Claude more context. And the more context, the smarter the decisions will be. Because as an engineer working in a good ways, you have a ton of context in your head about your systems and all the history and everything else. There's different ways to give this to Claude. And as you give clad more context, itdo better. There's different ways to do this. The simplest one is what we call quad md. And quad md is the special file name. The simplest place to put it is in the project route. So the same director, you start quad in, put a qumd in there, and thatget automatically read into context at the start of every session. And essentially, the first user turn will include the quad md. You can also have a local qulot md. And this one, you don't usually check into source control. So qumd, you should check into source control share with your team so that you can write it once and share it with your team. This one, you don't check in. It's just for you the kinds of things you put in quatmd. It's like common bash commands, common mcp tools, architectural decisions, important files, anything that you would kind of typically need to know in order to work in the school base. Try to keep it pretty short because if it gets too long, it's just going to use up a bunch of context and it's usually not that useful. So just try to keep it as short as you can. And for example, in arco base, we have common on bash commands. We have a style guide. We have a few core files, kind of things like that. Although other quad mds, you can put them in other nested child directories and Claude will pull them in on demand. So these are the qumds that will get pulled in automatically. But then also you can put quadmds in nested directories and those will get automatically pulled when quad works in those directories. And of course, if you're a company, maybe you want a qumd that's shared across all the different code bases and you want to manage it on behalf of your users and you can put it in your enterprise route and thatget pulled in automatically. There's a ton of ways to pull in context. I actually had a lot of trouble putting this fight together just to communicate the breadth of ways you can do this. But quatum d is pulled in automatically. You can also use flash commands. So this is dark quad slash commands. And this can be in your home directory, or it can be checked into your project. And this is for sh commands. And over here, we have a few examples of the slash commands that we have in cloud code itself. And so for example, if you're in the cloud code repo and you see issues getting labeled, that's actually this workflow running here. It's labeled GitHub issues. And we have a GitHub action running the same one we talked about this morning, where crod code will run this command. And it's just a splash command, itrun and itwaive, all the issues. So humans don't have to. It just saves us a bunch of time. And of course, you can add mention files to pull them into context. And like I said before, quad md's in an nested directory get pulled in when quad works in that directory. So give quad more context, and it's definitely worth taking the time to tune context. If you can run it through a prompt improver, consider who the context is for. If you want to put it in every time, if you want na put it in on demand, if you want to share it with a team, if it's a personal preference, definitely take the time to tune it. This will improve performance dramatically if you do it right. As you get more advanced, you're going to want to think about this a little bit more, this kind of hierarchy of different ways to pull in everything. So like not just quatum d, but also config and kind of everything about quad, you can pull in in this hierarchical way. So projects are specific to your git repo. And this you can check in or you can make it just for you. You can also have global configs that are across all your projects, or you can have enterprise policies. And this is essentially a global config that you row up for all of your employees, everyone on your team automatically. And the slide is like pretty information dense. But the point is this applies to a lot of stuff. So you can do this for ssh commands. You can do it for permissions. So for example, if you have a bash command that you would run for all your employees, like all your employees use this like test command, for example, you can actually just check it into this enterprise policies file. And then any employee, when they run this command, it will be auto approved, which is pretty convenient. And you can also use this to block commands. So for example, let's say there's a euro that should never be fetched. Just add it to this config and thatmake it so an employee cannot override it, and that that euro can never be fetched. So pretty convenient both to unblock people and also just to keep your code base safe. And then same thing for mcp servers. Have a mcp json file, check it into the code base. That way, anytime someone runs quad code in your code base, theybe prompted to install the mcp servers and share it with the team. If you're not sure which of these to use, this is like a kind of an insane matrix because we support a lot of stuff and engineer workflows are very flexible and every company is different. So we kind of want to support everything. So if you're not sure how to get started, I would recommend start with shared project. You write this once and then you share it with everyone on the team, and you get this kind of network effect where someone does a little bit of work and everyone on the team benefits. There's a lot of tools built into qud to manage this. So as an example, if you run slash memory, you can see all the different memory files that are getting pulled in. So maybe I have an enterprise policy, I have my user memory, I have project quadmd, and then maybe there's a nested quad md that's only pulled in for certain directories. And then similarly, when you do slamemory, you can edit particular memory files. When you type pound sign to remember something, you can pick which memory you want it to go to. So Yeah, that's the next step. Take the time to configure qumd, mcp servers, all the stuff that your team uses so that you can use it once, configure it once, and then share it with everyone. An example of this is in our apps repo for anthropic. This is like the repo that we have all of our web and apps coden. This is a puppeteer mcp server, and we share this with the team and there's a mcp jsonchecktin. So any engineer working that repo can use puppeteer in order to pilot end to end test and to screenshot automatically and iterate so that every engineer doesn't have to install it themselves. This is a talk about pro tips. So I just want to take a quick interruto talk about some common key bindings that people may not know. It's very hard to build for terminal. It's also very fun. It feels like rediscovering this new design language. But something about terminals, it's extremely minimal. And so sometimes it's hard to discover these key bindings. And here's just a quick reference sheet. So anytime you can hit shift tab to accept edits, and this switches you into auto accept edits mode. So bash commands still need approval, but edits are auto accepted and you can always ask quad to undo them later. For example, I'll do this if I know quads on the ray track, or if it's writing unit tests and iterating on tests. I'll usually just switch into auto accept mode so I don't have to ok every single item anytime you want cloud to remember something. So for example, if it's not using a tool correctly and you wanted to use it correctly from then on, just type the pound sign and then tell it what to remember and ititincorporate it into quamd automatically. If you ever want to drop down to bash mode, so just run a bash command. You can hit the exclamation mark and type in your command that run locally, but that also goes into the context window. So Claude will see it on the next turn. And this is pretty good for long running command, if you know exactly what you want to do or any command that you want to get into context and quad will see the command and the output. You can add mention thousand folders anytime you can hit escape to stop what quad is doing. No matter what quad is doing, you can always safely hit escape. It's not going to corrupt the session and it's not going to mess anything up. So maybe quad is doing a File Edit. I'll hit escape. I'll tell you what to do differently. Or maybe it suggested a 20 wedit. And I'm like, actually 19 of these lines were perfect, but one line you should change. I'll hit escape. I'll tell what that, and then I'll tell it to redo that. You can hit escape twice, to jump back in history. And then after you're done with the session, you can start quad with a resume to resume that session if you want or asdash continue. And then anytime, if you want to see more output, hit controller and thatshow you the entire output, the same thing that Claude sees in its context window. The next thing I want to talk about is the cloud code sdk. So we talked about this at the top right after this. It is doing a session, I think, just across the hallway. And he's gonna to go super deep on the sdk. If you hahim played around with us, if you use the dash p flag and claug, this is what the sdk is. And we've been wina bunch of features over the last few weeks to make it even even better. So Yeah, you can build on top of this. You can do cool stuff. This is exactly the thing that quad code uses. It's exactly the same sdk. And so for example, something you can do is claw dash p. So this is the cli sdk. You can PaaS a prompt. You can PaaS some allowed tools, which could include specific bath commands, and you can tell it which format you want. So you might want json or you might want streaming json if you want na process this somehow. So this is awesome for building on. We use this in ci all the time. We use this for incident response. We use this in all sorts of pipelines. So really convenient. Just think of it as like a unix utility. You give it a prompt, it gives you json. You can use this in any way. You can pipe into it. You can pipe out of it. The piping is also pretty cool. So you can use, like, for example, git status and pipe this in and use jq to select the result. The combinations are n of us. And it's sort of this new idea. It's like a super intelligent unix utility. And I think we barely scratch the surface of how to use this. We're just figuring this out. You can read from like a gcp bucket, read like a giant log, and pipe it in and tell quad to figure out what's interesting about this log. You can fetch data from like the sentry cli. You can also pipe it in and have quad do something about. The final thing, and this is probably like the most advanced use case as we see, I'm sort of a quad normy. So I'll have usually like one quad running at a time, and maybe I'll have like a few terminal tabs for a few different reppos running at a time. When I look at power users in and out of anthropic, almost always they're gonna to have like sa sessions, theyhave like tmux tunnels into their quad sessions. They're going to have a bunch of checkouts of the same repo so that they can run a bunch of quads in parallel in that repo, or they're using git work trees to have some kind of isolation as they do this. And we're actively working on making this easier to use. But for now, these are some ideas for how to do more work in parallel with quad. You can run as many sessions as you want and there's a lot that you can get done in parwell. So Yeah, that's it. I wanted to also leave some time for Q&A. So I think this is the last slide that I have. And Yeah if folks have questions, there's mics on both sides and Yeah welove to answer any questions. I did. Hey, worries. Thanks for building a cloud code. And I was wondering what was the hardest implementation, like part of the implementation for you of building it? I think there's a lot of tricky parts. I think one part that is especially tricky is the things that we do to make bash command safe. Bash is inherently pretty dangerous, and it can change system state in unexpected ways. But at the same time, if you have to manually approve every single bash command, it's super annoying as an engineer and you can't really be productive because you're just constantly approving every command and just kind of navigating how to do this safely in a way that scales across the different kinds of code baspeople have because not everyone runs their code in a docker container was pretty tricky. And essentially, the thing we've landed on is there's some commands that are read only. There's some static analysis that we do in order to figure out which commands can be combined in safe ways. And then we have this pretty complex tiered permission system so that you can allow list and blolist commands at different levels. Hi, Boris. You mentioned giving an image to cloud code, which made me wonder if there's some sort of multimodal functionality that I'm not aware of. Is that are you just pointing it at an image on the file system or something? Yes. So cloud code is fully multimodal. It has been from the start. It's in a terminal, so it's a little hard to discover. But Yeah, you can take an image and just drag and drop it in thatwork. You can give it a file path thatwork, you can copy and paste imain, and that works too. So I'll use this pretty often for if I have like a mock of something, I'll just drag and drop in the mock, I'll tell it to implement it, I'll give it up up a tier server so we can iterate against it. And Yeah, it's just fully automated. Okay, why did you build a cli tool instead of an ide? Yeah, it's a good question. I think there's probably two reasons. One is we started this ad anthropic. And ad anthropic people use a broad range of iand. Some people use vcode, other people use said or x code, or vim, or emacs. And it was just hard to build something that works for everyone. And so terminal is just the common denominator. The second thing is at anthropic, where we see up close how fast the model is getting better. And so I think there's a good chance that by the end of the year, people aren't using ids anymore. And so we want to get ready for this future and we want to avoid overinvesting in ui and other layers on top given that the way the models are progressing just it may not be useful work pretty soon. Yeah how much of you I don't know if is this on how much have you used pcode for machine learning modeling and almost that auto ml experience. I was curious what the experience has been so far with that. Yeah, I think I think the question was how much are we using cloud code for machine learning and modeling? We actually use it for this a bunch. So both engineers and researchers at anthropic use qud code every day. I think about 80% of people at anthropic that are technical use cloud code every day. And hopefully you can see that in the product and kind of the amount of love and dog footing we've put into it. But this includes researchers who use tools like the notebook notebook tool to edit and run notebooks. Okay, very cool. Thank you. All right. I think that's it. Thanks.