LongCut logo

How Claude Code’s lead designer builds with AI

By Dive Club 🤿

Summary

Topics Covered

  • Worktrees unlock parallel AI coding sessions
  • Delegate the decision, not just the task
  • Everyone can ship doesn't mean everything should
  • Hand off everything around the code too
  • Design workflows for models that don't exist yet

Full Transcript

What I'm actually going to show today is what I would consider a pretty practical demo of some of the workflows that I think will help up level people who are using Claude code.

[clears throat] The way I like to describe it and in some of my experience so far in the industry, we're kind of operating in like these really compressed time horizons, but the way that we work at Anthropic because we

just have access and we're playing all the time and all day, it feels like we're like always looking for the next way to work and make ourselves more optimal. And so I'm going to show some

optimal. And so I'm going to show some of the things that have become really popular internally for how we work and hopefully this will all help you up level.

One thing I'll call out is that I am a CLI die hard. Like I've designed the CLI. Like Claude is in there. I think

CLI. Like Claude is in there. I think

it's just like like I used to design CLI products even before AI, so know that like this is not how you need to work that the desktop app is much more accessible and like you can do everything that I show today on the desktop app as well.

But um this is going to be on an open source repo. Does everyone know what

source repo. Does everyone know what Excalidraw is? Does anyone know what it

Excalidraw is? Does anyone know what it is? It's like a

is? It's like a Yeah.

Excellent product. Super great that they're open source. You can always contribute. If you actually want to

contribute. If you actually want to practice, they're really great one cuz they have a great backlog of issues and a pretty open community. First tip, if you don't know it, is that you should always be starting your work in a work tree. Does everyone do this or does

tree. Does everyone do this or does anyone know what this is?

All right. So work trees are pretty complicated and generally I don't think you need to know what they are, but all you need to know is that if you have a local source of your repository on your computer

and you want to run multiple Clauds at once, you might have run into the issue where your Clauds start conflicting with each other and you're doing one thing in one and another thing in another and they're overriding each other and they're competing, work trees keep makes

an isolated copy of your repository so that you can do multiple parallel tasks.

So if you find yourself having multiple windows open and doing multiple things at once or you see your engineers who have four or five Clauds open, know that they either have multiple copies of the repository on their laptop and they

might call it like repo one, repo two, repo three or or using work trees. And I recommend work trees cuz it's a little bit easier to manage. And to start it up, you just

to manage. And to start it up, you just do Claude {dash} {dash} worktree. And so

you can kind of see in the branch there, it's in a worktree and it already checked out a new branch for me. So, pro

tip number one, if you're multi-Clauding, use worktrees.

The second pro tip I'll give, I know not everyone has access to this, depending on your organization, so I just say like I am always in Opus 1 million contexts, just so you don't have

to think about it. And then I am always in fast mode.

Uh [laughter] yeah.

So, once again, I know it's not accessible to everyone.

And I am going to do this so that we can fast forward through the demo a little bit cuz I only have 15 minutes, but I do think that it does, you know, it does make a little bit of a difference. Okay,

and then I'm a big typewriter. Claude is actually really

typewriter. Claude is actually really good at getting typos if you type them, but uh I put this here so that y'all could see it.

This is a prompt that I'm just going to get Excalidraw to add a new autocomplete feature.

That's it. No design specs, no just like I want to add autocomplete, I want to see what it looks like. A few things I'm going to call out here that I think are important when you're prompting. The

first is I built myself a slash prototype skill.

I asked Claude to build this, you could build it in like 2 seconds. All it does is get Claude to generate uh n number of options, default to five, of a different implementation of a feature, generate an

HTML file, preview it, and then iterate on it a few times and I can enter that n and I can enter what the feature is going to be. Uh I did not write this. No

one ever writes their skills by hand anymore. If anyone tells you they do,

anymore. If anyone tells you they do, they're lying. Everyone just prompts

they're lying. Everyone just prompts them.

Um and then a few things I will add in here is I always ask Claude to pick an option for me first. I think it's actually fun to see what Claude comes up with. So, historically, I used to be

