Inside Claude Code From the Engineers Who Built It

At Every, the team credits Claude Code with transforming the way they work. They now ship to codebases they barely know, each new feature makes the next easier to build, and even non-technical teammates confidently use the terminal. To explore how this happened, AI & I host Dan Shipper invited Claude Code’s creators—Cat Wu (@_catwu) and Boris Cherny (@bcherny) from Anthropic AI—to discuss what they’ve learned from building one of the most beloved AI engineering tools in the world. This episode is a must-watch for anyone—technical or not—who wants to understand how to use Claude Code like the people who built it. If you found this episode interesting, please like, subscribe, comment, and share. Want even more? Sign up for Every to unlock our ultimate guide to prompting ChatGPT here: https://every.ck.page/ultimate-guide-to-prompting-chatgpt. It’s usually only for paying subscribers, but you can get it here for free. To hear more from Dan Shipper: Subscribe to Every: https://every.to/subscribe Follow him on X: https://twitter.com/danshipper Build your first AI-powered app at [ai.studio/build](http://ai.studio/build). Timestamps: 00:00:00 - Start 00:01:26 - Introduction 00:02:25 - Claude Code’s origin story 00:07:03 - How Anthropic dogfoods Claude Code 00:14:06 - Boris and Cat’s favorite slash commands 00:15:49 - How Boris uses Claude Code to plan feature development 00:21:53 - Everything Anthropic has learned about using sub-agents well 00:26:16 - Use Claude Code to turn past code into leverage 00:33:14 - The product decisions for building an agent that’s simple and powerful 00:36:38 - Making Claude Code accessible to the non-technical user 00:45:12 - The next form factor for coding with AI Links to resources mentioned in the episode: - Cat Wu: https://x.com/_catwu - Boris Cherny: https://x.com/bcherny - Claude Code: https://www.claude.com/product/claude-code

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  What made it work really well is that Claude Code has access to everything that an engineer does at the terminal. Everything you can do, Claude Code can do. There's nothing in between.

• 0:09Speaker 01

  There's actually an increasing number of people internally at Anthropic that are using like a lot of credits, like spending like over a thousand bucks every month. We see this like power user behavior. This is something that they teach in YC. If you can solve your own problem, it's much more likely you're solving the problem for others. There's this like really old idea and product called latent demand. You build a product in a way that is hackable, that is kind of open-ended enough that people can abuse it for other use cases it wasn't really designed for. And you build for that because you kind of know there was demand for it.

• 0:34Dan Shipper?

  Do you think the CLI is the final form factor? Are we going to be using Claude Code in the CLI primarily in a year or in three years? Or is there something else that's better?

• 0:56Speaker 03

  This podcast is sponsored by Google. Hey folks, I'm Amar, product and design lead at Google DeepMind. We just launched a revamped vibe coding experience in AI Studio that lets you mix and match AI capabilities to turn your ideas into reality faster than ever. Just describe your app and Gemini will automatically wire up the right models and APIs for you. And if you need a spark, hit I'm feeling lucky and we'll help you get started. Head to ai.studio/build to create your first app.

• 1:26Dan Shipper?

  Kat, Boris, thank you so much for being here.

• 1:29Speaker 00

  Thanks for having us.

• 1:30Dan Shipper?

  Yeah. So for people who don't know you, you are the creators of Claude Code. Thank you very much from the bottom of my heart. It's, I love Claude Code.

• 1:40Dan Shipper?

  That's amazing to hear. That's what we love to hear.

• 1:44Dan Shipper?

  Okay, I think the place I want to start is when I first used it, there was like this moment, like I think it was around when Sonnet 3.7 came out where I was like, I used it and I was like, holy shit. This is like a completely new paradigm. It's a completely new way of thinking about code. And the, the big difference was you went all the way and just eliminated the text editor. And you're just like, all you do is like talk to the, talk to the terminal and, and that's, that's it. And, you know, previous paradigms of AI programming.

• 2:18Dan Shipper?

  Previous harnesses have been like you have a text editor and you have the AI on the side and it's kind of like, or it's a tab complete. So take me through like that decision process, that process of architecting this new paradigm. How did you, how did you think about that?

• 2:35Speaker 01

  Yeah, I think the, the most important thing is it was not intentional at all.

• 2:40Speaker 01

  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, 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, you know, like a noob in the, in the time. Like I didn't know about any of these tools.

• 3:09Dan Shipper?

  Thank you for admitting that on the podcast.

• 3:14Speaker 01

  I didn't know any better. And then I, 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 and he just like rejected the PR and he was like, you wrote this by hand? What are you doing? He was Clyde. Cause 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 churn this thing out and just took forever. And, but it, but it worked and I was just mind blown that this, this was even possible. And this just kind of got the gears turning. Maybe you don't

• 3:56Speaker 01

  actually need IDE. And then later on, I was prototyping using the Anthropic API and the easiest way to do that was just building a little app in the terminal. Cause 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, I just started using tools 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.

• 4:41Speaker 01

  And I was like, this is just the craziest thing. I've never seen anything like this. Cause at the time I had only used IDEs with like, you know, like text editing, a little like one line autocomplete, multi-line autocomplete, whatever. 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, and I think it was the same for us. I think for me, it was like kind of Sonnet four, Opus four. That's where that magic moment was. It was like, oh my God, this, this thing works.

• 5:15Dan Shipper?

  That's interesting. So like, tell me about that, the tool moment, because I think that is one of the special things about Claude Code is it just writes bash and it's really good at it. And I think a lot of previous agent architectures, or even anyone building 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, you build all these like custom wrappers for, you know, all the different actions you might want the agent to take, but Claude Code just uses bash and it's like really good at it. So how do you think about, how do you think about what you learned from that?

• 5:51Speaker 01

  Yeah, I think we're at this point in our, Claude Code actually has a bunch of tools. I think it's like a dozen or something like this. We, 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, for searching. 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 on 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. But definitely, we want to like unship tools and kind of keep it simple for the model.

• 6:34Speaker 01

  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 ls that directory. And because we can enforce that consistently, we don't need this tool anymore. And this is nice because it's a little less choice for Quad, a little less stuff in context.

• 6:59Dan Shipper?

  Got it. And how do you guys split responsibility on the team?

• 7:03Speaker 00

  I would say Boris sets the technical direction and has been the product visionary for a lot of the features that we've come out with. I see myself as more of like a supporting role to make sure that, that one, that like our pricing and packaging resonates with our users. Two, making sure that we're shepherding all our features across the launch process. So from like deciding, all right, like these are the prototypes, we should definitely amp food to like setting the quality threshold for amp fooding through to communicating that to our end users. And there's definitely some new initiatives that we're working on that I would say historically, a lot of Quad Code has been built bottoms up, like Boris and a lot of the core team

• 7:47Speaker 00

  members have just had these great ideas for to do this, subagents, hooks, like all of these are bottoms up. As we think about expanding to more surfaces and bringing Quad Code to our places, I think a lot of those are more like, all right, let's talk to customers, let's bring engineers into those conversations and prioritize those services and knock them out.

• 8:06Dan Shipper?

  Got it. What is amp fooding?

• 8:08Speaker 00

  Oh, ant fooding is-

• 8:10Dan Shipper?

  Oh, anth fooding?

• 8:11Speaker 00

  Oh, um, it, it means dog fooding, so-

• 8:16Speaker 01

  Anthropic ants. I got it, I got it.

• 8:19Speaker 00

  Yeah, our nickname for internal employees is ant. And so, uh, ant fooding is our version of dog fooding. Uh, internally, over, I think, seventy or eighty percent of ants, uh, technical, anthropic employees use Quot Code every day. And so, every time we are thinking about a new feature, we push it out to people internally and we get so much feedback. We have a feedback channel, I think we get a post every five minutes. And so you get really quick signal on whether people like it, whether it's buggy, um, or whether, uh, it's not good and we should unship it.

• 8:54Dan Shipper?

  You can tell, um, you can tell that someone that is building stuff is using it all the time to build it, uh, because the, the, like, its ergonomics just makes sense if you're trying to build stuff and that that only happens if you're like, ant, ant fooding.

• 9:11Dan Shipper?

  I, yeah, and I, I think that that's a really interesting paradigm for building new stuff, like, that sort of bottoms up, I make something for myself. Um, tell me about that.

