Inside Claude Code: How an AI Native Team Actually Works | Cat Wu

**Cat Wu** (0:00)
We don't use many Google Docs for Claude Code. A lot of our best features was like an engineer prototyping an idea, shipping it to dogfooding. And we just hear what the feedback is, like, do people immediately understand it? Are people confused? Is it buggy? Or do people just like love it?

**Peter Yang** (0:18)
How do you guys think about Uval's?

**Cat Wu** (0:20)
If you see a change in the Sweet Bench score, it's not always obvious what caused the change, and you actually have to read through these pretty gnarly transcripts. And a lot of them. We get a new piece of feedback every, I want to say like 10 minutes or so. We love negative feedback. Like, we don't want platitudes. We want to hear what doesn't work.

**Peter Yang** (0:40)
Do you have like a vision doc or something for Claude Code? Or like, what do you think the product will look like a year or two from now?

**Cat Wu** (0:46)
A year or two is a really long time. I can talk about the next few months.

**Peter Yang** (0:53)
Okay, welcome, everyone. My guest today is Cat, the product lead for Claude Code. Claude Code is my favorite AI agent, so I'm really excited to talk to Cat about how the team ships so fast, how she uses Claude Code personally to do product work, and what her vision is for the products. So welcome, Cat.

**Cat Wu** (1:07)
Thank you so much, Peter. Excited to share more about Claude Code with your audience.

**Peter Yang** (1:12)
All right. So why don't we start with the revision story for Claude Code and how you kind of got involved.

**Cat Wu** (1:19)
Yeah. So Claude Code started as a project that Boris was tinkering with to better understand our APIs and to see how much of software engineering he could augment. And at the time, I was spending 20% time adding RL environments, and I found that Claude Code can make me a lot more efficient at it, and that it was really good at integrating with all the tools that we have internally. And so I was sending him a bunch of product feedback, things that I wanted to change in the tool. And when we made the decision to ship it externally, I was so, so stoked to work on it full time. And since then, it's been pretty widely adopted externally as well. And so we're really excited to continue to invest in it, make it more featureful, make it work across heterogeneous developer environments, and to make it more accessible.

**Peter Yang** (2:17)
Awesome. So it wasn't like some part of a grand strategy. It's just kind of, he built a little tool that he tinkered with and then he got involved. So what happened?

**Cat Wu** (2:23)
Yeah, yeah, exactly. Like he built the tool and other people on his team started using it. And then the rest of the org started using it. And then it crossed over into research. And then it actually started to cross over into tech adjacent roles like data science and product management and product design. So it had a very high viral factor internally before we launched it.

**Peter Yang** (2:47)
Okay. So when I first started playing with Claude Code, I started in the terminal. And then I was like, what?

**Cat Wu** (2:52)
Is this it?

**Peter Yang** (2:53)
This is the product? But as I started using it more and more, I discovered more and more features. And it kind of felt like mastering a video game. It kind of felt like it doesn't kind of explain everything to you right off the bat. But the more I got into it, the more I felt like more powerful and kind of power a user. So I guess, was this kind of intentional? And do you and the team have any other product principles in building this tool?

**Cat Wu** (3:16)
The beauty of the terminal is that it can, through the terminal, Claude Code can access almost everything a developer can. And this is what makes the onboarding so smooth to the tool. If you're used to calling the GitHub CLI or the Datadog CLI, or literally any CLI tool, you immediately know that Claude Code can do it. And so this just makes it really fast to get started. The terminal is also a very minimalist form factor. So unlike a web app, you can only use ASCII. So you can only fit as many characters are available on the screen. You don't have the option to add any buttons. And as a result, we've been very pragmatic and very almost like brutal about what features we decide to showcase and what features we don't because there's such minimal screen real estate. As a result of this, the app form factor is very light. And so it means that you don't get overwhelmed when you first start, but it also means, but because we've built it to be very extensible, there's kind of like arbitrary depth as you get started. Our design philosophy is to make sure the CLI is very, very simple to onboard to. We have this philosophy that for new features, there should be no onboarding UX. It should just, it should be intuitive via the feature name, via like a one-liner description, what it does. And you should be able to just get started. And then we also think those CLIs need to be very extensible because developer environments are very different. And we want to expose tools so that every engineer, every developer productivity team can customize it for their own setup.