with. So, historically, I used to be like, oh, like prototype and then I'll choose. Now I'm like, oh, prototype and

choose. Now I'm like, oh, prototype and then you should choose what you're going to do and then tell me why.

And then I say another one is like feel free to research online. Now, if I were doing this in my production code base, I'd say like please look at Slack, Google Docs, any discussions, and like like BigQuery, like look at all these

sources and figure out which is the best one. But given that this is an

one. But given that this is an open-source repo, online research is fine. And then, you know, implement the

fine. And then, you know, implement the best option, verify, get the styles to match. Um really important one, put up a

match. Um really important one, put up a PR with a screenshot. Claude is actually really good at this, and I actually don't review the outputs anymore of Claude in the transcript. I'm typically

reviewing a PR that Claude put up that has a recording of the feature that implemented. And then a new feature that

implemented. And then a new feature that we released, I think a few months ago, is Loop. Does anyone Has anyone used

is Loop. Does anyone Has anyone used this before?

Loop is pretty much just cycle.

Keep going. So, loop until you're done just means keep going at this until it's fully done.

And so I'll I'll show some more applications of Loop in the future, but it's like a pretty standard prompt. If

an engineer asked me to like build something, I would this is like Well, to be honest, they would probably do this on their own without me and then send me a five-coded prototype. But if I was doing it from the ground up, this is how

I would do it.

Oh, the other pro tip that I forgot to mention, I'm always and everyone at Anthropic is always in auto mode. So,

auto mode is our kind of workaround for lower permission modes. We have a classifier that will

modes. We have a classifier that will detect whether or not a risky action is being taken on your computer. So, you

don't have to be sitting there being like, "Yes, I accept. Yes, yes, yes, yes." So, you should be using it in this

yes." So, you should be using it in this way, and it'll go a lot faster.

Now, I've done a lot of these demos before, and Claude takes a long time to work. So, typically, if I were doing

work. So, typically, if I were doing this, I'd actually spin up a bunch of these, but because we're here and I'm trying to showcase a workflow tonight, I'm actually going to show a few other things I do on the side while Claude is working.

But um I think these are a few tenants that I hold true as I'm working today, and they're going to kind of inform some of the workflows that I'm going to show all of you today.

So, the first is that Claude, tragically, and most LLMs are not good at design yet. So, what this means is that you should still very much be in the loop for the craft and the decision-making. It doesn't mean this is

decision-making. It doesn't mean this is going to be holding true forever, but a lot of my workflows revolve around the idea that I still need to be the one making a decision about what actually goes into the product.

Perfect. So, you can see here, sorry, this is going to be a little back and forth, that Claude has used my prototype skill to list a bunch of different options of what tabs to complete could look like. And so, it's showing all the

look like. And so, it's showing all the different ways. I'll typically like

different ways. I'll typically like preview, sometimes I'll play around with it.

Um Sometimes Claude asks me for one. Does

anyone have a preference on one that they like?

[snorts] Two.

All right, I'm going to go two.

That's it. All right. Um the second is that I actually, yes, coding is automated, but I hand off so much of my work that is not coding to Claude. And

if you're not doing that, then you're actually not using Claude in the most, I think, like automated way. You We really need to start thinking about more than just code when we think about AI automation.

And then the third one, which I don't think is controversial for this room, but has definitely been one that has been an uphill battle a lot of places, is just because everyone can ship doesn't mean not everything should ship.

And that's a pretty important distinction that we need to start making as we're adding more features and as everyone has the ability to access code and like push to production, we need better systems that scale.

And so, some ways that we're fighting this internally today is I actually use Claude in the web. Does everyone have this internally at their teams or companies?

Uh you might have it with your own internal infrastructure, but I have like Claude in the cloud or Claude in the web is a service that we offer and I use it as a way to send like hundreds of tiny

little polish fixes all the time that I find in the app. They're not worth spinning up a new session for, they're not worth dedicated time. I just have all of these going and I would say, uh sometimes I get complaints from the engineers that there's too many of them.

So, every now and then I'll ask Claude to squash them all into one PR for me.

And sometimes they just got auto approved because they're tiny CSS changes and no one really needs to review them. So, I would say like this