• 9:20Speaker 01

  Yeah, and Cat, Cat is also so humble. Um, I think Cat has a really big role in the product direction also. Like, it, it comes from everyone on the team. And like, these specific examples, this actually came from everyone on the team, like, to-do lists and subagents that was Sid, Hooks, Dixon shipped that, plugins, Daisy shipped that. So, like, everyone on the team, like, these ideas come from everyone. And so, I think for us, like, we build this core agent loop and this kind of core experience. And then everyone on the team uses the product all the time. Uh, and so everyone outside the team uses the product all the time. And so, there's just all these chances to build things that serve these needs. Like, for example, like, bash mode. You know, like, the exclamation mark and you can type in bash commands. This was just like, many months ago, I was using Quot Code

• 10:05Speaker 01

  and I, I was going back and forth between two terminals and just thought it was kind of annoying. Uh, and just on a whim, I asked Quad to kind of think of ideas. I thought of this, like, exclamation mark bash mode. And then I was like, great, make it pink and then ship it. It just did it. That's the thing that's still kind of persisted. And now you see others also catching on to that.

• 10:23Dan Shipper?

  That's funny. I actually didn't know that. And that's extremely useful because I always have to open up a new tab to run any bash commands. So you just do an exclamation point and then it just runs it directly instead of filtering it through all the Claude stuff.

• 10:35Speaker 00

  Yeah, and Claude Code sees the full output, too.

• 10:38Dan Shipper?

  Interesting. That's perfect.

• 10:40Speaker 00

  So anything you see in the Claude Code view, Claude Code also sees.

• 10:43Dan Shipper?

  OK, that's really interesting.

• 10:44Speaker 01

  And this is kind of a UX thing that we're thinking about. Like in the past, tools were built for engineers, but now it's equal parts engineers and model. And so as an engineer, you can see the output, but it's actually quite useful for the model also. And this is part of the philosophy also, like everything is dual use. So for example, the model can also call slash commands. So I have a slash command for slash commit where I run through a few different steps, like diffing and generating a reasonable commit message and this kind of stuff. I run it manually, but also Claude can run this for me. And this is pretty useful because we get to share this logic. We get to define this tool and then we both get to use it.

• 11:20Dan Shipper?

  Yeah. What are the differences in designing tools that are dual use from designing tools that are used by one or the other?

• 11:30Speaker 01

  Surprisingly, it's the same.

• 11:32Dan Shipper?

  OK.

• 11:32Speaker 01

  So far. Yeah, I sort of feel like this elegant design for humans translates really well to the models.

• 11:40Dan Shipper?

  So you're just thinking about what would make sense to you and the model generally. It makes sense to the model, too, if it makes sense to you.

• 11:47Speaker 00

  Yeah, I think one of the really cool things about Claude Code being a terminal UI and what made it work really well is that Claude Code has access to everything that an engineer does at the terminal. And I think when it comes to whether the tool should be dual use or not, I think making them dual use actually makes the tools a lot easier to understand. It just means that, OK, everything you can do, Claude Code can do. There's nothing in between.

• 12:12Dan Shipper?

  Yeah. That's interesting. Yeah, there are a couple of those decisions. So no code editor. It's in the terminal, so it has access to your files.

• 12:24Dan Shipper?

  And it's on your computer versus in the cloud and a virtual machine. So you get to use it in a repeated way where you can build up your Claude MD file or build slash commands and all that kind of stuff, where it becomes very composable and extensible from a very simple.

• 12:46Dan Shipper?

  Starting point. And I'm curious about how you think about, you know, for, for people who are thinking about, okay, I want to build an agent, I want to build, probably not Claude code, but like something else, how you get that, that simple package that then can extend and be really powerful over time?

• 13:05Speaker 01

  For me, I, I'd start by just thinking about it, like developing any kind of product where you have to solve the problem for yourself before you can solve it for others. And like, this is something that they teach in YC is you have to start with yourself. So like, if you, if you can solve your own problem, it's much more likely you're solving the problem for others. And I, I think for coding, starting locally is the reasonable thing. And, you know, now we have Claude code on the web. So you can also use it with a virtual machine and, um, you know, you can use it in a remote setting. And this is super useful when you're on the go, you want to take something off your phone. And this is sort of, we, we started proving this out kind of a step at a time where you can do at Claude and GitHub. And, uh, I use this every day, like on the way to work, I'm like at a red light, I probably shouldn't be doing this, but I'm like,

• 13:47Dan Shipper?

  Yeah, yeah, yeah.

• 13:48Speaker 01

  You know, on GitHub, at a red light, and then I'm like, at Claude, you know, fix this issue or whatever. And so it's, it's just really useful to be able to control it from your phone. Um, and this kind of proves out this experience. I, I don't know if this necessarily makes sense for every kind of use case. For coding, I think starting local is right. Um, I don't know if this is true for everything, though.

• 14:05Dan Shipper?

  Got it. What are the slash commands you guys use?

• 14:09Speaker 00

  Slash PR commit.

• 14:11Dan Shipper?

  Yeah.

• 14:13Speaker 00

  Yeah, it's, I, I think the PR commit slash command makes it a lot faster for Claude to know exactly what bash commands to run in order to make a commit.

• 14:22Dan Shipper?

  And what does the PR commit slash command do for people who aren't familiar?

• 14:26Speaker 00

  Oh, it, it just tells it like exactly how to make a commit.

• 14:30Dan Shipper?

  Okay.

• 14:31Speaker 00

  And you can like, you can say like, okay, these are the three bash commands that need to be run.

• 14:36Speaker 01

  Got it. And what's pretty cool is also we have, um, this kind of templating system built into slash commands. So we actually run the bash commands ahead of time. They're like embedded into the slash command. Um, and you can also pre allow certain tool indications. So for that slash command, we say allow, um, you know, get commit, get push, G H P R. And so you don't get asked for permission after you run the slash command because we have like a permission based security system. And then also it uses Haiku, which is pretty cool. So it's kind of a cheaper model and faster. Yeah, and for me, I use like Commit, Commit PR. Feature Dev we use a lot, so like Sid created this one. It's kind of cool, it kind of like walks you through step by step.

• 15:18Speaker 01

  Building something, so we prompt Claude like first ask me how to, what exactly I want, like build the specification. And then, you know, kind of like build like a detailed plan and then make a to do list, walk through step by step. So it's kind of like more structured feature development. And then I think the last one that we probably use a lot, so we use like security review for all of our PRs. And then also code review. So like Claude does all of our code review internally at Anthropic. You know, there's still a human approving it, but Claude does kind of the first step in code review. That's just a slash code review slash command.

• 15:49Dan Shipper?

  Got it. Yeah, what are the things, I would love to go deeper into like the, how do you make a good plan? So the sort of the feature dev thing, because I think there's a lot of like little tricks that I'm starting to find, or people at every start starting to find that work. And I'm curious like what, what are the things that we're missing? So for example, one step in the, one unintuitive step of the, of the, you know, plan development process is even if I don't exactly know what the thing that needs to be built is, I just have like a little sentence in my mind, like I want feature X, I have Claude just like implement it, just without giving it anything else, and I see what it does. And that helps me understand like, okay, here's actually what I mean, because it made all these different mistakes.

• 16:32Dan Shipper?

  Or like it, it did something that I didn't expect that might be good. And then I use that, like the learning from the sort of throwaway development. I just clear it out and then that helps me write a better plan spec for the actual feature development, which is something that you would never do before, because it'd be too expensive to just like Yolo, send in an engineer on a feature that you hadn't actually specked out. But because you have Claude going through your code base and doing stuff, you can like learn stuff from it. That helps inform the actual plan that you make.

• 17:02Speaker 01

  Yeah, I feel maybe I can start and I'm curious how you use it too. I think there's like a few different modes maybe for me, like one is prototyping mode. So like traditional engineering prototyping, you wanna kind of build the simplest possible thing that touches all the systems, just so you can kind of get a vague sense of like, what are the systems? There's unknowns and just to kind of trace through everything. And so I do the exact same thing as you Dan. Like Claude just does the thing and then I see where it messes up and then I'll ask it to just throw it away and do it again. So just hit escape twice, go back to the old checkpoint and then try again. I think there's also maybe two other kinds of tasks. So one is just things that Claude can one-shot and I feel pretty confident I can do it. So I'll just tell it and then I'll just go to a different tab and I'll shift tab to auto-accept

