Claude Code for SWE Teams: Building a Shared AI Coding Toolkit

Key Takeaways

Welcome everyone. I'm Shah and today I'm going to talk about how software engineering teams can basically onboard Claude Code onto their team. But before getting into that, you might be wondering who is this guy, why should I listen to him? Very good question. I got into AI about 8 years ago when I was getting my physics PhD at UT Dallas. After I graduated, I went to work at Toyota Financial Services as a data scientist and the past 2 and 1/2 years I've been out on my own. Maybe you guys heard of me through my YouTube channel. So I posted a lot of free educational content there. I also had a class on Maven that I would teach. It was like a 6-week cohort on how to build AI applications. Also, I've been building a lot of different SaaS products. Got two failed SaaS products under my belt. Most recently, I've been building a learning platform called AI Builder Academy where got free courses and then I do custom trainings for businesses. Let's get into this. Software engineering has changed. Now AI is writing about 100% of the code at leading labs. Here's a headline from earlier this year. Top engineers at Anthropic and OpenAI were saying how their models are writing virtually all of their code for them. This has brought up a new skill set for software engineers. This idea of so-called harness engineering. So it's not just about software engineering, but how do we give Claude or GPT or whatever model that you like the right context, the right tools to be helpful. But what about teams that are not at AI labs? What about just like the regular software engineering teams at your mid-size company or non-technology company? What are they doing with AI? I did a lot of research before this talk, so just surveying software engineers in my network and hopping on calls with them and there were three common bottlenecks that kept coming up with software engineering teams not at these cutting-edge AI labs. First and foremost, people just don't have the right tools to be getting the most out of AI to help them code. Tools like Claude Code, Cursor, GitHub Copilot, Antigravity from Google or Codex, they just don't have these tools. Maybe they are stuck with a internal GPT that their company built for them and they have to use that on-prem LLM or maybe they're using something like Microsoft Copilot or they're stuck with Claude in the chatbot interface on the web or they're stuck with like ChatGPT. They just don't have the right tools that developers need to write code. The second big bottleneck is a skill issue. Developers have the tools, but they don't really know how to maximize it. They don't know how to get Claude integrated and embedded into the codebase and doing helpful work. Not just generating code that creates more work than just doing it from scratch. So for a lot of developers, having more AI in their workflow actually leads to more problems and more effort and they think to themselves, well, it would have been faster for me to just write this from scratch than having to finally get Claude to do this correctly and then me having to like debug and fix the code afterward. But even if the teams have the right tools and they know how to use the tools effectively, individual productivity doesn't necessarily translate to team productivity. Imagine you have your software engineering team. Everyone is like that 10x engineer. They are off to the races, they've got their harnesses set up and they're shipping code 10 times faster. However, it's not enough for individuals to be more productive because in a company, in an organization, people are collaborating with one another. They have to work together in order to generate value for the customer. Even if individual engineers are effective, if the way they communicate and the way they interact with each other is still kind of slow, that's going to create a bottleneck. But it's not even just within the software engineering teams. Software engineering teams live in a larger business context. If the way that they're getting work and the way that they're generating value can't handle the 10x output that these engineers are creating, then you're not going to get that 10x impact, the 10x value from using coding agents in your work. So what's the solution here? Ultimately, what this comes down to is reimagining your software engineering workflows with AI. Reflecting on this fundamental question, what happens when the cost of generating code goes to zero? What this is going to create is a mindset shift for software engineers. The mindset shift goes from writing code to owning software. Boiling it down, what this means is the question that software engineers need to ask themselves is no longer, how do I implement this? How do I write this code? But instead, the question they need to ask themselves is, how do I get the coding agent to implement this for me? But not just like generate code that's not helpful. How do I get it to generate code that I understand, that is aligned with my expectations, that is secure and actually provides value? In order to do this, software engineers need to learn this new idea of so-called harness engineering. This is this idea of optimizing the tools, the context and the boundaries around the coding agent so that it does helpful work. That's basically what we're going to talk about in this talk. So let's talk about Claude Code. If you're not familiar, Claude Code is this coding agent and it's basically Claude, which is Anthropic's flagship AI model, plus this so-called coding harness. So it's just tools, prompts and code. Here we've got Claude and the harness around Claude are things like the ability to read and write files in the local directory, the ability to search the web and to search your codebase for specific pieces of text, the ability to run bash commands and execute code, come up with plans and ask users questions and the ability to spawn sub-agents to do specific tasks. All these things put together is what Claude Code is. This central model, Anthropic's Claude model, plus this harness, plus all the tools, the prompts and the code built around the model. There are three reasons why I personally like Claude Code. In my opinion, Claude Code is the best model today for tool calling. So a lot of times you don't just want the AI to give you answers, to generate text. You want it to do helpful work. What does that mean? It means it's going to need to pull tickets from Jira. It's going to need to search the documentation on Confluence. It's going to need to go into your Slack messages to gather more context. The second reason I like Claude Code is that it gives you better visibility and steerability into what the model is actually doing. So if you're just using Claude in the web interface or using ChatGPT or something like that, you don't really know what's going on under the hood. I mean, there's some indication of what tools it's calling and what it's thinking about, but I just feel like you have a lot more visibility with Claude Code and you can easily stop it if it's going down the wrong rabbit hole, you can give it feedback. Finally, what's helpful about Claude Code is that it's not running on the web, but rather it's deployed where you work. So it's running on your work machine so that it can go off and interact with your tools, it can see your local file system, it can explore your codebase. So it's deployed where the work is being done. And of course, even though I'm just talking about Claude Code here, a lot of these ideas apply to other coding agents. So if you're using Codex or Cursor or Antigravity or GitHub Copilot, it doesn't really matter. So what I'm going to talk about are these three main primitives for doing harness engineering. These are like three key levers we can pull to optimize Claude Code for our work. One, MCP, giving Claude the right tools and connecting it to your applications. The second are skills. These give Claude the right context to do helpful work or to generate code in a way that is aligned with your expectations. And then finally, we have hooks, which are basically automations which you can use to create boundaries or guardrails around Claude so it doesn't do anything that you really don't want it to do. So the first primitive is MCP and this is giving Claude access to tools and applications. Here we've got Claude. It already comes out of the box with a handful of tools and prompts and things like that. But what MCP allows it to do is connect to the tools and the applications that you are using for your work. Whether that's connecting to your team's Slack account, connecting to the Jira board, your Notion with a bunch of documentation, augmenting its capabilities by using Microsoft's Playwright MCP so it can actually interact with the browser, connecting it to GitHub so it can make pull requests, DataDog for pulling production observability metrics and whatever other applications or services that your team is using in their work. This is a point worth stressing, which is even though Claude is very smart, without the right context, it's not going to be as helpful as it could be. So for example, you wouldn't hire someone on your team and not give that person access to the Slack account or not give that person access to the Jira board. Imagine how much friction that would add to that person's life, to that new hire. They would just be a lot less productive than someone who has those tools that's on your team. Essentially, that's kind of like what we're doing with these coding agents. We're basically onboarding them onto our software engineering team and so they should get access to the right tools to help them be more productive. Let me just give some examples of how you might use MCP. One, you might let Claude research Slack channels and your Confluence documentation to fill in the gap of Jira issues. Maybe you've seen this like some person submits a ticket and it's like one line like the announcement banner on the website is broken or something like that. It's like, okay, well, what does that mean? There's a lot of research that is involved in understanding that problem. Another example is have it verify front ends by running them in the browser and looking at screenshots. If you're doing any kind of front end development work, it's not enough just for Claude to be able to see the code. It's helpful if it can look at the browser on its own, take a screenshot, process that screenshot and iterate on its own to improve any front end designs. Or another thing is some kind of outage happens, you have some flags on DataDog, you can automatically trigger root cause analysis when that happens. To install MCP servers, this is actually pretty straightforward. There are two main ways. One, you can explore the official servers by just running {slash} plugins in Claude code, and this is going to show you all the plugins on the official Anthropic marketplace. Also, you can download custom plugins if you want from the internet, and we'll talk about that later. Or, you can manually download servers using the Claude CLI tool. But of course, you know, internet, as you know, is the wild west, so you have to be a bit more cautious when downloading MCP servers from unknown sources. But if you just do {slash} plugins and you look at the default marketplace, they've got the check mark from Anthropic, so those are going to be a safe bet for you. The second primitive are these agent skills. These teach Claude how to use tools well and do good work. At the end of the day, all a skill is is a folder with files in it. This is going to consist of a markdown file called skill, which is just text file. You can also include other things in it. You can have like subfolders with other subfolders and files, so this could be like references. You can have assets, so like screenshots and other artifacts. You can even have scripts or like command line tools that Claude can run to do effective work. One of the key features of skills is this idea of so-called progressive disclosure. All that means is skills give Claude the right context at the right time. And so, what I mean by this is the first thing that's going to happen anytime you open up a new Claude code session is that the skills description is going to be loaded into the context window, not the full skill file and definitely not all the different files and folders that you have loaded in the skill. Just the skills description. That's going to be including things like what does this skill do and when should Claude use it? From there, if Claude realizes that that skill is relevant to the work, for example, you might have like a Jira skill for how Claude can navigate all the different Jira projects you have going on and how to pull tickets and how to update them and things like that, only then will Claude load in the full context of this skill.md file, and then from there, if there's additional context that's needed, Claude can fetch that as needed. Why use skills? Most importantly, skills give Claude competence, not just capability. It's not enough that Claude is able to access your Notion account or is able to search the web or is able to explore your code base and do stuff. Just cuz someone has access to tools doesn't necessarily mean that person is actually competent in using those tools. And I'm sure you guys have experienced this where you are trying to get Claude to do something, but it makes a bunch of mistakes. It like tries things, it gets errors, and it takes a really long time for Claude to figure out how to actually do that work. But anytime that happens, you can basically distill all the learnings, all the mistakes that Claude made, into a skill so that next time you try to do that thing, it's not going to run into those same mistakes and errors. Another key benefit is this idea of progressive disclosure, the right context at the right time. So, instead of having a bunch of text files in a specific folder and manually having to manage the context window, skills allow you to get the best of both worlds of not bloating the context window while still giving Claude all the information that it needs to be helpful. Last thing about skills is that they're composable, which means you can mix and match them. You can have a Jira skill, you can have a Confluence skill, you can have a create pull request skill, you can have a Notion skill, and Claude can combine these skills as needed for any kind of task. And just some examples of when to use skills. First and foremost, when there are performance gaps. When it takes you like 30 minutes to finally get Claude to do what you're trying to get it to do, all the lessons and the mistakes that Claude made can be summarized and compressed into a new skill. Another is MCP-specific skills. So, a lot of times, even though Claude might have all the tools that it needs to interact with your DataDog account or your Jira account, you'll find that a lot of times it makes tool calls that are not necessary, it makes tool calls and gets errors back. It has the tools, but it doesn't really know how to use them well. It's usually helpful to create a skill for specific tools to make Claude more efficient at using the MCP server. Another good use case is giving library or API-specific guidance. This came up for me. I've been using this obscure Python library to create all my web applications called FastHTML. The upside is that it's a front-end framework for Python, so all my code can be in Python. However, the downside is that there's just not a lot of examples of FastHTML code on the internet cuz it's pretty new, and accordingly, LLMs and coding agents make a lot of mistakes when trying to code in FastHTML. I created a FastHTML skill to make Claude more effective at writing code with it. And you can do this with any kind of framework. So, if you find that Claude starts making mistakes with a specific framework or a library that you're using, you can just make a specialized skill for whatever you're using. Two more. One is coding standards, so if there are shared coding standards that your team follows or that you personally follow, that can be distilled into a skill. Finally, business context. If you've hired someone on a technical team that's new to your business domain, they could be like the best coder in the world, but if they lack the business context, they're not going to be as effective as they could be. But being able to understand the business context can make developers more effective, so that's another good use case for skills. The last primitive I'm going to talk about are hooks. These are automations triggered by tool calls, session starts, and more. One of the key features of Claude is that it calls tools. Claude will call the tool, this will execute some code, and then there will be some result from that tool call. And there are tons of tools that Claude has, so like file operations, bash commands, web search, spinning up agents, doing workflow stuff, and whatever it might be. But there's some cases where you might want to execute some code anytime a tool call is executed. This is a great use case for hooks. For example, you can have hooks that run before a tool execution, and then hooks that run right after a tool execution. Some times to use hooks is when you're automating things that you or Claude do repeatedly, or if you want to set boundaries for Claude. So, basically, you don't want it to read sensitive files or you want to block it from doing a specific tool call. Ultimately, what this comes together to do is it allows Claude to be more independent, because now you can trust that Claude's not going to do anything dangerous. It's not going to go off the rails and do something you didn't expect, because you've built the right guardrails, built the right boundary for Claude using these automations. Some concrete examples, when I'm building front-ends, I'll have Claude spin up the browser, take screenshots, look at what it built, and iterate. But then after it does that, maybe it has like a dozen screenshots of the front-end. Instead of just like accumulating dozens and dozens of screenshots, I just have a hook that every time Claude is closing the browser, it's just going to automatically delete all the screenshots that were created. Another great use case are protecting sensitive files. So, if you have a .env file with API keys in it, you can basically have a pre-tool hook anytime Claude is trying to read a .env file or any other kind of file that matches some pattern, you can basically block that tool call. Another example is if you have sensitive data in a specific file format or data structure, you can block any tool call that tries to read those data files. Another example is anytime Claude generates code for you, you can automatically run some kind of verification steps. So, maybe you're going to spin up a sub-agent that has a set of tools and a set of skills specifically for verifying code and applying maybe coding standards or something like that. You can really go to town with hooks, and this gives you tremendous flexibility in how you customize Claude. I'm going to talk about two more things. I'm going to talk about combining primitives together, and then I'm going to talk about when you should have team-level primitives versus individual-level primitives. And then we'll go into a demo, and then we'll do Q&A. Combining primitives, this is basically how MCPs, skills, and hooks can be used together. In Claude code, there are two ways you can do this. We can do this with sub-agents, which are these specialized agents that have a specific model, a prompt, and harness. For example, you could create a sub-agent for verifying code implementations. Another thing you can do is you can create plugins. These are just packages of skills, sub-agents, hooks, and MCP servers. And you can just bundle all these things together. Use cases here are sub-agents are great for specific tasks, while plugins are great for sharing toolkits. This kind of brings up a natural question, like what skills and hooks should I share with my team versus what should just be specific to the individual contributor. The way I think about it is team-level stuff is all the shared stuff. If everyone uses Slack, there's no point in having people have like built custom MCP servers for Slack, just use a single Slack MCP for everyone. Another thing is if you guys all share the same Jira account, there's no point in everyone having their own Jira skill, you can just have one single Jira skill that teaches Claude how to navigate the platform effectively. Also, if your team has a template, a certain way of submitting pull requests, that can be distilled into a hook. So, anytime Claude submits a pull request, it's going to follow whatever team-level guidelines that you guys have. But the individual stuff just comes down to personal preferences. If people like to use Context 7 to automatically get updated documentations, they can download the Context 7 MCP server, it doesn't necessarily need to be like a team-level thing. Another thing is if people have very opinionated coding principles that may not be something that the whole team agrees with, but that's how they like to code, that can be an individual-level skill. Another thing is maybe they want to automatically fetch errors that happen in the terminal, that happened in the log, and write it to a text file. That's helpful to that individual, but maybe that's not ergonomic for everyone on the team, so there's no need to make it a team-level hook. Let me just do this quick demo, and then we'll do Q&A. Again, I kind of mentioned I had two failed SaaS products, and now I'm building this learning platform. What I'm going to walk through is the coding harness that I used to build AI Builder Academy. So, I'm going to walk through my MCP server, skills, and hooks. I'm going to show you guys the plugin marketplace, which is how you can basically get more MCP servers, more skills, and more hooks. And then I'm going to show you guys how to create and share custom plugins. So, this will be helpful if you're trying to create a harness that is relevant to the whole team, whether you want to distribute MCP servers or hooks or agent skills. This is the platform, just like a typical landing page. The event that we're in right now is here, and then I've got these courses here. So, it's like a little LMS, and basically all the code was written by Claude. Okay, so let's talk about the harness. I'm going to open up the terminal, and I'll type Claude. So, this is my code base. Here's Claude. We can look at the MCP servers that I have available. So, you can just write {slash} MCP, then you'll see that we have these two MCP servers built in. So, I use Notion for like basically all my documentation and all the notes. I can just say like, "Hey Claude, what's the next feature I need to implement?" And then it can go into Notion, and it can grab the right context. Playwright is a plugin {slash} library developed by Microsoft that allows computers to open up browsers, interact with user interfaces like a human would. So, this is super helpful for building front ends. You can also open up my skills. So, I've got a lot of different skills. Got these project-level skills. I've also got these user-level skills. The project-level ones, you can see this one, Fast Light, one of those obscure Python libraries, and it's for interacting with SQL like database built by Answer AI and Jeremy Howard and that whole team, if you guys are familiar. And then I have some of these other skills like to help me create content for like the events for the platform and then help me set up all the back-end stuff for the lessons. Also, I'm using this platform called MUX for the video hosting. They have a whole API, and this skill just basically teaches Claude everything you need to know about this API. So, the value of this is that, sure, Claude, every time I ask it to do something about MUX, it could go off and do research and do web search to understand how the API works. But why would I waste all those tokens and waste all that time in every new session having Claude to relearn all this stuff? I can just distill it into this very short skill so that it can just pull the skill over and over again. Then I have all these like user-level skills. So, front-end design is from Anthropic. These are just some like personal preferences I want Claude to follow whenever using the Playwright MCP server. These are some like non-technical things. Here's that Fast HTML skill that I mentioned. You can download skills from plugins. So, I got this AI Evals plugin from Hamel Husain, if you guys are keeping up with AI Evals. That's one I have there. The last thing I'll share are the hooks, which I don't have that many. So, I've got a pre-tool use hook and a post-tool use hook. The pre-tool is anytime Playwright MCP tries to open up a browser, it's going to create this {dot} playwright-mcp so that it can save its screenshots to this folder. Finally, I have this post-tool use hook. Anytime Claude tries to close the browser using Playwright, it's automatically going to delete all the PNG files in this folder. Sure, Claude could just do this itself, but it's just faster and more reliable to have this be automation instead of having it in like a skill file. If you guys aren't familiar where skills live, everything is in this {dot} Claude folder that's in your project. So, I've got all these skills here. See, we can look at the MUX skill. MUX integration for ABA courses used when working with video uploads, playback, asset management, connecting with MUX videos to course lessons. Covers MUX Python SDK signed playback tokens. It's not like a exhaustive documentation of MUX. It's just what's relevant to this project. All this has been distilled into this skill here, so it gives Claude all the context that it needs. Hooks are going to live in the settings.json file. So, we can see specifically what's happening. We have this pre-tool use hook. Anytime the tool matches this description, it's going to execute this command. So, it's going to make this directory in the current folder, {dot} playwright-mcp. And then we have the post-tool use hook, which anytime the tool matches this description, it's going to remove all the screenshots in this playwright-mcp folder. That's just like this individual project, but we can easily add more plugins. Maybe there's some other things I want to get. There's this code review plugin on the official marketplace by Anthropic. So, automated code reviews for pull requests using multiple specialized agents with confidence-based scoring to filter false positives. You know, there's the Ralph loop, which went viral. There's Figma. So, if you were working with designers, this allows Claude to connect with your team's Figma account and comes with skills for navigating it effectively. Atlassian. So, if you're using Jira and Confluence, this Atlassian plugin will be super helpful. And on and on and on. So, like Slack, Telegram. Just find whatever tools that your team is using and just download these plugins, and that's going to immediately make Claude a lot more helpful. Last thing I wanted to show you guys is the GitHub repo. So, we can actually take this harness that we've created for maybe a specific project, and we can make it shareable. So, basically all I did is told Claude to package all this into a plugin, and then I hosted it on GitHub. So, now what can happen is anyone who has access to this GitHub repo can just run {slash} plugin marketplace add shauti Claude for software engineering teams, and then they can install this plugin. So, I can show you quickly what this looks like. First, add the marketplace, and now we can add the plugin itself. You can decide, do I want this plugin to be user-scoped, so it's available across all my Claude code sessions? Do I just want it for this specific project? Or do I want it just for this specific And then if I open up Binder and I go to my downloads folder demo, we can see that it added this plugin. Okay, takeaways. So, AI agents are eating coding work. What this means is the skill set that software engineers need to think about is shifting from writing code to engineering these harnesses. To basically, how do I get Claude to write this code for me in a way that's actually helpful? And the primitives for harness engineering are MCP, skills, hooks, and Claude.md, which I didn't have time to talk about, but basically you can give Claude access to your tools and where work is happening in your team via MCP. You can distill common {slash} complex tasks into skill files, the Claude.md file, and into hooks. Finally, you can package and share MCP skills and hooks via plugins. So, if you guys have a question, feel free to just like come off mute and raise your hand. I'll also go into the chat to see if I missed anything.