review them. So, I would say like this is a really great way to maintain crafting quality in your products and it's something that you can do on the side as Claude is working.

A second one is that almost everyone at Anthropic actually always has Claude's running and always has Claude's running to help merge PRs. So, one thing that I never do anymore actually is once an idea is done, I'm never actually in CI.

I'm never reviewing like like until merge. I'm never like addressing code

merge. I'm never like addressing code review comments and stuff like that.

It's actually all fully automated now.

And so, there's two tricks that I did to do with that. The first is All right, perfect. So, now you can see I asked

perfect. So, now you can see I asked Claude to verify.

So, Claude is opening Chrome right now and it's going to test that it's working, but I'm just going to We can watch it if you want. If you guys have the Claude in Chrome, I would highly recommend using it cuz if you're doing front end changes, it's actually the

best way to have Claude be able to self-verify.

And you can see the ADHD we all way we all work right now where we're like doing one thing and then Claude pops in and is doing another thing.

Uh but I'm just going to let that go.

Uh these are the commands. The first one I do actually before when I make big code changes is just a really good way to like do a little bit of a hygiene check.

Uh simplify and code review are internal to our repository, but I guarantee you if your engineering team is using AI, they have an equivalent of that that kind of prunes your code base. So, ask

your engineering partners like how do like what skills do you guys have to simplify your PRs and then they'll be able to put them up. And then this commit push PR is one that runs a bunch of checks that we have internally as well. So, these are all ones that our

well. So, these are all ones that our team has built. Some of them are available externally, but I also like know that all your engineering teams have dev prod teams that have built these and you should be using them.

Uh and then the second one is one that almost everyone engineering non-engineering has at Anthropic. This

is built into skill, but I wrote out the full command that we used to use, which is just to review any open PRs and just get them over the finish line. And the

somewhat annoying thing, but really great thing that we have is cuz it's connected to Slack, it will DM people if they are on your code review as well, or it'll DM the stamp channel and ping

who's on call. So, the full integration of your suite is where it's at.

Uh and then the last one, which I think has been the most game-changing for me personally as our product suite has grown, is actually I have a Claude code routine, which is a scheduled task if

you use uh Claude code work. And what

this does is it scrapes all of our repositories for any front-end changes that anyone has implemented.

It will check if a designer was involved in it by going through Slack, Google Meet transcripts, like uh Google Docs, like any kind of data that it has access to. If a designer was not involved in

to. If a designer was not involved in it, it will flag that it shipped without a designer or not.

[laughter] If it shipped without a designer, it will come up with an adversarial or it'll review the design and then it will typically come up with an adversarial

design in a PR already drafted, DM it to the engineer who shipped that feature, and then ask them to work with the designer

on that feature.

I tested this a few times and I had to turn off the DMing cuz Claude was actually really bad at design, unfortunately. And I We did have to like

unfortunately. And I We did have to like it's And like that goes back to my first one, like Claude is not good at design yet, but I think this is the level of automation that you have to be thinking, like not just the first step, but like the next step, the next step, the next step after that. Like you want to be

pushing it so far that it's like building the actual end product. And I

think we have a lot of forgiveness right now in the industry because we're all testing how these workflows work. So, uh

people were very forgiving when I first tried this and it was really bad. And

now I just consume this myself, but uh I'm always ready for when the next model's going to come out and this is actually going to be ready and available because I have it all written up. So,

when we're testing the next one, I'll just throw that up, get it, see if it'll work, and it typically gets better.

Yeah. And so, these are the three tips if I could like really impress on you of like workflows that we're using that have really like just augmented how the team works. These are the three things I

team works. These are the three things I demoed today. And then, if we go back to

demoed today. And then, if we go back to the session, you can see that Claude is now recording a screenshot from Claude in

Chrome here. Uh, it does it through a

Chrome here. Uh, it does it through a series of GIFs. It's going to post it up, and then it's going to open the PR.

Yeah, but that's it for my demo.

Hopefully, this is helpful, and hopefully, this helps you guys all use Claude code.

Loading...

Loading video analysis...