• 17:47Speaker 01

  and then just go do something else or go to another one of my Clods and tend to that while it does this.

• 17:53Speaker 01

  But also there's this kind of like harder feature development. So these are, you know, things are, maybe in the past it would have taken like a few hours of engineering time. And for this, usually I'll shift tab into plan mode and then align on the plan first before it even writes any code. And I think what's really hard about this is the boundary changes with every model in kind of a surprising way. Where the newer models, they're more intelligent. So the boundary of what you need plan mode for got pushed out like a little bit. Like before you used to need to plan, now you don't. And I think this is general trend of like stuff that used to be scaffolding with a more advanced model, it gets pushed into the model itself and the model kind of tends to subsume everything over time.

• 18:32Dan Shipper?

  Yeah, how do you think about like building a agent harness? That isn't just gonna like, you're not spending a bunch of time building stuff that is just gonna be subsumed into the model in three months when the new Claude comes out? Like, yeah, how do you, how do you know what to build versus what you just say? It doesn't work quite yet, but next time it's gonna work, so we're not gonna spend time on it.

• 18:55Speaker 00

  Ooh, I think we build most things that we think would improve Claude code's capabilities, even if that means we'll have to get rid of it in three months. If anything, we hope that we will get rid of it in three months. I think for now, we just want to offer the most premium experience possible. And so we're not too worried about throwaway work.

• 19:15Dan Shipper?

  Interesting.

• 19:16Speaker 01

  Yeah, and an example of this is something like even like plan mode itself. I think we'll probably unship it at some point when Claude can just figure out from your intent that you probably want to plan first. Or, you know, for example, I just deleted like 2,000 tokens or something from the system prompt yesterday. This goes like, like Sonnet 4.5 doesn't need it anymore. But Opus, Opus 4.1 did need it.

• 19:37Dan Shipper?

  What about, you know, in the case where the latest frontier, you know, model doesn't need it, but you know, you're trying to figure out how to make it more efficient because you have so many users that, you know, you're, maybe you're not going to use Opus or Sonnet 4.5 for everything. Maybe you're going to use Haiku. So there's a trade off between having a more elaborate harness for Haiku versus just like not spending time on it, using Sonnet, eating the cost and working on more frontier type stuff.

• 20:05Speaker 00

  In general, we've positioned Claude code to be a very premium offering. So our North Star is making sure that works incredibly well with the absolutely most powerful model we have, which is Sonnet 4.5 right now.

• 20:18Speaker 00

  We are investigating how to make it work really well for like future generations of smaller models, but it's, it's not the top priority for us.

• 20:27Dan Shipper?

  Okay. What do you think about, you know, one thing that I notice is we get models often, and thank you very much for this, we get models a lot before they come out, and it's our job to kind of figure out, is it any good? And over the last six months, when I'm testing Claude, for example, in the Claude app with a new frontier model, it's actually very hard to tell whether it's how, whether it's better immediately, but it's really easy to tell in Claude code because the harness matters a lot for the performance that you get out of the model. And you guys have the benefit of building Claude or building Claude code inside of the, inside of Anthropic. So there's like a much tighter integration between the fundamental like model training

• 21:12Dan Shipper?

  and the harness that you're building and they seem to kind of like really impact each other. So how does that, how does that work internally and what are the benefits you get from having that like tight integration?

• 21:24Speaker 01

  Yeah, I think the biggest thing is like researchers just use this. And so, you know, as they see what's working and what's not, they can, they can improve stuff. We do like a lot of evals and things like that to kind of communicate back and forth and understand where exactly the model's at. But yeah, there's this frontier where you need to give the model a hard enough task to really push the limit of the model. And if you don't do this, then all bottles are kind of equal. But if you give it a pretty hard task, you can tell the difference.

• 21:53Dan Shipper?

  What subagents do you use?

• 21:55Speaker 01

  I have a few. I have like a planner subagent that I use. I have a code review subagent. Code review is actually something where sometimes I use a subagent, sometimes I use a slash command. So usually in CI, it's a slash command, but in synchronously, I use a subagent for the same thing.

• 22:13Speaker 01

  It's a good question, yeah. Maybe it's like a matter of taste. Yeah, I don't know. I don't know. I think it's maybe when you're running synchronously, it's kind of nice to fork off the context window a little bit because all the stuff that's going on in the code review, it's not relevant to what I'm doing next. But in CI, it just doesn't matter.

• 22:30Dan Shipper?

  Are you ever spawning like 10 subagents at once? And for what?

• 22:35Speaker 01

  For me, I do it mostly for like big migrations.

• 22:37Dan Shipper?

  Okay.

• 22:37Speaker 01

  It's like the big thing. Actually, we have, so this like code review slash command that we use, there's a bunch of subagents there. And so one of the steps is like find all the issues. And so there's one subagent that's like checking for QUADMD compliance. There's another subagent that's looking through Git history to see what's going on. Another subagent that's looking for kind of obvious bugs. And then we do this like kind of deduping quality step after. So they find a bunch of stuff. A lot of these are false positives. And so then we spawn like five more subagents. And these are all just like checking for false positives. And in the end, the result is awesome. It finds like all the real issues without the false issues.

• 23:11Dan Shipper?

  That's great. I actually do that. So one of my non-technical Claude code use cases is expense filing. So like when I'm, I'm in SF right now, so like I have all these expenses. And so I built this little Claude project that, or in Claude code that.

• 23:26Dan Shipper?

  It uses one of these finance APIs to just download all my credit card transactions. And then it decides like, these are probably the expenses that I'm going to have to like file. And then I have two subagents, one that represents me and one that represents the company. And they like do battle to like, figure out like, what's the proper, like, actual set of expenses.

• 23:48Dan Shipper?

  It's like an auditor subagent and like a pro Dan subagent. So yeah, that kind of thing, the sort of like opponent process or pattern seems to be like an interesting one.

• 23:58Speaker 01

  Yeah, yeah, it's cool. I feel like when subagents were first becoming a thing, actually what inspired us, there was like a Reddit thread a while back, where someone made subagents for, there was like a front-end dev and a back-end dev and like a, I think like a designer.

• 24:10Speaker 00

  Testing dev.

• 24:11Speaker 01

  Testing dev, like there was like a PM subagent. And this is like, you know, it's cute, like it feels like a little maybe too anthropomorphic. Maybe there's something to this, but I think like the value is actually like the uncorrelated context windows. Where you have these two context windows that don't know about each other. And this is kind of interesting and you tend to get better results this way.

• 24:29Dan Shipper?

  What about you? Do you have any interesting subagents you use?

• 24:32Speaker 00

  So I've been tinkering with one that is really good at front-end testing. So it uses Playwright to like, see, all right, what are like all the errors that are coincided? And pull them in and try to test more steps of the app. It's not totally there yet, but I'm seeing signs of life. And I think it's the kind of thing that we could potentially bundle in one of our plugins marketplaces.

• 24:59Dan Shipper?

  Yeah, definitely. I've used something like that just with Puppeteer and just like watching it build something and then open up the browser. And then be like, oh, I need to change this. It's like, this is like, oh my God.

• 25:10Speaker 00

  Yeah, it's really cool.

• 25:12Speaker 01

  It's really cool. I think we're starting to see the beginnings of this like massive, like multi-massive subagents. I don't know what to call this, like swarms or something. There's a bunch of people, there's actually an increasing number of people internally at Anthropic that are using like a lot of credits every month, like, you know, like spending like over a thousand bucks every month. And this like, this percent of people is growing actually pretty fast. And I think the common use case is like code migration. And so what they're doing is like framework A to framework B. There's like the main agent and makes a big to-do list for everything. And then just kind of map reduce over a bunch of subagents. So you instruct a lot of like, yeah, like start 10 agents and then just go like, you know, 10 at a time and just migrate all the stuff over.

• 25:50Dan Shipper?

  That's interesting.

• 25:53Dan Shipper?

  What would be like a concrete example of the kind of migration that you're talking about?

• 25:56Speaker 01

  I think the most classic is like lint rules. So there's like, you know, there's some kind of lint rule you're rolling out. There's no auto fixer because it's like, you know, like AST analysis can't really, it's kind of too simplistic for it. I think other stuff is like framework migrations, like we just migrated from like one testing framework to a different one. That's a pretty common one where it's super easy to verify the output.

