The Exchanges

Q Yeah. How did that start? Did you have a master plan to build cloud code or?

A There's no master plan. Uh, when I joined Anthropic, I was experimenting with different ways to use the model kind of in different places. And the way I was doing that was through the public API, the same API that everyone else has access to. And one of the really weird experiments was this cloud that runs in a terminal. And I was using it for kind of weird stuff. I was using it to like, look at what music I was listening to and React to that and then, you know, like screenshot my, you know, video player and explain what's happening there and things like this. And this was like kind of a pretty quick thing to build and it was pretty fun to play around with. And then at some point I gave it access to the terminal and the ability to code. And suddenly it just felt very useful. Like I was using this thing every day. It kind of expanded from there. We gave the core team access and they all started using it every day, which was pretty surprising. Uh, and then we gave all the engineers and researchers at Anthropic access and pretty soon everyone was using it every day. And I remember we had this DAU chart for internal users and I was just watching it and it was, it was vertical like for days and we're like, all right, there's something here. We got to give this to external people so everyone else can try this too. Yeah. Yeah. That's where it came from.

AI assessment note: “There's no master plan. Uh, when I joined Anthropic, I was experimenting”

Q and whatnot. But I know you recently released like, you know, compacting context features and all that. How do you decide how thick it needs to be on top of the CLI? So that's kind of the share interface. And at what point Are you deciding between, okay, this should be a part of clock code versus this is just something for the IDE people to figure out, for example?

A Yeah, there's kind of three layers at which we can build something. So the, you know, being an AI company, the most natural way to build anything is to just build it into the model and have the model do the behavior. The next layer is probably scaffolding on top, so it's like cloud code itself, and then the layer after that is using cloud code as a tool in a broader workflow, so to compose defend. You know, so for example, a lot of people use code with, you know, tmux, for example, to manage a bunch of windows and a bunch of sessions happening in parallel. We don't need to build all of that in. Um, compact, it's sort of this thing that kind of has to live in the middle because it's something that we want to work when you use code. You shouldn't have to pull in extra tools on top of it. And rewriting memory in this way isn't something the model can do today. So you have to use a tool for it. And so it, it kind of has to live in that, that middle area. We tried a bunch of different options for compacting, you know, like rewriting, uh, old tool calls and, uh, truncating old messages and not new messages. And then the end, we actually just did the simplest thing, which is ask Claude to summarize the, you know, the previous messages and just return that and that's it. And it's funny with, when the model is so good, the simple thing usually works. You don't have to over-engineer it.

AI assessment note: “there's kind of three layers at which we can build something.”

Q How can writing a file ever be unsafe if you have version control? I think that's

A Yeah, I think it's, I think there's, like, a few different probably, like, aspects of safety to think about, so it could be useful just to break that out a little bit. So for file editing, it's actually less, I think, about safety, although there, there is still a safety risk, because what might happen is, let's say the model fetches a URL, and then there's a prompt injection attack in the URL, and then the model writes malicious code to disk, and you don't realize it. Although, you know, there is code review as, like, a separate Kind of wear there as, as protection. But I think generally for file rights, the model might just do the wrong thing. That's the biggest thing. And what we find is that if the model is doing something wrong, it's better to identify that earlier and correct it earlier, and then you're gonna have a better time. If you wait for the model to just go down this like totally wrong path and then correct it 10 minutes later, you're gonna have a bad time. So it's better to usually identify failures early. But at the same time, there's some cases where you just want to let the model go. So for example, if cloud code is, uh, you know, it's writing tests for me, I'll just hit shift tab, enter auto accept mode, and just let it run the tests and iterate on the tests until they pass. Um, cause I know that's a pretty safe, safe thing to do. And then for some other tool…

AI assessment note: “prompt injection attack in the URL, and then the model writes malicious code to disk”

Q What are the best practices here? Because when it's non-interactive, it could run forever, and you're, you're not, you're not necessarily reviewing the output of everything, right? So I'm just kind of curious, how does, how is it different in non-interactive mode? What are the most important hyperparameters or arguments to set?

A Yeah, and for folks that haven't used this, so non-interactive mode is just cloud dash p, and then you pass in the prompt in quotes, and that's all it is. It's just the dash p flag. Generally, it's best for tasks that are read-only. That's the place where it works really well and you don't, you know, super have to think about permissions and running forever and things like that. Um, so for example, a linter that runs and doesn't fix any issues, or for example, we're working on a thing where we use quad in with dash P to generate the change log for quad. So every PR is just looking over the commit history and being like, okay, this makes it into the change log. This doesn't, um, because we know people have been requesting, uh, change logs, so we're just getting quad to build it. So generally, non-interactive mode, really good for read-only tasks. For tasks where you want to write, the thing we usually recommend is pass in a very specific set of permissions on the command line. So what you can do is pass in, ah, dash, dash, allowed tools, and then you can allow a specific tool. So for example, not just bash, but for example, git status, um, or git diff. So you just give it a, a set of tools that it can use or, you know, edit tool.

AI assessment note: “pass in a very specific set of permissions on the command line”