Name: Claude Code Advanced Patterns: Subagents, MCP, and Scaling to Real Codebases
Uploaded: 2026-03-24T18:32:14.376Z
Duration: 59 min 22 s
Description: Claude Code Advanced Patterns: Subagents, MCP, and Scaling to Real Codebases

Transcript for "Claude Code Advanced Patterns: Subagents, MCP, and Scaling to Real Codebases": Hello. Welcome to a record breaking webinar. We have people from all over the world. Look at how many countries we have represented here. Add your emojis so that we can count them up. We are, really, really excited to bring you advanced patterns with Claude Code. I am honored to be here with Alon and Lizzie from our Applied AI team. And we're gonna do just a little bit of housekeeping here, to begin. And, this is recorded, so, it will be distributed within twenty four hours to everyone who has registered. You can watch it as many times as you want. I'm sure you'll wanna watch it at least a 100 more times. It's gonna be that good. This is live. We'll have live demos. Everything is live. You can ask questions live, and we will try and answer questions as we go. And we'll also save time at the end for questions. I'm sure there will be a lot, that come up as as we proceed through. And we are very, very interested in your feedback. Tell us how we're doing. Rate the webinar. Let us know what what we could be doing better. That would be super, super helpful for all of us. And we're gonna kick things off with a poll. So tell us how your team is currently using Claude Code. And we'll continue. It's funny to see all the emojis just keeping on. It's like a slot machine over here. Alon and Lizzie, do you want to introduce yourselves and tell us a little bit about you? Yeah. Absolutely. I'll go ahead and kick off. So excited to be here, team. My name is Lizzie and I'm on the applied AI team supporting state and local governments. Really excited to be leading us through the slides and demo today. And And then, Alon, I'll pass to you next. Thanks, Lizzie. My name is Alon Krifcher. I am one of the Applied AI architects also here at Anthropic. I support our strategic tech and digitally native business unit customers. Liz and I are both based in New York City, and we're both really happy to be here. And I am joining from San Francisco. I'm Kacie, and I lead marketing for Claude Code here at Anthropic. Awesome. Let's check out our poll results. Wow. Okay. Got a lot of experimenters. Looks like we have all kinds, all all stages. This is great. We're gonna really get into it. So we all take notes. And I'm gonna hand it off to Lizzie to get started. Awesome. Great. Well, let's go ahead and kick off with what I'm hoping folks come out of this session having learned. First up, I'm hoping that you'll learn a little bit more about controlling Claude's behavior with CLAUDE.md and Hooks. And if you're anything like me and you're sort of staring at Claude as it tinkers and and moves through your code base, let's learn a little bit more about paralyzing Claude to get the most out of your sessions as well. We're gonna end our slide section with embedding Claude code across your SDLC from feature research to CICD, and then zooming out a little bit, hoping that we'll form a mental model together and when tool creation is actually worth the cycles for your team. Leaving this webinar, I'm hoping that you're able to imagine and start thinking about what an advanced Claude Code implementation could look like for your organization. So without further ado, let's go ahead and jump in. Let's start by discussing how to customize Claude Code for your code base and your team's unique needs. As many of you know, the first step towards customizing Claude Code is setting up a CLAUDE.md file. A CLAUDE.md file is a markdown file that Claude reads automatically whenever you start a new session. You can think of this as Claude's instruction manual for navigating your code base and making effective high context changes. Without one, right, Claude is using general best practices, but they're not necessarily your best practices. You can think of it as trying to put some IKEA furniture together without an instruction manual. You can do it because Claude has a good idea of, you know, what a dresser looks like. But we really want the precise instruction manual to actually guide Claude to the best possible outcome. If you don't actually have one yet, it's super low lift and I recommend setting one up as soon as you can. Just start your next session with slash init and Claude will scan your code base and draft one for you and you can edit it from there. Alright. Great. So for those of you, though, who are are already Claude power users, you might be at the point where you're wondering, okay. Well, what happens when my code base, like, is just too big for one single file? And that's really where nested CLAUDE.md files come into play. We recommend using your root CLAUDE.md files, so in this case, monorepo/CLAUDE.md slash Claude dot m d for any context that applies more generally to your entire code base. And then keeping module specific or topic specific guidance in nested collab MD files within a sub module, for example. Importantly, right, Claude is gonna walk up your directory tree from wherever you start your session. So in this case, if you start your session in test cases, Claude is gonna walk up the directory to then understand the CLAUDE.md in packages as well as the CLAUDE.md in mono repo. The inverse is also true. So Claude is also gonna walk down your directory to discover CLAUDE.md files in sub modules or packages. But, importantly, there's an important difference here that Claude is only gonna access those CLAUDE.md files when it's relevant, when it's actually editing files within those sub modules or packages. The goal here just to build your mental model a little bit more is to provide Claude with enough context to work efficiently and to navigate, but not overload the context window with information that ideally is just retrieved just in time. And the reason why we really recommend this strategy and why it works for us too, right, is that it can actually boost instruction adherence. We want collage to be focused on exactly what you're the tasks that you're working on in that moment. And it can also limit unnecessary costs. So stuffing a ton of context when it's actually not super necessary for your particular task, is actually gonna burn unnecessary tokens and and maybe even slow you down a little bit. This actually makes CLAUDE.md files easier to maintain as well. So you could imagine, like, the UI team is gonna work only on their CLAUDE.md file for their specific set of packages, the API client team as well. Great. Let's wrap this section up with CLAUDE.md best practices. If you were to take like nothing else from this section, what I'd really recommend that you think about is just keeping your CLAUDE.md files really concise. We recommend keeping them, you know, under 200 lines or so. For each line, a good mental model is, you know, I'd ask yourself, would removing this line actually cause Claude to make mistakes? And if not, I'd consider cutting it. The reason being, like, really bloated CLAUDE.md files can actually cause Claude to ignore your instructions or wait instructions that are actually imprinted to you less heavily. Even so, if you notice that your files are still starting to get pretty unwieldy, we'd recommend creating a Claude rules directory where you can break things up into multiple files by topic. And you can actually scope these, to paths with front matter, which is super helpful. So a good example might be for all of your Python linting roles. Those only load for dot py files, for example. So when I'm writing TypeScript, they're not relevant and they're not loaded into context. One last piece of advice here, especially in monorepo environments, you sort of run the risk of picking up CLAUDE.md files that aren't super relevant to your team as Claude walks up the directory tree. CLAUDE.md excludes is a setting that can be used to exclude files matching certain glob patterns. So for example, if I'm working on a Grimfield project for which I don't need to, you know, log anything quite yet, I might actually ignore the platform team's logging rules just so that I can sort of get through my project without having to apply a bunch of logging rules that don't necessarily apply yet. One important caveat for all of the admins on the line, if your admin has pushed a managed policy CLAUDE.md, you can exclude that. So rest assured that will still be in context. Great. So now that we've talked a little bit more about controlling Claude's behavior with CLAUDE.md files, let's move on to introducing determinism to your Claude Code workflows. So hooks are shell commands that run at really specific points in Claude's life cycle and hooks are purposefully deterministic. So a good example might be, let's say I put into my prompt always run prettier after editing this file. And in a prompt, Claude is going to do that most of the time. Right? But a post tool use hook that runs Prettier every single time, no exceptions, is really where the value is for hooks. To give you a sense of some of the other, like, life cycle events that you can plug into here, you can use pre tool use, such as what we just talked about, post tool use, notifications, and many, many more. And folks are great at utilizing hooks. There's so many good examples out there and in our docs. But a few quick hit examples, notifications, you can customize how you get notified. So a good example might be, you know, sometimes, Claude is working on a long running task, and I've tabbed away to, you know, six tabs deep in another window. I might actually create a hook such that whenever Claude is done with the task, I actually get notified. Another good example is automatic formatting, logging, tool calls, for example, and on the more aggressive side, actually correcting Claude's behavior. So, for example, always writing tests for certain packages before committing. Would really recommend that you utilize hooks, and we're gonna talk a little bit more about how they compare to other types of behaviors like tool use next. Moving right along to tool use, MCP, as many of you know, stands for model contact protocol. It's the standard way to give Claude access to external systems outside of Claude's execution environment. The comparison we often use internally and what, like, really made it click for me when I started working on MCP is that MCP is like a USBC plug. So just like you would plug that into any computer in order to connect information into it or another system into it, MCP is like one plug to connect to any service on the other end. There's a huge and growing ecosystem of MCP servers and prebuilt servers, And you can add them with Claude MCP add server name and maintain them with /mcp. Importantly, MCP has three separate scopes. So local for just you on this project, project scope which lives in mcp.json and gets checked into git, so you'd share that with your entire team. And then user scope for personal tools that you want to follow you around to separate projects. A quick note on what MCP tools might not be for, and of course there's always an exception to the rule. I'm curious Alon's take on this as well. But generally speaking, you don't need to build a custom tool to wrap a CLI. CLIs actually allow you to allow Claude to to run, for example, Bash. You can call GitHub CLI directly and are actually really context efficient way to get things done. It's not really worth it to build a custom tool to wrap CLIs that Claude can already call with Bash. Another thing which we just talked about is deterministic tasks that Claude really doesn't need to reason about. So for example, running Prettier or linting, that should just always fire and and probably belongs in a hook. And then user triggered scripts such as logging, for example, probably belong in a hook or a slash command. I think the mental model that really helped to click for me is that MCPs are for when Claude needs to reason over external state, not in its execution environment, like fetching Figma designs or creating tickets without relying on copy paste. If you find yourself, you know, dragging the same file or same context into Claude more than once or twice, it's probably time to think about connecting some MCP tools. Alright. Let's go ahead and bring this section home. So let's let's compare these. Let's think about when to use each feature, CLAUDE.md, MD, Hooks, and MCP. And one thing I'll just flag, I was talking about this with Alon a little bit earlier. Sometimes the lines here are intentionally a little bit blurry and take a little bit of trying just to see what works for you and your particular task. So with that in mind, here are some of the mental models to guide when you reach for each one. I like to think of CLAUDE.md as memory. So there's static facts about your project that Claude couldn't learn just by reading code. This is for helping Claude navigate through your repo and make good high context decisions. Hooks I like to think of as reflexes reacting to particular events. And then MCP is like Claude's eyes and ears and hands, live access to read and influence external state. Okay, great. Before we head over to the next section, is on paralyzing Claude, I'm wondering alone or Kacie if there are some good questions that have come up that we should try to answer. A lot of questions about the slide deck, which we can absolutely share, so I just wanna address that quickly. And then a lot of questions about having Claude like, asking Claude to help write, your CLAUDE.md file Yeah. at one. So so there are a couple of questions that I I think I specifically want to cover just because I saw thematically, a lot of people asking. There are lots of questions about, kinda CLAUDE.md, agents.md. Clearly, a lot of of users of other agentic tools in the house, which is great. Oftentimes, like, you could think of them somewhat similarly. Right? Like, there there is a lot of similarity between, like, a CLAUDE.md, agents.md, rules.md. Right? Like, these are all kind of mark down files designated to, specifically accomplish certain tasks based on the type of platform or tool that you're using. One of the things that we often see is that, with customers or users who are, using kind of multiple tools, how do you kind of think, holistically about all of them together? Well, the best way is to ask Claude about it. So you can ask Claude to kind of summarize an agents.md or rules.md into its CLAUDE.md. And these can be checked into your, centralized repositories, and systems to be able to either share them across, across different people or across different teams, as well as make sure that there is kind of state change on them, when you're when you're working through updating kind of your systems, your rules, your processes, etcetera. I think this also leads to, another kind of thematic question we're seeing, which is around, how to kinda make sure that you are building the best CLAUDE.md file. And, again, the answer is is simply has Claude to do it. What Claude will essentially do is it will review your code base or the specific repository or subdirectory that you're in. It will understand kinda based on the the code itself and what you're building, what is important there. It gives you a really good kind of foundational starting point for what should be in your CLAUDE.md that then allows you to think about what do I wanna add from a customization perspective. What do kinda only I know in my brain that I want to tell Claude that would be impossible to understand by just looking through my code base or looking through, what I'm building. So that's kind of that really strong kind of foundational place, where you can, use kind of Claude to help summarize and create that first pass at a Claude. Md as well as take information you already have built out into a, a rules file or an agent's file, to ensure that it is completely compatible with Claude Code. The last question I think I'll answer here, which has just gotten a lot of upvotes here. So thank you, Prasian, for for asking. Are you moving away from MCPs? Absolutely not. MCPs are are something, obviously, that we built, and are really excited about, not just kind of when we built it and now, but into the future. There are always going to be different scenarios where MCPs are gonna be valuable or a CLI tool might make the most sense, but MCP is still fundamentally the core way that these models interact with databases, systems, and other, API libraries. And so we are by no means moving away from MCP. We're actually continuing to invest in it both as we've kind of, donated it out and are continuing to invest, funds to supporting MCP as an open source system and and project. And we're really excited to keep seeing how MCP is going to continue to evolve as, software engineering evolves. Pass it back to you, Lizzie, for the next section. Awesome, Milan. Thanks for answering. Great. So now we're gonna get into a section on parallelizing Claude, which honestly might be my favorite out of these. And thanks everyone again for the for the great questions. Please keep them coming. So let's talk about how to get the most out of your Claude Code sessions with parallelization. If you're anything like me and when you first started utilizing Claude Code, you kind of wanted to watch its every move, both to make sure that it was doing the right things, but also it's pretty amazing just to to watch Claude seamlessly move throughout your code base. But as you, you know, accelerate in your development and your partnership with Claude Code, you might find yourself, you know, just wasting a level of time waiting for Claude to finish tinkering or sauteing or whatever the fun word has presented to you is. Sorry. Okay. Great. So let's start out with the simplest version of parallelism. So first, just opening up more terminals and launching Claude in a new terminal. In this case, each session has its own context and doesn't know about other sessions. This is the human orchestrated version of parallelism where you're in charge and you're routing Claude throughout your code base. For this reason, you know, we'd recommend thinking about this as being really independent tasks touching totally different files. But if you do want two Claudes, you know, to touch the same files at once, at least slightly, we'd recommend utilizing Git Worktrees. Claude -- work tree gives each instance its own isolated working directory off of the same repo, which can help, you know, to keep Claude's who are unaware of each other from clobbering and and, you know, just in time writing over particular changes. We use parallel Claude a ton internally for multi part features where the pieces again are pretty independent to make the most of our time while Claude is is tinkering and working away. Let's complicate this a little bit with subagents. So if you're working on a single task, so rather than a bunch of independent tasks that touch different files, but instead a single task that can be broken up into sub tasks. So maybe, you need some research done. You need to write some tests. You need to plan. Subagents might help you get the most out of your Claude session without overloading your context window. subagents. I'd like to think of as assistants, and they run-in their own context window with their own system prompt, tool access, and permissions. So one mental model is that your main Claude session is like a generalist, and then subagents are specialists running out, on an errand just to return the most relevant information to your generalist. So you know where to find them. Subagents live as markdown files in Claude agents. And you'll notice even without configuring anything that Claude Code right now has access to built in agents. So one that you'll see in the demo is explorer, for example, for researching your code base within your code base. In terms of configuration, so like Alon was nudging people earlier, we try to build in a lot of opportunities to use Claude to build new primitives for Claude. And so you can use slash agents to actually configure an agent or subagent rather, and then work with it from there. Alright. Moving up the complexity chain, let's talk about agent teams. So if Subagents are specialists that report back to one session, you should think of agent teams as multiple full Claude Code sessions all working as peers. My friend, Kacie, internally came up with a metaphor that I really like, which is thinking about this as a chef, right, that delegates to sous chefs. And all of those sous chefs are working on separate but related tasks that might need to come together at the end. So you can imagine one sous chef is chopping onions, another sous chef is chopping carrots, and then the last one needs to, you know, put them in a pot pie or something. They ultimately need to coordinate, but they can make progress on their own with guidance from a head chef. Importantly, this is important to remember, each has its own persistent context window. So it's really helpful to utilize agent teams for something that maybe a single context window just couldn't handle. And they actually communicate with each other, splitting up the work and syncing progress. So you no longer have to be sort of the router, although, of course, you can interrupt their work at any time and provide guidance and so on. The big difference between subagents and agent teams that I think made it click for me is that subagents live inside your single session and report back once. Whereas team agents like sous chefs, right, run alongside each other and coordinate with each other over time. And the ideal use case again to to think about for agent teams, and again, you know, are blurry lines. We'll we'll see what works best for you, is work that you can clearly separate into independent chunks, but still requires some level of coordination. So maybe some good examples to throw out there would be, like, a multi service refactor or a migration that touches five packages, both front end and back end. And then each agent owns a piece, and then they check-in with each other without requiring direct coordination from you. Great. So let's bring this all together again, and then we'll pause for questions. Really curious sort of what what came up for you all. And then we also have a fun poll about, you know, which one you're the most excited to try. So really excited to see sort of what this has peaked for you all. So again, parallel Claude, best for unrelated tasks. You are the router. You are controlling, you know, which Claudes are working on which files and they don't know about each other. So you might want to utilize Git Worktrees for that and then merge everything at the end. Subagents alternatively are best for delegation within a single task. So the main session is still in charge, but it spawns this focused helper that's just returning the main session back a result. And then agent teams we should think about for a more complex set of tasks requiring independent work, but then coordination on a shared goal. Again, the lines here are blurry, hoping that the demo sort of illustrates when each one comes into play. Great before I move on why don't we go ahead and talk through some new questions while folks finish on the poll. Yeah. Lots of really great questions about agents and and parallel clotting, agent teams. Really keep them coming. This is this is really great, guys. I think that, like, there there are, again, a few themes that are probably worth touching on. So a lot of people are kind of, somewhat new to, like, TMux and and how to think about kind of split panes. Right? This is available across Linux, across Mac. We've used them internally. Lots basically, all of our engineers here at Anthropic are using TMux in some form or fashion as well as some combination of, like, Git Worktrees and and thinking about, how to kind of do this parallel work. This is the kind of thing where, Worktrees does a lot of that work in in ensuring that there aren't going to be kinda like these merge conflicts to make sure that you're not kind of overriding or there's going to be issues with the type of content that you're, building or or updating in your code. So that's definitely something that I think is is, like, a highlight to, to to try out if you haven't already. In terms of, like, agents and subagents, there were a few questions on how to know how does Claude know which agent to to call on, and as, like, a generalist and then kind of, pushing down to kind of the subagents. That's where, like, when you build out your subagents. in Claude Code specifically, you'll have, like, front matter essentially on the on the Subagents where it will be a a clear explanation of what the goal of the subagent is, and you can call them different names, etcetera. And Claude will be able to read those through and know based on the kind of task that, you are are working on, which Subagents that you wanna delegate some work to. And so you can either be explicit and say, hey. I want you to delegate to x subagent. But the vast majority of the time, Claude knows exactly which subagents to delegate to based on kind of how you've built out the agents in the first place. And so you can treat Claude kind of as that main orchestrator and allow it to, choose and delegate. Okay. Cool. I'm gonna pull out my review subagent agent or I'm gonna pull out my kinda security test or subagent just as some examples. Yeah. So, again, keep these questions coming. These are awesome. We'd like to see love to see the, the results of this poll. Interesting. Alright. Agent team's winning basically in a landslide. Wow. Okay. Great. I'm glad that's in the demo. So we'll get to play around with that together in a little bit. We are getting a lot of questions. I just wanna say that we're gonna collect these, and then we'll do our best to answer what's coming up most often, then work with our team to create more content that we'll address some of the Good idea. Awesome. Great. Let's move into our last section here before we get into the demo. Great. So embedding Claude. Let's talk about, embedding Claude into your CICD. So the first step here might be to introduce Claude Code in GitHub actions. Claude Code in GitHub actions let you lets you plug Claude directly into your deployment as a workflow step, and it's bringing all of Claude intelligence and all of your best practices, so those CLAUDE.md's, Claude roles that you've worked so hard on into one of the most critical steps of the SDLC. And all of this again runs on the agent SDK. So it's that same agent loop that we've been talking about using locally just headless in CI. So everything that you know about Claude Code still applies here. In terms of how to use it, how I most often find myself using it is actually tagging Claude in to fix issues, just typing @claude into that issue, reviewing PRs, or even triggering automatically on a GitHub action. So you can think of this as, like, the same agent operating in a different environment and then helping you save time on reviews, identify hard to find bugs, and just generally making sure that your PR matches your organization's bar because all of those best practices, right, should be in those CLAUDE.md files. Great. Let's talk about code review. So code review builds on this concept and is in research preview. Really excited to get more of you using this. It's a review system that leverages that same agent team concept that we just talked about from a few slides back. So when a PR opens, a team of specialized reviewers spins up with context on your entire code base. So we can actually identify issues that might have affected other parts of your code base that a diff only review would probably miss. Right? And importantly, those those reviews actually scale with the size of the PR. So if I'm just sending, you know, a few line change, Claude isn't gonna go crazy in scanning through my entire code base. But if I'm doing a huge migration or a huge launch, you're gonna get a lot more attention and a thorough read. Even just to give you sort of a sense of how this has affected us internally, code output per Anthropic engineer, the stat was crazy when I first read it, has grown over 200% in the last year. And manual code review, you can imagine, started to really slow people down and become a bottleneck. And now we run code review on almost every PR at Anthropic. The change that that ultimately ended up creating was before about 16% of PRs got meaningful comments and review, and now 54% do, which has really allowed us to just ship more often and with confidence. And it's a more thorough review. I will say, just on the other hand, that that does mean that it's a little bit more token consumptive than just Claude Code and GitHub actions. It'd be a little bit more choosy in when you're utilizing code review. That being said, it's it's super worth considering for really significant changes. So, for example, really critical parts of your code base or teams who are super strapped for reviews right now and just can't can't meet the the rate of shipping that you'd like them to. Awesome. That was my last section before we hop into a live demo. Alon and Kacie, I'll take the queue from you on if you think that we wanna answer a few more questions before we hop in here or just jump right in. I think let's jump right in. Awesome. Let's do it. Great. So the demo that I prepared for today, imagine, for example, that I'm an engineering manager at an issue tracking software company. And like every EM, right, I have three things to do at once. I'm sure many of you can relate to this. Here are those three things. One of them is adding a mention feature to our ticketing tool. Another one is deciding on priorities and assigning tickets for Alon for our next sprint. He's really gonna have his handful because we have a good amount of of user research to go through as well. And then finally, through an initial code review for a major addition on audit logging. Just so you guys have a better sense, I'm gonna go ahead and stop sharing slides. I wanna give you guys a little bit of a better sense of what I'm working with in the tool. And then from there, we'll move on to my terminals. Okay. Great. So here's TrackLine, this issue tracking tool. And like I mentioned, right, this is what those at mentions look like right now. If I at Alon to take a look, you know, nothing really happens. There's no notifications. So that's what I'm gonna try to take on. On the other hand, in order to actually order Alon work for next week, I had my user researchers go out and interview a bunch of different customers. And now I have all of this great, but really unstructured feedback to go through and diff with those tickets in TrackLine before I know what alone should actually take on. And then finally, here's this huge PR that I have to actually go through in order to make sure that audit logging to ticket mutations doesn't break anything else in our code base. So many of you might recognize a few of these tasks and know just how long they actually take. So let's hop into Claude Code and see if Claude Code can help us figure this out. Okay. Great. So before I type anything, I just wanna orient you a little bit to how this repo is set up. You'll notice this is the root CLAUDE.md here. It's it's actually pretty short unintentionally so. It's a directory with some broadly applicable best practices, and then it points to really specific per package files for more details. So you'll notice, for example, notifications has this on CLAUDE.md, so does the MCP section as well. This matters because TrackLine is formatted as a mono repo. If I stuffed, like, every single convention into one file, Claude would be reading Python linting rules while I'm working on TypeScript. And instead, with this model, right, it's getting that just in time context and then any stylistic hints that I don't want to repeat myself on. Great. So let's start on that at mentions feature. The first thing I want to do whenever I'm starting on a new feature is just understand what's already there, and Anthropic's Claude is great at that. So let's ask Claude to do a little bit of research for me on the notification system before I write a line of code. In this case, I'm explicitly asking for an explore agent and or subagent rather. And the reason why is because the research output I just know is gonna be huge. If it lands all in my main session, I'm just gonna burn context on grep results. I'm, like, truly never gonna look at it again. And so the subagent is going out, doing that homework, and then I'm gonna get the summary. Something that I I noticed recently that, like, truly blew my mind is this by by the way, b t w slash command. It allows me to have, like, a quick aside with Claude without interrupting its work. So I'm just gonna say, what are the available subagents. And I'll make this a little bit bigger so we can see it as well. Okay. Great. So I know many of you are asking, you know, what what are the subagents that are available? Here are the ones that I have loaded up. Explore and plan are in general purpose are some of ones built in. And then test author is gonna help us, out a little bit later writing some tests. So I'll go ahead and hit enter and just let Claude keep cooking here. And this might take a minute. So like I mentioned earlier, let's go ahead and parallelize Claude on a really independent task with my terminal up on the right hand side. Great. So this is a really, really different task, from what I'm working on in the future work up there. Again, if you remember, I need to spend some time wrapping my head around what Alon is gonna do next week. And I have all of those tickets in TrackLine that I wanna pull in with the Google Drive MCP. And then I have all of those, or rather pull in with the TrackLine MCP, and then I have all of that user research that I wanna pull in with Google Drive. So I'm gonna kick off all of those agents, and then we'll see that they'll start to work here. Great. So now it's gonna start working on the MCP side. While that's cooking along, let's go ahead and head over to our feature work here and see what it was outputted. Okay. Great. So I see that Claude found the notification funnel. I have a little bit of information about the notification type values, which is great. Looks like those exist already. Mention exists, but nothing creates it yet. That must be the reason why we're working on this today. Okay. Great. Awesome. And then it found the modern service, which is great. Looks like there's a deprecated service that I should avoid. So all of that is great to know. I'm gonna go ahead and provide Claude a little bit more guidance and then send it on its way. So here, I'm just reaffirming. Great. Glad you found the modern notification service pattern. Go ahead and implement, parcel of these username tokens, and then here's a little bit of a design net to make sure that it ends up with something that aligns with what I'm imagining. Great. I'll go go ahead and, kick that off there. And you'll see that it's actually calling the TrackLine MCP, which is a custom MCP server for our internal service in order to get the latest information on that ticket, which is great. I see that it's spinning up another explore agent to make sure that it understands which files it needs to modify. So again, protecting my context window and keeping the main session context really, really tight. Let's go ahead and see what's going on in my other pane here. Great. So it looks like the agent has outputted a bunch of the track line tickets. So it has that context, which is awesome. All three agents have all set up. And now it's gonna apply some changes to my MCP server, which is great. So let's go ahead and approve some of those, setting up ticket keys for that MCP server, leveraging the m c p or rather the CLAUDE.md file that exists for the MCP server directory, and then it's gonna run some type checks to get us going. Okay. Great. Just gonna check for errors in solely the change files to make sure that we're all set. Okay. Great. And I see that there is a proposed work list for a Alon, which is awesome. I'm gonna go ahead and think about that in the background and move over to my mention section again. It's hard when Claude is so fast that that it's actually moving faster than me, but this is genuinely how I prefer working. It's kind of how my brain works, like a little bit of tasks over here, a few tasks over there. So, I like that Claude is sort of matching my style there. Awesome. So I see that it has the full plan. We're gonna set up parse mentions, comment service, comment body, and then page. That's just TSX. Okay. Great. Let's go ahead and start making some edits here. Alright. Great. That looks good to me. That seems reasonable. Okay. Great. And now we're gonna update the ticket page, which is probably hopefully applying some of my stylistic nets and then verify the build actually compiles. While that compiles, let's go ahead and see the proposed work list for Alon. So clearly, thinks that Alon is a very competent engineer, which is very true. But it wants to, you know, assign him a few different items. One through three, four to five are scope fixes, six. All of that looks good. You know, I agree with Claude. I think that alone can get through all six in one week. Okay. Great. So let's go ahead and reconnect at this point to our MCP server. You'll notice that it's this TrackLine MCP server up here on the right. And the reason why I'm reconnecting is because I want Claude to have a chance to pick up that new tool that it created. So I'm gonna reconnect here, and then I can even go into the MCP server again and just make sure that there are actually three tools. Okay. Great. That looks good to me. Okay. Go ahead. That looks right to me. Okay. Great. Awesome. And it looks like Claude has cooked here, made these changes, and that is all set. Before I actually go ahead and file these tickets, I just wanna make sure that Claude's changes applied correctly and I'm liking what I'm seeing in the TrackLine app. So I'm gonna go ahead back to TrackLine. And I see I'm gonna just have to kick my dev server really quick as it's been a little bit funky today. So I'm gonna go ahead and and restart here and just start it up and see if see if a little kick. And then start that up again. Once it's up, I'll go ahead and share one more time. Okay. Great. I see it's back up. So that was pretty quick. Thank goodness. I'm gonna go ahead and share that screen so we can take a look and assess together if we like the changes that were made. Let's go ahead and see here. Awesome. Let's see. @Alon, can you take a look? Great. I see that it's formatted, and let me go over and pretend I'm Alon for a sec. Awesome. I see that notification came right through. Great. I'm gonna go ahead and switch back into my Versus code so we can finish up here with all of the all the things that we still have to assign Alon because that wasn't just it. Awesome. So I'm gonna go ahead and proceed here. And I see that that MCP tool that we just created is now helping me to actually assign those tickets and and finish the loop. Great. And below, I'm gonna say it looks good. Go ahead and commit. Great. Yeah. I just want the changes that have mentioned support, that was a good guess, Claude. Great. And I see a launch work list is all set up for the week of March 24. Okay. And you'll notice here that with my commit, right, actually a hook ran on pre tool use bash. So for every time bash is trying to run git commit, I'm running a few different hooks that actually, you know, keep us honest on making sure that we've formatted our code, that we've run prettier and we've linted. So that's what you'll see here. You'll notice that I didn't ask Claude, like, hey, run this, make sure that you see this. Claude is actually doing this completely itself. Right? Because these hooks are actually firing on events in Claude's life cycle. Okay. Great. And you'll see now that one of the commit hooks actually required test to be written. So the test author, which is that subagent that we saw earlier, is gonna go ahead and write those for me. Awesome. Great. That looks good to me. Just for the sake of time, I'm gonna go ahead and commit this once the test author is done. But I wanna make sure that we get to all of your really good questions. So I'm just gonna hop over to one of my last tasks, right, which was reviewing that huge PR that had to do with audit logging. So let's go ahead and hop over there. You'll see that my hooks are being really effective at catching anything that I have omitted, which is awesome. But let's not let that slow us down too much. I'm gonna hop over now into into our GitHub repo, and let's go ahead and take a look. Okay. Great. So, again, this was that huge PR that I, ultimately had to review. Let's go ahead and take a look at the conversation. So I actually tagged Claude in to do a code review, which is what we talked about earlier, right, where we're spinning up a bunch of agents that are collaborating with each other in order to get something done. And it actually found some really important errors. Right? One of them was, I saw this earlier, a silent failure that I didn't see that actually swallows all audit errors, which, you know, isn't the best way to build an audit logging surface. And then any minor tests. Something that I really enjoy about this feature as well is that the comments are actually in line. So if you scroll down to find one, we can see the extended reasoning, see what the bug is, any of the specific code paths so that I can actually recreate this error myself and understand Claude's reasoning, and then why this is inconsistent with the rest of the PR. All of this, again, is building off of knowledge about my entire repo and information contained in my CLAUDE.md files. Alternatively, right, I could also just, you know, tag Claude into a code review. So this is a version of the PR that we just started working on within Claude about notifications that actually took the deprecated route. So we're seeing if Claude can catch that. And so this is a little bit more of a lightweight review as this is just Claude and GitHub actions, but it really does the job for the small feature work. Right? And if I want to, I can actually reference in a new issue and then just tag Claude in. Claude, can you take a look at this? Great. I'll go ahead and create that issue directly. And then Claude is gonna spin up here and start working. Awesome. Given that we have fifteen minutes left, I'm happy to sort of go through the commit flow and finish the loop in in Versus Code here. And then let's actually hop to questions to to close out. I'd love to hear what's come up in the demo. So I'm just gonna hop back into Versus Code really quick. We'll see that we finally passed all of our hook checks, and I'm gonna commit here. And then I'm just gonna say open a PR with this commit. Importantly, right, I can always just use bash mode in order to create that PR myself with the CLI tools. But in this case, I'll just let Claude do it for me. Okay. Great. Awesome. All set. And that PR has been created. Great. Alon Krifcher, yeah, what's come up during the demo? Curious what folks are thinking about. Yeah. So much. Thanks, Lizzie, for for going through this. This is this is really awesome. Been been tracking a lot of questions, I think, specific to the demo and just kinda touching on a lot of the, previous topics that we discussed today. So talking through some of the things around, like, code review, one of the questions was, what's the difference between Claude code code review and just tagging at Claude in GitHub actions? And I think this is a really good question. So, fundamentally, I think that the the key here is that code review is really specific, of course, to code review. It's kind of an always on agent that is designed to kind of automatically when, PRs are submitted to be able to go through and run through those different different reviews. You could think of tagging at Claude via GitHub actions kind of as more of a generalist agent. And the idea is that you can, specifically kinda guide it in the direction that you wanna guide it. If you wanted to at Claude in a GitHub action on a specific PR and ask it to do a code review, it would be able to do that. Right? But you kinda have to give it that guidance and you can also, of course, do many other things while tagging Claude direct directly in a a GitHub action. Whereas for, code review, the idea is like, yeah, it's always on. It is here to make sure that we're reviewing your code. It's got kind of the built in, infrastructure around it to do that really effectively. It's a much more kind of specific and purpose built tool for that code review process. So I think that that's a a really good question and good to kind of fundamentally understand. Like, code review, again, really purpose built for for that process. Tagging at Claude is more of a generalist that you can really guide it to do anything that you wanna guide it to do. A, another question around code review is, that I I saw a few times is, you know, Claude's writing the code. Claude's use Claude's reviewing it via via code review. How do you trust the review to not be biased? One of the really cool things to think about working with these types of models is that when you instantiate them with with new context windows and in new, surfaces, they they really do act in the kind of the most unbiased way possible. And what we see here at Anthropic is that oftentimes, Claude is catching things that maybe Claude didn't catch before in a different context window or in a different scenario. So kind of unleashing, Claude in different formats with different prompting and different goals for kinda each version or instantiation of Claude allows, Claude to kinda do that work really effectively. So totally understand that you're saying, well, it's Claude here. It's Claude here. Isn't this the same? They're just gonna agree with each other. It's not really how it works in practice. And all that's to say, there is still and another question was asking about kind of human in the loop. There's still often, scenarios where you do wanna kinda keep humans in the loop. Right? You do wanna make sure that there is, depending on the type of code that is being reviewed, how kinda mission critical it is. Having humans kinda stay in that loop and be able to even check Claude's work is is really valuable and really important, for depending on kind of the organization that you're in and the type of work that you're doing. So, yeah, I think that, like, having Claude be that first pass is going to reduce much of the manual work from kind of that code review process. And then where if and when you need to have, more human interaction and engagement on it, totally fine as well. Lizzie, anything you wanna kinda wanted to to add there, especially kind of the difference between, like, code review and just GitHub actions or where you see code review being the most effective for organizations? Yeah. That's not great. I love all of those points you made alone. I think that the one that you know, is most applicable to my work is I work with a lot of public sector customers. So folks who are, you know, migrating really, really legacy code bases from, like, COBOL, for example, even just to Java. And for those folks, you know, when they're doing, like, this really, really high risk, like, huge business role migration, I think that's really worth it to have a second pair of really, really capable eyes. Maybe in in the case in which, you know, you're doing a really complex PR, it'd be, like, six or seven different sets of eyes, with specialized agents all taking a look at it. So I think that really the way to think about it in terms of when to leverage code review is, you know, is this PR really, really important to my business? Is this a team that is really strapped for resources for code reviewers? And or is this a repo that no matter what, we just always want this to run because it's that critical. That's the way that a lot of my customers think about it. Sweet. Another question that came up was a few people noticed Lizzie here using VS Code. Lizzie, wanna talk about kind of why you use VS Code? You're using the terminal here versus the, the plug in, when you might use one or the other. What's what's your kind of preference? Yeah. I'm a big VS Code user. I hate to say it. For for multiple years, I had, like, an Olivia Rodrigo themed VS Code setup. I actually made it a little bit more professional for for this. But, you know, I love VS Code. And I know folks, you know, utilize the plug in, which is awesome. I honestly am just most comfortable in the terminal. A lot of those, like, VIM commands and Bash commands are just, like, drilled into my memory. And so I'm just happy and comfortable using them. I think that that's what's so great about Claude Code, right, is that it just meets you exactly where you want to work. For me, that might be VS Code, Olivia Rodrigo themed alone. I'm curious what that looks like for you or if you have a fun theme. so vanilla I term too. It's crazy. Like, it's basically every engineer's I term. But yeah. No. I think Lindsay's point around, like, meeting where you are is is really key. It's one of the the fundamental principles of of the team and of how we're building out Claude Code is just really thinking about, like, how do we ensure that we are enabling, engineers and non engineers alike to utilize this tool? And sometimes that'll be in, terminal. Sometimes that'll be terminal within an IDE. Sometimes that'll be with, like, the IDE plug in, and it's about what you're most comfortable in. Of course, you know, recent releases on, on the browser and Claude Code, remote and desktop, are making things even kinda more, broad in terms of where you can access Claude Code. Of course, being able to access it on your phone too. But, yeah, if you we want to make sure that, you know, where you are working, Claude Code is accessible. And and I actually think that that's a a a good segue into one of the other questions, where a few people were asking about, Claude Code review availability on other CI platforms. And I think GitLab was was one that was, commonly brought up. We are always working to, like I said, continue to make Claude Code and our features available on all the platforms that our users are on. We started obviously here with with GitHub for for a Claude Code review, and I think that it's something where we're always thinking about where can we expand and extend to. So there's no, you know, road map discussions being had right now or no promises being made right now, but you can be sure that, the team is is constantly thinking about how we can extend and expand Claude Code onto all the different platforms, that that we we know our users are on and that our our engineers are on. So, yeah, we're looking at kind of everything from Claude Code code review, other features that we build to ensure that we're meeting developers and software engineers where they are at. Okay. There were a few questions, just kinda going back to some of the other topics that, that we were discussing. A few questions around skills. Lizzie, can you talk a little bit about, you know, your overview of skills, and then when should people use skills versus maybe dedicated subagents versus hooks? Yeah. Great question. So for folks who went to our last sort of Claude Code webinar session, our colleague, Carrie, gave an awesome overview of skills. For those of you who are just getting acclimated to skills, you can think of skills as prescriptive workflows that you want Claude to follow for particular tasks or specialized tasks. So maybe a good example is, like, in Applied AI. So my and Alon team, we have, like, a technical writing guide skill that helps us to format and think about our writing and make it consistent across a bunch of different areas. These actually can be written also as just plain text files. So even if you're nontechnical, I've found, you know, a ton of the folks that I work with just being able to to write them sort of in the same style as you would write. CLAUDE.md with that front matter that tells Claude, you know, what the skill is for and then, allows you to progress through that workflow. And then the question was, how do we compare that, for example, to Subagents or to I forget what the the third door was. Books or Yeah. yeah. Absolutely. So skills rate are to guide Claude's behavior sort of in two cases. One is, you know, something that Claude, like, isn't quite good at yet. And, of course, that's like an ever decreasing list, but you might work in a really, really, really specialized firm or field that, you you want things done a very particular way. So maybe a good one is, like, FinServe, for example. There's, like, very, like, specific particulars on how you assess a fund, for example. So something that Claude, you know, might not be quite as good at yet or something that you wanna be really, really specific with. Importantly, skills. Right? They do get added to context as that entire file. So with subagents. right, only the results is coming back to your main context window, whereas skills and everything that then Claude goes out to do is gonna be part of your context windows. That's one thing to think about when differentiating between them. And then hooks. Right? Hooks are really for life cycle events that fire, you know, whether Claude likes it or not. You saw that Claude in my demo, you know, wanted to go ahead and commit and my hook said, absolutely not. We need some tests that actually cover the feature that you created and fired on that tool use pre tool use hook. So or or life cycle event rather. And so when you think about the usefulness of hooks, think about something that you want to run every single time whether or not you actually remembered to prompt Claude or Claude remembers to bring that in. Anything that you'd add along? No. I mean, I think that you summarized that really well. And I think just, like, broadly, the, understanding and explanation of skills being something that, is really, really bespoke or specific to your workflow, your organization, the work that you are doing, and ensuring that you can kinda give Claude that information that, yeah, that list is ever decreasing, as Lizzie said, but it will never be kind of empty. Right? There will always be stuff that kind of only you know and only you you know how to do. And being able to give Claude that that skill, the literal definition of the word skill to do those tasks is is a really valuable, workflow to follow. Okay. There were a a couple of questions specifically around, back to CLAUDE.mds. So, you know, questions about, CLAUDE.mds referring to other files. How do you structure them in a a repository with kind of multiple subdirectories. And one of the things I think to keep in mind is that there's the ability to at mention files, throughout your use of Claude Code, and that applies to, to CLAUDE.md files as well. So you can within kind of a subdirectory, maybe you have some dependency somewhere else in the codebase, and you can actually at mention that file in the CLAUDE.md for that subdirectory to ensure that when Claude is reading through and refers back to that CLAUDE.md, it will actually go directly to that file via that app mention to ensure that it's got the additional context from that file. So you can always kinda refer to files via Claude dot m d's, and elsewhere with app mentions. And then the other question was around thinking, like, you have your three repos. They're a little bit different. What's the recommendation for CLAUDE.md files on, like, maybe a back end or a front end of mobile? I'll refer a little bit back to, like, what Lizzie was showing in in kind of that mono repo example. Right? Like, we really wanna think about CLAUDE.md files that are specific to the work that is being done within that subdirectory. So because they recurse back in terms of Claude's ability to read through those CLAUDE.mds dot MDs, we wanna make sure that the information in a CLAUDE.md file is specific to everything kinda within that subdirectory. We wanna make sure that it's not too, restrictive in that, like, once it goes back up the the ladder through the mono repo, it might conflict with other rules. Obviously, we just wanted to be, like, really specific to the work that's being done in that subdirectory. And then there are there's one last question that I want to touch on, before we wrap up here, and that is what's the best way to keep track of changes and features in Claude and Claude Code? Some people use YouTube. Others use, x. Right? There are a lot of answers to this. It kinda depends on you, but I think that things like YouTube, things like X, we're releasing blog posts all the time about new changes and updates. We're running these webinars now regularly, and we're so lucky to have Casey on the team who's gonna be helping a lot with this type of work as well. So keep your eyes peeled to kinda all your favorite channels. Follow, the different Claude Code team members on x where often they're posting updates before they even tell us internally at Anthropic. And we sorta learn from them sometimes based on some of their social channels. But, yeah, there are lots of ways to to kinda get this information. We know that we're releasing fast and furious. It's one of the things that, has made it so much fun to be here and to work with a tool like Claude Code. We actually released auto mode for Claude Code while we were here, so y'all should go check that out. It's a safer, long running alternative to dangerously skip permissions. We are gonna be hosting a monthly with the Claude Code team to talk about what we shipped. So that will be available to register for soon, and it'll be coming up in April. And we'll talk about, auto mode. We'll talk about dispatch. We'll talk about scheduled tasks. We'll go through a bunch of stuff, and I saw a lot of questions here about how to use those with agent teams and subagents. We'll make sure the Claude Code team knows what all of what what all we saw on the questions here that we didn't get to. I will say again, this was recorded within twenty four hours. We will send the recording. You'll have the transcript. You'll have the slides. And we we put some docs here that you can go to for further reading. I recommend following Tharek and Boris and the team, Noah, Kat, on x if you're there. And we are also working on new ways, to get you the change login details around what we've launched, because it is fast and furious, and, you know, it's hard to keep up. Thanks, everyone, so much for joining us, and thanks, Alon and Lizzie, for for being here with us and and answering all of these many, many questions. And we appreciate you all for for spending time with us today. Thank you all. care, y'all. Thanks.