• 26:16Dan Shipper?

  One of the things I've found is, and this is both for projects, projects inside of every and then just open source projects. It's like if you're someone building a product and you want to build a feature that's been done before. So maybe like an example that people might need to implement a bunch is like memory. How do you do memory?

• 26:36Dan Shipper?

  Because we have a bunch of different products internally, you can just like spawn Claude subagents to be like, how do these three other products do it? And there's like possibility for just like tacit code sharing where you don't need to like have an API or you don't need to like ask anyone. You can just be like, how does, how do we do this already? And then use the best practices to, to build your own. And you can also do that with open source because there's like tons of open source projects where people are like, you know, they've been working in memory for like a year and it's like really, really good. And you'd be like, what are the patterns that people have figured out and which ones do I want to implement?

• 27:07Speaker 00

  Totally. You can also connect to your version control system. If you've built a similar feature in the past, Claude code can use those APIs, like query GitHub directly and find how people implemented a similar feature in the past and read that code and copy the relevant parts.

• 27:25Dan Shipper?

  Yeah. Is there, have you found any use for like log files of, okay, you know, here's, here's the full history of like how I implemented it? And like, is that important to give to Claude and, and how are you, how are you implementing that or making it useful for it?

• 27:41Speaker 00

  Some people swear by it. There are some people at Anthropic where for every task they do, they tell Claude code to write a diary entry in a specific format. That's just documents like what did it do, what did it try, why didn't it work? And then they even have these agents that like look over the past memory and synthesize it into observations. I think this is like the starting budding. Like, there's like something interesting here that we could productize. Um, but it's a new emerging pattern that we're seeing that works well. I think the hard thing about like one-shotting memory from just one transcript is that it's hard to know how relevant a specific instruction is to all future tasks.

• 28:22Speaker 00

  Like our canonical example is if I say make the button pink, I don't want you to remember to make all buttons pink in the future. And so I think um synthesizing memory from a lot of logs is a is a way to um find these patterns more um consistently.

• 28:39Dan Shipper?

  It seems like you probably need, like, there's some things where you're gonna know.

• 28:44Dan Shipper?

  You'll be able to summarize, like, synthesize or summarize in this sort of like top-down way, like, this this will be useful later and and you'll you'll know the right level of abstraction at which it might be useful. But then there's also a lot of stuff where it's like, you actually, you know, any given, like, commit log, like, make the button pink. It could be useful for kind of an infinite number of different reasons that you're not going to know beforehand. So you also need the the model to be able to look up all similar past, you know, commits and surface that at the right time. Is that something that you're also thinking about?

• 29:19Speaker 01

  Yeah, I think I think there could there could be something like that. Maybe I think one way to see it is this kind of like traditional memory storage work, like Memex, like kind of stuff where you you just want to like put all the information into the system and then it's kind of a retrieval problem problem after that.

• 29:36Speaker 01

  Yeah, I think as the model also gets smarter, it naturally, I've seen it start to naturally do this also with Sonar 4.5, where if it's stuck on something, it'll just naturally start looking, like we talked about before, like, using bash spontaneously to just like look through Git history and be like, oh, okay, yeah, this is kind of an interesting way to do it.

• 29:54Dan Shipper?

  Yeah. One of the things that, like, we were talking before we started recording, one of the things that we're doing inside of every, like, I feel like it has really changed the way that we do engineering, because everyone is Claude Code-pilled, like CLI-pilled. And we have this engineering paradigm that we call compounding engineering, where In normal engineering, every feature you add, it makes it harder to add the next feature. And in compounding engineering, your goal is to make the next feature easier to build from the feature that you just added. And the way that we do that is we try to codify all the learnings from everything that we've done to build the feature. So like, you know, how did we make the plan and what parts of the plan needed to be changed? Or like, when we started testing it, like, what issues did we find? What are the things that we missed?

• 30:39Dan Shipper?

  And then we codify them back into all the prompts and all the subagents and all the slash commands so that the next time when someone does something like this, it catches it and that makes it easier. And that's why for me, for example, I can like hop into one of our code bases and start like being productive, even though I'm, I don't know anything about how the code works, because we have this like built up memory system of all the stuff that we've learned as we've implemented stuff. But we've had to build that ourselves. I'm curious, are you working on that kind of loop so Quadcode does that automatically?

• 31:14Speaker 01

  Yeah, we're starting to think about it. It's funny, we were just, we heard the same thing from Fiona. She just joined the team and, you know, she's our, she's our manager. She hasn't coded in like 10 years, something like that. And she was landing PRs on her first day. And she was like, yeah, like not only did I kind of, I forgot how to code and Quadcode kind of made it super easy to just get back into it, but also I didn't need to ramp up on any context because I kind of knew all this. And I think a lot of it is about like, when people put up pull requests for Quadcode itself, and I think our customers tell us that they do like similar stuff pretty often. If you see a mistake, I'll just be like, @quad, add this to QuadMD so that the next time it just knows this automatically.

• 31:59Speaker 01

  And you can kind of like instill this memory in kind of a variety of ways. So you can say like, @quad, add it to QuadMD. You can also say, @quad, write a test. You know, that's like an easy way to make sure this doesn't regress. And I don't feel bad asking anyone to write tests anymore.

• 32:12Dan Shipper?

  Right.

• 32:13Speaker 01

  It's like super easy. And like, I think probably close to 100% of our tests are just written by Quad. And if they're bad, we just won't commit it and then the good ones stay committed. And then also, I think lint rules are a big one. So for stuff that's enforced pretty often, we actually have a bunch of internal lint rules. Claude writes 100% of these. And this is mostly just like at Claude, in a PR, write this lint rule. And yeah, there's sort of this problem right now about like, how do you do this automatically? And I think generally how like Kat and I think about it is we see this like power user behavior. And the first step is how do you enable that by making the product hackable? So the best users can figure out how to do this cool new thing. But then really the hard work starts of like, how do you take this and bring it to everyone else?

• 32:57Speaker 01

  And for me, I count myself in the everyone else bucket. Like, you know, I don't really know how to use Vim. Like, I don't have this like crazy like T-Buck setup. So I have like a pretty vanilla setup. So if you can make a feature that I'll use, it's a pretty good indicator that like other kind of average engineers will use it.

• 33:13Dan Shipper?

  That is interesting. Tell me about that, because like that's something I think about all the time is making something that is extensible and flexible enough that power users can find like novel ways to use it that you would not have even dreamed of. But it's also simple enough that anyone can use it and it's and they can be productive with it. And you can, you can kind of pull what the power users find back into like the basic experience. Like, how do you think about making those design and product decisions so that you enable that?

• 33:39Speaker 00

  In general, we think that like every environment is a little bit different from the others. And so it's really important that every part of our system is extensible. So everything from your status line to adding your own slash commands through to hooks, which let you insert a bit of determinism at pretty much any step in Claude code. So we think these are the, these are like the basic building blocks that we give to every engineer that they can play with.

• 34:06Speaker 00

  For plugins, plugins is actually our, so it was built by Daisy on our team. And this is, this is our attempt to make it a lot easier for the average user like us to bring these slash commands and hooks into our workflows. And so what plugins does is it lets you browse existing MCP servers, existing hooks, existing plugins, and just like, or sorry, existing like slash commands and just let you write one command in Claude code to pull that in for yourself.

• 34:37Speaker 01

  There's this like really old idea and product called latent demand, which I think is probably the main way that I personally think about product and like thinking about what to build next. And it's a super simple idea. It's you build a product in a way that is hackable, that is kind of open-ended enough that people can abuse it for other use cases it wasn't really designed for. Then you see how people abuse it and then you build for that because like you kind of know there was demand for it. Right. And like, you know, when I was at Meta, this is how we built kind of all the big products. I think almost every single big product had this nugget of latent demand in it. You know, like for example, something like Facebook Dating, it came from this idea that when we looked at who looks at people's profiles,

• 35:17Speaker 01

  I think 60% of views were between people of opposite gender, so kind of like traditional setup, that were not friends with each other. And so we're like, oh man, okay, maybe there's like, maybe if we like launch a dating product, we can kind of harness this demand that exists. That's interesting. And for, you know, Marketplace, it was pretty similar. I think it was like 40% of posts in Facebook groups at the time were by cell posts. And so we're like, okay, people are trying to use this product to buy itself. If we just build a product around it, that's probably going to work. And so we think about it kind of similarly, but also we have the luxury of building for developers. And developers love hacking stuff and they love customizing stuff. And it's like, as a user of our own product, it makes it so fun to build and use this thing. And so, yeah, like, like I said, we just build the right extension points. We see how people use it and that kind of tells us what to build next.

