Lieutenant General Passbutter

Up until this point, we've been using a naive approach to agentic development. I have a generally-informed idea of what I want to do, and I just ask Claude to perform a task of a reasonable size. We've had Claude add some directives to CLAUDE.md, but we've only been working with one agent: the one that is identified as general-purpose.

This single agent has been responsible for planning our implementations, installing our dependencies, writing code to meet our requests, checking code quality, writing commit messages, and pushing to our GitHub repo.

But there are ways to curate the information that is provided to Claude, and there are ways to focus its concentration.

I started by asking Claude some questions about MCP servers:

I wasn't sure these were great use cases for MCP.

At my current level of understanding, an MCP server provides a kind of API that agents can utilize when prompted with the right data. If we're going to implement one ourselves, it's because we want to give the agent access to only particular data (either data that we own, or a third-party API that doesn't have an MCP implementation yet).

I can see some uses for this when we look at making tag suggestions for songs later in development, but I don't think this translates well to our early-stage Spotify usage—looking at the proposed backend endpoint, we are just adding an extra layer to our logic without any agentic utilization along the way.

Still, we'll keep an open mind. The uses for these tools are fairly unbounded, and I think we'll have many uses for MCP.

For the sake of asking, let's see what Claude thinks we could do with MCP as a dev tool.

We'll keep these suggestions in mind for later. But why not just use subagents?

It seems reasonable to start with the obvious benefit. Subagents will provide separation of duties and may avoid some of the "oops, I forgot" that we've encountered with Claude Code thus far.

All of these look promising. They would remove that overhead from ourgeneral-purpose agent and parcel out the thinking required for each task. Can Claude do this for us?

It's important to be clear in your prompts. I was asking if Claude was able to do this, but it was taken as a directive. In this case, I just removed the file after inspecting it to understand what Claude was trying to do. We didn't want something that is effectively a subagent. We want to create actual subagents.

I asked Claude to recall our original question about proposed subagents and give us templates instead. Not only can Claude Code generate the agent based on your prompt (which you'll see coming up), but it can also generate the prompt you should provide in the first place.

Now we can just progress through the agent creation menu and paste the suggested prompts. We can always refine these agents later—let's just see how they perform.

I followed these quick steps for each of the templates Claude provided. Let's take a look at our new agents!

Well that's not right. We can see the agent files were created, but the current Claude instance hasn't detected them (even though it created them!).

Notice the problem yet? That's right, Claude mistakenly created our new .claude directory in the backend directory instead of the project root.

Once the new directory was moved to the proper place, the new subagents were recognized and we're ready to try them out.

Obviously, our new test-coverage-enforcer has some catching up to do.

When you're bound to syntax, you become a slave to propriety. You look at documentation, you implement the tool you're building, you do things by the book. LLMs have thrown that concept on its head in many ways—and for people like me who tend to think of things in terms of stages of canon, it can be frustrating. I've mentioned my concerns about exactness in prompts to AI agents, and I still have many concerns about the concept we're building out now. I won't understand the guts of this thing like I would if I had to build it through trial and error. And I like that process.

But with this approach comes some new abilities. We don't have to follow a rote development workflow. Much of what I've done in this project does follow the steps a developer might normally take in the early stages of development, but I'm trying to illustrate how these tools can help us. We always need to be open to the idea that they're capable of much more as well. Despite the ambiguity inherent in natural languge prompts, or perhaps because of it, you can find yourself breaking out of your safe habits and finding new approaches.

I did that in the most primitive way with our subagents. If subagents can be defined, then the agent can define them. We'll see how many opportunities for abstraction we can discover.