Claude Code began as a lightweight terminal prototype

Transcript

From the transcript AI & I publishes with the episode.

1. 2:25

   So take me through like that decision process, that process of architecting this new paradigm. How do you think about that? Yeah, I think the most important thing is it was not intentional at all. Okay. We sort of ended up with it. So at the time when I joined Anthropic, we were still on different teams at the time. There was this previous predecessor to QuadCode. It was called Clyde, like C-L-I-D-E. And it was this like research project.

2. 2:54

   You know, it took like a minute to start up. It was this kind of like really heavy Python thing. It had to like run a bunch of indexing and stuff. And when I joined, I wanted to ship my first PR. And I hand wrote it like a noob in the time. I didn't know about any of these tools. Thank you for admitting that on the podcast. I didn't know any better. And then I put up this PR. And Adam Wolf, who was the engine manager for our team for a while, he was my ramp up buddy.

3. 3:22

   And he just rejected the PR. And he was like, you wrote this by hand? What are you doing? He was Clyde. Because he was also hacking a lot on Clyde at the time. and so I tried Clyde I gave it the description of the task and it just like one shot at this thing and this was like you know sonnet 3.5 so I still had to fix the thing even for this kind of basic task and the harness was super old so it took like five minutes to turn this thing out and just took forever and um but it but it worked and I was just mind blown that this this was even possible and they just kind of got the gears turning maybe you don't actually need an IDE and And then later on, I was prototyping using the Anthropic API.

4. 4:03

   And the easiest way to do that was just building a little app in the terminal because that way I didn't have to build a UI or anything. And I started just making a little chat up. And then I just started thinking, maybe we could do something a little bit like Clyde. So let me build like a little Clyde. And it actually ended up being a lot more useful than that without a lot of work. And I think the biggest revelation for me was when we started to give the model tools, they just started using tools.

5. 4:31

   And it was just, it was this insane moment. Like the model just wants to use tools. Like we gave it bash and it just started using bash, writing Apple script to like automate stuff. in response to questions. And I was like, this is just the craziest thing. I've never seen anything like this. Because at the time I had only used IDEs with like text editing, a little like one line autocomplete, multi-line autocomplete, whatever.

6. 4:54

   So that's where this came from. It was this kind of convergence of like prototyping, but also kind of seeing what's possible in kind of like a very rough way. And this thing ended up being surprisingly useful. And I think it was the same for us. I think for me, it was like kind of Sonnet 4, Opus 4, that's where that magic moment was. Where it's like, oh my God, this thing works. That's interesting.

7. 5:16

   So tell me about the tool moment, because I think that is one of the special things about Cloud Code, is it just writes Bash and is really good at it. And I think a lot of previous agent architectures, or even anyone building an agent today, your first instinct might be... Okay, we're going to give it a find file tool, and then we're going to give it a open file tool. And you build all these like custom wrappers for, you know, all the different actions you might want the agent to take.

8. 5:44

   But CloudCo just uses Bash, and it's like really good at it. So how do you think about what you learned from that? Yeah, I think we're at this point right now where QuadCode actually has a bunch of tools. I think it's like a dozen or something like this. We actually like add and remove tools most weeks. So this changes pretty often. But today there actually is a search, there's a tool for searching.

9. 6:06

   And we do this for two reasons. One is the UX, so we can show the result a little bit nicer to the user because there's still a human in the loop right now for most tasks. And the second one is for permissions. So if you say in your like quad code, like settings.json, this file you cannot read, we have to kind of enforce this. We enforce it for bash, but we can do it a little bit more efficiently for if we have a specific search tool.

10. 6:28

    But definitely we want to like unship tools and kind of keep it simple for the model. Like last week or two weeks ago, we unshipped the LS tool. Because in the past we needed it, but then we actually built a way to enforce this kind of permission system for Bash. So in Bash, if we know that you're not allowed to read a particular directory, Quad's not allowed to elicit that directory. And because we can enforce that consistently, we don't need this tool anymore.

11. 6:55

    And this is nice because it's a little less choice for Quad, a little less stuff in context. Got it. And how do you guys split responsibility on the team?