• 36:02Speaker 00

  Like for example, we got all these user requests where people were like, dude, Call Code is asking me for all these permissions and I'm out here getting coffee. I don't know that it's asking me for permissions. How can I just get it to like ping me on Slack? And so we built hooks, Dixon built hooks, so that people could get pinged on Slack. And you could get pinged on Slack for anything that you want to get pinged on Slack for. And so it was very much like. People really wanted the ability to do something. We didn't want to build the integration ourselves. And so we exposed hooks for people to do that.

• 36:38Dan Shipper?

  The thing that makes me think of is you recently released, you kind of moved or rebranded how you talk about Claude Code to be this like more general purpose agent SDK. Is that, was that driven by some latent demand? Where you sort of saw there's like a more general purpose use case for what you built?

• 36:58Speaker 00

  We realized that similar to how you were talking about using Claude Code for things outside of coding, we saw this happen a lot. Like we get a ton of stories of people who are using Claude Code to like help them write a blog and like manage all the like data inputs and take a first pass in their own tone. We find people building like email assistants on this. I use it for a lot of just like market research. Because at the core, it's like an agent that can just go on for an infinite amount of time as long as you give it a concrete task and it's able to fetch the right underlying data. So one of the things I was working on was I wanted to look at all the companies in the world and how many engineers they had and to create a ranking.

• 37:43Speaker 00

  And this is something that Claude Code can do, even though it's not a traditional coding use case. So you realize that like the underlying primitives were really general. As long as you give, as long as you have like an agent loop that can continue running for a long period of time and you're able to like access the internet and write code and run code, pretty much you can, if you squint, you can kind of build anything on it.

• 38:07Speaker 01

  And I think like, but at the point where we like rebranded it to like, from the Claude Code SDK to the Claude Agent SDK, there was already like many thousands of companies using this thing. And a lot of those use cases were not about coding. So it's like both internally and externally, we kind of saw that.

• 38:23Speaker 00

  It's like health assistants, like financial analysts, legal assistants. It was pretty broad.

• 38:30Dan Shipper?

  Yeah. What are the coolest ones?

• 38:33Speaker 01

  I feel like actually you had Noah Breier on the podcast recently. I thought like the obsidian, like kind of mind mapping, note keeping use case is really cool. It's insane how many people use it for this.

• 38:44Dan Shipper?

  Yeah.

• 38:44Speaker 01

  This particular combination. I think some other, like some coding or kind of coding adjacent use cases that are kind of cool is we have this like issue tracker for Claude code. The team's just like constantly underwater, like trying to keep up with all the issues coming in. There's just so many. And so like Claude dedupes the issues and it automatically finds duplicates and it's extremely good at it. It also does first pass resolution. So usually when there's an issue, it'll proactively put up a PR internally. And this is a new thing that Inigo on the team built. So this is pretty cool. There's also like on-call and kind of collecting signals from other places, like getting like sentry logs and getting like logs from BigQuery and kind of coletting all this. Claude's just really good at doing this because it's all just bash in hand.

• 39:28Speaker 01

  And so these are all kind of these internal use cases that I saw.

• 39:31Dan Shipper?

  Is it, so when it's, you know, coletting logs or deduping issues, is that like you have Claude's like continually running in the background? And is that something that you're building for?

• 39:42Speaker 00

  It gets triggered, for that particular one, it gets triggered whenever a new issue is filed. So it runs once, but it can choose to run for as long as it needs.

• 39:50Dan Shipper?

  Got it. What about the idea of Claude's always running?

• 39:53Speaker 00

  Ooh, proactive Claude's. I think it's definitely where we want to get to. I would say right now, we're very focused on making Claude code incredibly reliable for like individual tasks. And, you know, if you think about, like, if you think about like multiline autocomplete and then like single turn agents and then now we're working on like Claude code that can complete tasks. I feel like if you trace this curve, eventually you go to even higher levels of abstraction, like even more complicated tasks. And then hopefully the next step after that is a lot more productivity. So just understanding what your team's goals are, what your goals are, being able to say, hey, I think you probably want to try this feature. And here's a first pass of the code and here are the assumptions I made and are these correct?

• 40:39Dan Shipper?

  I can't wait. And I think probably right after that is Claude is now your manager.

• 40:48Speaker 00

  That's not in the plan.

• 40:50Dan Shipper?

  So everyone on the team was like super excited that we were, we were talking today and they gave me a bunch of questions and I want to make sure I hit all the questions.

• 41:00Dan Shipper?

  Oh, here's a good one. Why did you choose agentic rag over vector search in your architecture? And are like vector embeddings still relevant?

• 41:11Speaker 00

  So actually, initially, we did use vector embeddings.

• 41:16Speaker 00

  They're just really tricky to maintain because you have to continuously re-index the code and they might get out of date and you have local changes. So those need to make it in. And then as we thought about what does it feel like for an external enterprise to adopt it, we realized that this exposes a lot more surface area and like security risk. We also found that actually Claude Code is really good and Claude models are really good at agentic search. So you can get to the same accuracy level with agentic search and it's just a much cleaner deployment story.

• 41:50Dan Shipper?

  That's really interesting.

• 41:51Speaker 00

  If you do want to bring semantic search to Claude Code, you can do so via an MCP tool. So if you want to manage your own index and expose an MCP tool that lets Claude Code call that, that that would work.

• 42:04Dan Shipper?

  What do you think are the top MCPs to use with Claude Code?

• 42:08Speaker 00

  Puppeteer and Playwright are pretty high up there.

• 42:10Dan Shipper?

  Definitely, yeah.

• 42:11Speaker 00

  Sentry has a really good one. Asana has a really good one.

• 42:16Dan Shipper?

  Do you think that there are any, any power user tips that you see people inside of Anthropic or, you know, other people who are, you know, big power, you know, inside of organizations that are big Claude Code power users that people don't know about, but they should?

• 42:35Speaker 00

  One thing that Claude Code doesn't naturally like to do, but that I personally find very useful is Claude Code doesn't naturally like to ask questions. But you know, if you're brainstorming with a thought partner, a collaborator, usually you do ask questions back and forth to each other. And so this is one of the things that I like to do, especially in plan mode. I'll just tell Claude Code like, hey, we're just brainstorming this thing. Please ask me questions. If there's anything you're unsure about, I want you to ask questions and I'll do it. And I think that actually helps you arrive at a better answer.

• 43:09Speaker 01

  There's also so many discs that we can share. I think there's a few really common mistakes I see people make. One is, like you said, not using plan mode enough. This is just super important. And I think this is people that are kind of new to agent decoding. They kind of assume this thing can do anything. And it can't. It's not that good today. And it's going to get better. But today, it can one-shot some tasks. It can't one-shot most things. And so you kind of have to understand the limits. And you have to understand where you get in the loop. And so something like plan mode, it can like 2, 3x success rates pretty easily. If you land on the plan first. Other stuff that I've seen power users do really well is companies that have really big deployments of Quadcode. And luckily, there's a lot of these companies, so we can learn from them.

• 43:54Speaker 01

  Having settings JSON that you check into the codebase is really important. Because you can use this to pre-allow certain commands. So you don't get permission prompted every time. And also to block certain commands. Let's say you don't want web fetch or whatever. And this way, as an engineer, I don't get prompted. And I can check this in and share it with the whole team. So everyone gets to use it.

• 44:14Dan Shipper?

  I go around that by just using dangerously skip permissions.

• 44:20Speaker 01

  Yeah, we kind of have this there, but we don't recommend it. It's a model. It can do weird stuff. I think another cool use case that we've seen is people using stophooks for interesting stuff. So a stophook runs whenever the turn is complete. So this is, it did some tool calls, back and forth with whatever. And it's done. And it returns control back to the user. Then we run this stophook. And so you can define a stophook that's like, if the tests don't pass, return the text, "Keep going." And essentially, you can just make the model like, "Keep going until the thing is done." And this is just insane when you combine it with the SDK and this kind of programmatic usage. This is a stochastic thing. It's a non-deterministic thing. But with scaffolding, you can get these deterministic outcomes.

• 45:06Dan Shipper?

  So you guys started this sort of CLI, this CLI paradigm shift. Do you think the CLI is the final form factor? Are we going to using Claude code in the CLI primarily in a year or in three years? Or is there something else that's better?

• 45:21Speaker 00

  I mean, it's not the final form factor, but we are very focused on making sure the CLI is like the most intelligent that we can make it and that's as customizable as possible. You can talk about the next form factors.

• 45:35Speaker 01

  Yeah, I mean, Kat's asking me to talk about it because no one knows. This stuff's like, it's just moving like so fast, right? Like, no, no one knows what these form factors are. Like, right now, I think our team is in experimentation mode. So we have CLI, then we came out with the IDE extension. Now we have a new IDE extension that's like a GUI. It's a little more accessible. We have at Claude and GitHub, so you can just add Claude it anywhere. Now there's Claude on web and on mobile, so you can use it on any of these places. And we're just in experimentation mode, so we're trying to figure out what's next. I think like, if we kind of zoom out and see where this stuff is headed, I think one of the big trends is longer periods of autonomy.

• 46:17Speaker 01

  And so with every model, we kind of time, how long can the model just keep going and do tasks autonomously and just, you know, in dangerous mode in a container, keep auto-compacting until the task is done? And now we're on the order of like double-digit hours. I think it's like the last model's like 30 hours, something like this. And, you know, the next model is going to be days. And as you think about kind of parallelizing models, there's kind of a bunch of problems that come out of this. So one is, what is the container this thing runs in? Because you don't want to have to like, close your laptop.

• 46:46Dan Shipper?

  I have that right now because I'm doing a lot of DSP. I don't know, I've only heard, I've only read it, but DSP or DSP prompt optimization and like, it's on my laptop and it's like, I don't want to close. I'm like in the window, like with my laptop open because I'm like, I don't want to close it, yeah.

• 47:02Speaker 01

  Yeah, that's right. Yeah, we like visited companies before, like, like customers that everyone's just like walking around with their like Claude codes.

• 47:09Speaker 01

  Is this running? So I think one is kind of getting away from this mode. And then I also think pretty soon we're going to be in this mode of like quads, monitoring quads. And kind of, I don't know what the right form factor for this is because as a human, you need to be able to inspect this and kind of see what's going on. But also it needs to be quad optimized where you're optimizing for kind of bandwidth between like the quad to quad communication. So my prediction is terminal is not the final form factor. My prediction is there's going to be a few more form factors in the coming months, you know, maybe like year or something like that. And it's going to keep changing very quickly.

• 47:46Dan Shipper?

  What do you think about, you know, I teach a lot of Claude code to a lot of every subscribers.

• 47:50Speaker 00

  Thank you.

• 47:52Dan Shipper?

  You're welcome. Doing your work for you.

• 47:57Dan Shipper?

  And I think the, like, one of the big things is just the terminal is intimidating. And just like being on a call with subscribers being like, here's how you open the terminal and you're allowed to do this, even if you're non-technical is like a big deal. How do you think about that?

• 48:14Speaker 00

  Yeah, I, one of the people on our marketing team started using Claude code because she was writing some content that touched on Claude code and I was like, you should really experience it. And she got like 30 pop-ups on her screen where she had to accept various permissions because she'd never used a terminal before. So I completely see eye to eye with you on that. It's definitely hard for non-engineers. And there's even some engineers we've found who aren't fully comfortable with working day to day in the terminal. Our VS Code GUI extension is our first step in that direction because you don't have to think about the terminal at all. It's like a traditional interface with a bunch of buttons.

• 48:52Speaker 00

  We are working on more graphical interfaces. So Claude code on the web is a GUI. I think that actually might be a good starting point for people who are less technical.

• 49:03Dan Shipper?

  Yeah.

• 49:04Speaker 01

  There was this like magic moment, maybe like a few months ago where like I walked into the office and the, some of the data scientists at Anthropic like sit right next to the Claude code team. And the data centers just had like Claude code running on their computers. And I was like, what is this? Like, how did you figure this out? I think it was like Brandon was like the first one to do it. And he was like, oh yeah, I just like installed it. Like I work on this product, so like I should use it. And I was like, oh my God. So he like, he figured out how to use a terminal and OGS, like, you know, he hasn't really done this kind of work before before. Obviously like very technical. So I think now we're starting to see all these kind of like code adjacent like functions, people you use Claude code.

• 49:45Speaker 01

  And yeah, it's kind of interesting, like from a latent demand point of view, these are people hacking the product. So there's like demand to use it for this. And so we want to make it a little bit easier with more accessible interfaces. But at the same time, for us, for Claude code, we're laser focused on building the best product for the best engineers. And so we're focused on software engineering and we want to make this like really good. But we want to make it a thing that other people can can hack.

• 50:09Speaker 00

  Sometimes Claude code will write code that's a bit verbose. But you can just tell it to simplify it and it does a really good job.

• 50:17Dan Shipper?

  Hmm, interesting. And so, and how are, how and when are you doing that? So you're, you're using a slash command or you're?

• 50:23Speaker 00

  I just say it.

• 50:24Dan Shipper?

  Just every time?

• 50:25Speaker 00

  Sometimes you're like, hey, this should be a one line change.

• 50:28Dan Shipper?

  Yeah.

• 50:28Speaker 00

  And I'll write five lines here, like simplify it and it understands immediately what you mean and it'll fix it.

• 50:34Dan Shipper?

  Yeah, I think a lot of people on our team do that, too.

• 50:37Dan Shipper?

  That's, that's interesting. Why do you like, why not then, if you're saying that all the time, why not then, you know, push that into like a slash command or the harness or something like that to, yeah, make it just happen automatically?

• 50:49Speaker 00

  We do have instructions for this in the Claude MD. I think it impacts such a low percentage of conversations that we don't want it to like over rotate in the other direction. And then the reason why not slash command is because you actually don't need that much context. I think slash command is really good for situations where you would otherwise need to write two, three lines. But for some, like even for plan mode, you actually can use a few words, but sometime, but it actually takes two or three lines to capture the entirety of what you want in plan mode. For simplify it, you can just write simplify it and it gets it.

• 51:26Dan Shipper?

  Yeah, that makes sense. Cool. Um, okay, now we're, we can.

• 51:34Dan Shipper?

  That's interesting.

• 51:35Speaker 01

  Yeah, but, but the stuff like, you know, it still feels just so early.

• 51:38Speaker 00

  Yeah.

• 51:39Speaker 01

  You know, like we, we were talking before, before the recording about like, kind of where are we on the adoption curve? And it's still.

• 51:45Dan Shipper?

  The Houshian curve or whatever.

• 51:49Speaker 01

  It just feels, it just feels like we're, you know, like first 10% still like this stuff is going to change so fast. It's going to keep changing.

• 51:55Speaker 00

  Even when I talk to researchers outside of Anthropic, who, who use Codcode, um, they also get stuck on things like this, like not realizing that they can just tell the LLM to simplify it. And I think that just goes to show that even for people who are like working in this industry, they don't always realize that you can just talk to the model.

• 52:13Dan Shipper?

  That's the thing is like, I, I think that there's this underlying expectation that using AI shouldn't have to be a skill. Like, because it just does whatever you say. And you're like, well, I mean, whatever you say is going to matter for what it does. So if you can say things better, it's going to do better.

• 52:31Speaker 01

  Yeah, I mean, it, it changes with every model though. That's the, that's the hard part, like, you know, prompt engineer was a job and now famously it's not a job anymore. And there's going to be more jobs that are than like not, not jobs anymore of these kind of like little micro skills that you have to learn to use this thing. And as the model gets better, it can just like interpret it better. But I think that's also like, for us, this is part of this kind of humility that we have to have building a product like this, that we just really don't know what's next. And we're just trying to figure it out, kind of along with everyone else. We're just here for the ride.

• 52:59Dan Shipper?

  And that's why it's cool that you're building it for yourself. Cause I think that's the, that's the best way to know that is just like you're, and this is what we do too. It's like, you're sort of living in the future, you're using it all the time. And, uh, it's pretty clear what's missing. You're like, I just want this thing and you can just do the next thing rather than being like, hmm, let me ask like some enterprise product manager at like some gigantic company, like what kind of AI feature do you want? And they're like, I don't know, like, you know, put a little chatbot on the side of my, you know, IDE and you're like, okay.

• 53:28Speaker 01

  Yeah, this is like the luxurious thing about building DevTools, right?

• 53:31Dan Shipper?

  Yeah.

• 53:31Speaker 01

  You're your own customer.

• 53:32Dan Shipper?

  I think it's also really a unique thing about AI because it sort of reset the game board for all software. So, you know, we have Quora, this like email assistant, and we have like Sparkle, which organizes your files. And it's like, anything that you do for something that you want to use on your computer, if you're building it with AI, there's a good chance that hasn't been done before because like, the whole landscape has been reset. And so, it's a uniquely exciting time to build stuff for yourself.

• 54:04Speaker 00

  Totally. I think it totally opens the point you feel too. It's like, any individual can now build an app to fill their need and then distribute it to everyone else.

• 54:13Dan Shipper?

  Yeah.

• 54:14Speaker 00

  It's really cool. I've been prototyping all these like, random pet projects.

• 54:21Speaker 00

  I just moved into a new apartment and it's empty. And so, I've been, I've been building this like shopping advisor assistant on like the Claude Agent SDK, because who has time to like, read all the reviews and like, look at all the options and find their pricing? And everything's like, really hard to discover. And so, it just like, asks me a bunch of questions and I tell it what I want.

• 54:42Dan Shipper?

  Like for furniture?

• 54:43Speaker 00

  Yeah, exactly. And it shows me a bunch of photos, like different sofas and options, and what people say online. And then I tell it what I don't like. And it's literally feels like working with a shopping assistant. It's been really cool.

• 54:54Dan Shipper?

  That's really cool.

• 54:56Speaker 00

  I also have my little email response agent that like, drafts responses for me. But I don't use email that much, so.

• 55:03Speaker 01

  Oh, and I knew it wasn't you responding.

• 55:07Speaker 00

  That's why it's seven days delayed.

• 55:11Speaker 00

  The agent's just doing a very thorough job.

• 55:16Speaker 00

  Agent SDK is cool though.

• 55:18Speaker 01

  Yeah, Agent SDK is cool. Yeah, it's, it always just feels amazing like, how much we're able to build with such a small team.

• 55:24Speaker 00

  Yeah.

• 55:24Speaker 01

  So I feel like there's-

• 55:25Speaker 00

  Oh, the other thing that's really cool is that, I think people are just shifting their mindset from docs to demos. Like internally, our currency is actually demos. It's like, you want people to be excited about your thing?

• 55:36Dan Shipper?

  Yeah.

• 55:36Speaker 00

  Show us like, show us 15 seconds of what it can do. And we find that everyone on the team now has this kind of indoctrinated-

• 55:43Dan Shipper?

  Democulture, for sure. And I think that's better because there's a lot of things that you might have in your head that- If you're a great writer, maybe you could figure out how to explain it, but it's just, even then, it's just really hard to explain. But if someone can see it, they like get it immediately. And I think that's happening for product building, but it's also happening for like all sorts of other types of creative endeavors, like making a movie, for example, like you had to pitch it, but now you can just be like, I made this Sora video and like, you know, check, like you can kind of see like the glimmer of the thing you're trying to make for very cheap. And so that means you don't have to spend time convincing people as much. You're gonna be like, here, I made it.

• 56:22Speaker 01

  Yeah, and also as a builder, like you can just make it and then like make it again and then make it again. Until you're happy. I feel like the flip side is like you used to make a doc or, you know, like whiteboard something or, you know, like I would draw stuff in like sketch or Figma or whatever. And now we'll just like build it until I like how it feels. And it's just like so easy to get that feeling out of it now. And I think it's like you could see it visually before or you could describe it in words, but it's like you could never get the vibe. And now like the vibe is real easy.

• 56:51Dan Shipper?

  Yeah.

• 56:52Speaker 00

  And you built Plan Mode like three times.

• 56:54Speaker 01

  Yeah.

• 56:55Speaker 00

  Because of this.

• 56:56Dan Shipper?

  Like you built it and then you threw it out and rebuilt it and then threw it out and rebuilt it?

• 56:59Speaker 01

  Yeah, or like Todo's, like Sid built the original version, like also like three or four, he built like three or four prototypes. And then I produced maybe like 20 versions after that, like in like a day. Yeah, I think this is like a lot of, pretty much everything we've released, there was at least a few prototypes behind it.

• 57:16Dan Shipper?

  How do you like, um, keep track of and carry forward the things you learn from prototype to prototype? And especially if it's like, you know, some one person is prototyping it and then you're like, I'm gonna take it over, I'm gonna do 20 more. Like, how do you, how do you maximize what you get out of that?

• 57:33Speaker 01

  You know, it's like, there's maybe a few elements of it. One is the style guide. So there's like some elements of style that we discover. And I think a lot of this is like building for the terminal, or like we're kind of discovering a new design language for the terminal and kind of building it as we go. And I think some of this you can codify in a style guide. So this is our QuadMD. But then there's this other part of it that's like kind of product sense where I don't think the model totally gets it yet. And I think maybe we should be trying to find ways to like teach the model this this kind of product sense about like this works and this doesn't. Right? Because in in product, you want to solve the person's problem in the simplest way possible and then delete everything else that's not that. And just get everything out of the way. So you kind of you you align the product to the intent as quickly as possible.

• 58:18Speaker 01

  And maybe the model doesn't totally get that yet.

• 58:21Speaker 00

  Yeah, it's never doesn't really feel what it's like to use Quadcode. Like the model doesn't use Quadcode.

• 58:31Speaker 01

  Yeah. And so I think like when, you know, a Quadcode can like test itself and it can kind of use itself. And like we we do this one developing and it can see like UI bugs and things like that.

• 58:43Speaker 01

  I don't know, maybe we should just try prompting it, though. It could like honestly, a lot of the stuff is as simple as that. Like when there's some new idea, usually you just prompt it and often it just works. Maybe we should just try that.

• 58:55Speaker 00

  A lot of the prototypes are actually the UX interactions. And so I think once we discover a new UX interaction like shift tab for auto except, I think, uh, Boris figured out.

• 59:09Speaker 01

  That was Igor, actually.

• 59:10Speaker 00

  Oh, Igor.

• 59:11Speaker 01

  Yeah.

• 59:12Speaker 00

  Then new things can like fit into that.

• 59:14Speaker 01

  We did like doing prototypes for like a week.

• 59:18Speaker 00

  Yeah, shift tab felt really nice. And then one of the the now current plan mode iteration. Use a shift tab because it's actually just like another way to tell the model how agentic it should be. And so I think as as more features use the same uh interaction, you form like a stronger mental model for what should go where.

• 59:40Speaker 01

  Yeah. All right. Like thinking, I think, is another really good one. Like first, we were like before we released Quadcode, or maybe it was like the first thinking model was like three, seven. I forget what the first one was. But yeah, and it was like it was able to think and we're like brainstorming, like, how do we like toggle thinking? And then someone was just like, what if you just like ask the model to think in natural language and it knows how to think and we're like, okay, sweet.

• 1:00:04Speaker 01

  And so like we we did that for a while and then um we realized that people were accidentally toggling it. So they were like, don't think. And then the model's like, oh, I should think. It just started thinking. And so we had to kind of like. Tune it out. So, you know, don't think, didn't trigger it. But then it still wasn't obvious. So then we made a UX improvement to like, highlight the thinking words. And I was like, that was so fun. And it felt really magical.

• 1:00:24Dan Shipper?

  When you do Ultra Think, it's like a rainbow or whatever.

• 1:00:27Speaker 01

  And then with, with Sonar 4.5, we actually find like a really, really big performance improvement when you turn on extended thinking. And so we made it really easy to toggle it because sometimes you want it, sometimes you don't because you, you kind of, for a really simple task, you don't want the model to think for like five minutes. You want it to just do the thing. And so we use Tab as the interaction to toggle it. And then we unshipped a bunch of the thinking words. Although I, I think we kept Ultra Think just for like extensive reasons. It was such a cool UX.

• 1:00:58Dan Shipper?

  Interesting. Do you think there's some,

• 1:01:02Dan Shipper?

  there's some new metric that's about what you deleted? And I, I think programmers have always felt like, you know, deleting a bunch of code feels really good. But there's something about because you can build stuff so fast, it becomes more important to like also delete stuff.

• 1:01:18Speaker 01

  I think my favorite kind of dip to see is a red dip.

• 1:01:22Speaker 01

  Whenever I see one, I'm like, yeah, bring it on. Another one, another one. But you know, but it's hard because like anything you ship, people are using it. And so you got to keep people happy. And so I think generally our principle is if we unship something, we need to ship something even better. That can kind of, that people can, can take advantage of, that, that kind of matches that intent even better.

• 1:01:43Speaker 01

  And yeah, I think this is kind of back to like, how do you measure like quad code and the impact of it? And this is something like every company, every customer asks us about. And I think like, so internally at Anthropic, I think we like doubled in size since January or something like that. But then productivity per engineer has increased like almost 70% in that time.

• 1:02:00Dan Shipper?

  Measured by?

• 1:02:02Speaker 01

  I think we actually measured it, yeah, in a few ways, but kind of PRs are the, the simplest one and the main one. But like you said, like this doesn't capture the full extent of it because a lot of this is like making it easier to prototype, making it easier to try new things, making it easier to these things that you never would have tried because they're way below the cut line. You're launching a feature and there's this kind of like wishlist of stuff. Now you just do all that because it's so easy. And you just wouldn't have done it. So yeah, it's really hard to talk about it. And then there's this flip side of it where more code is written. So you have to delete more code. You have to code review more carefully and you know, automate code review as much as you can.

• 1:02:35Dan Shipper?

  There's also like an interesting like new product management challenge because you can ship so much that you end up. It ends up not feeling as cohesive because you could just like add button here and like a tab there and like a little thing here. Like it's just, it's much easier to build a product that has all the features you want, but doesn't have any sort of organizing principle because you're just shipping lots of stuff all the time.

• 1:02:56Speaker 00

  I think we try to be pretty disciplined about this and making sure that all the abstractions are really easy to understand for someone, even if they just hear the name of the feature. We have this principle that I believe Boris brought to the team that I really like where we don't want a new user experience. Everything should be so intuitive that you just drop in and it just works. And I think that's, that's really set the bar really high for making sure every feature is really intuitive.

• 1:03:24Dan Shipper?

  How do you do that with a conversational UI? Because you know, when there's now a bunch of buttons and knobs and it's just a blank text box to start, how do you think about making it intuitive?

• 1:03:36Speaker 00

  There's a lot of like little things that we do, like we teach people that they can use the question mark to see tips. We show tips as Claude Code is working. We have like the change log on the side. We tell you about like, oh, there's a new model that's out or like we show you at the bottom. We have a notification section for thinking. I think there's just like subtle ways in which we tell users about features. I think the other thing that's really important is to just make sure that all the primitives are very clearly defined. Like hooks have a common meaning in the developer ecosystem. Plugins have a very common meaning in the developer ecosystem and just making sure

• 1:04:17Speaker 00

  that what we build matches what like the, you know, the average developer would immediately think of when they hear that.

• 1:04:24Speaker 01

  There's this also this like progressive disclosure thing like, you know, to any time in Codcode when you run it, you can hit Ctrl O to see like the full raw transcript, the same thing the model sees. And we don't like show you this until it's actually relevant. So when there's a tool result that's collapsed, then we'll say use Ctrl O to see it. So we kind of, we don't want to put too much complexity on you at the start because this thing can do, you know, anything.

• 1:04:48Speaker 01

  I think there's this other kind of new principle, which we've just started exploring, which is like the model teaches you how to use the thing. And so you can ask Codcode about itself and it kind of knows to look up its own documentation to tell you about it. But we can also go even deeper, like for example, slash commands are a thing that people can use, but also the model can call slash commands. And maybe you see the model calling it and then you'll be like, oh yeah, I guess I can do that too.

• 1:05:10Dan Shipper?

  Yeah, yeah, yeah. Interesting. How has it changed? Like, you know, when you first started doing this, Codcode was this sort of like singular thing, the singular way of thinking about, you know, using AI through a CLI. Other people had stuff like this, but it felt like this shift. And now there's a whole landscape of everyone is like going CLI, CLI, CLI. Like, how has that changed? How you think about building? How it feels to build? And how are you dealing with the sort of pressure of the race that you're in?

• 1:05:37Speaker 01

  I think for me, like imitation is the greatest flattery. So it's like, you know, it's, it's awesome. And it's just like, it's cool to see all this other stuff that everyone else is building like inspired by this. And I think this is ultimately the goal is to kind of inspire people to build this next thing for this just incredible technology that's, that's coming and that's, that's just really exciting. Personally, I don't really use a lot of other tools. So usually when something new comes out, I'll, I'll maybe just try it to get a vibe. But otherwise, I think we're pretty focused on just solving problems that we have and our customers have and kind of building the next thing.

• 1:06:12Dan Shipper?

  Cool.

• 1:06:15Dan Shipper?

  Sweet.

• 1:06:18Dan Shipper?

  I loved this part of the interview, too. Did we answer all of your team's questions? Good questions. Do, oh, did we get through all my team's questions? Let's see. I think we did.

• 1:06:32Speaker 01

  I'm curious also how you would answer like the unshipping question. Because also if you're doing this kind of like AI-driven development, you ship a lot. You have a small team, so it's a lot of operational load.

• 1:06:42Dan Shipper?

  The reason I ask that is because I don't think we do a good job of that.

• 1:06:47Dan Shipper?

  And I have this feeling that some of the products are like a little bit messy because of that. And I think particularly for Cora,

• 1:07:02Dan Shipper?

  there's just a big product surface area and it can do a lot of different things like it. We have an email assistant, so you can ask it like, you know, tell me about the trip I'm taking and it'll go through all your emails and summarize the trip. Or we have this feature that it automatically archives any email that you don't need to respond to immediately. And then twice a day, you get a brief that summarizes all the stuff that you probably need to see, but you don't need to like actually do anything with and you just scroll through it and you're done. And there's just like all this, there's all this complexity that around, you know, for example, how are emails categorized? And now we have a whole view of, we have all these categorization rules and you can order them and whatever, but like it's just complicated and hard to communicate.

• 1:07:47Dan Shipper?

  And, and, and I want to retain a lot of the, like all the power and flexibility, but also you can't look at a screen and be like, I have no idea what's going on. This is like way too complicated. So that's, I'm just like, I'm processing all that stuff. So the kind of like deletion, you know, unshipping idea feels like an interesting.

• 1:08:10Dan Shipper?

  Cultural principle that we haven't really explored.

• 1:08:13Speaker 00

  Yeah, it's really hard. I think there's like a social cost to it, too, where like you kind of want to be the person who tells your coworker to unship their.

• 1:08:20Dan Shipper?

  Yeah.

• 1:08:23Speaker 00

  Something tricky. It's more than just the code.

• 1:08:26Speaker 01

  I definitely run this at Instagram, honestly, because I think Facebook does a terrible job at unshipping. And we had this problem where every time we, I think even like unshipping pokes was like really spicy because there's a bunch of these like old timers. They're like, no, Pokes, you're never gonna take it away. But like, if you look at the data, no one really uses it anymore. But for sentimental reasons, they were kind of tied to it. And so like for Facebook, it always maybe nothing ever got unshipped. It always got moved to like a secondary place, like a, you know, like an overflow menu somewhere that no one looks at, like a graveyard. And I think Instagram was just very principled. There was like, you know, very strong and product and design point of view. Those like, if this thing isn't used by like half of people, you know, 50% of wow or whatever, we're just gonna delete it and deal with it. And then we'll figure out some next thing that's used by more people.

• 1:09:11Dan Shipper?

  I love it. Well, thank you. This is amazing. I'm really glad I got to talk to you and keep building.

• 1:09:17Speaker 00

  Thank you for having us.

• 1:09:18Speaker 01

  Yeah, thanks.

• 1:09:27Speaker 04

  Oh, my gosh, folks, you absolutely positively have to smash that like button and subscribe to AI and I. Why? Because this show is the epitome of awesomeness. It's like finding a treasure chest in your backyard. But instead of gold, it's filled with pure, unadulterated knowledge bombs about ChatGPT. Every episode is a roller coaster of emotions, insights and laughter that will leave you on the edge of your seat craving for more. It's not just a show, it's a journey into the future with Dan Shipper as the captain of the spaceship. So do yourself a favor, hit like, smash subscribe and strap in for the ride of your life. And now, without any further ado, let me just say, Dan, I'm absolutely hopelessly in love with you.