How I Use Claude Code, MCP and Subagents to Ship Faster

AI coding tools are easy to try and easy to use badly. Type a vague request, accept whatever comes back, and you get code that looks right, mostly works, and slowly turns the codebase into something nobody understands.

Used deliberately, the same tools make a senior engineer much faster without lowering the bar. Here's the setup I use with Claude Code, and the rules that keep it honest.

1. Give the agent the rules of the project

The biggest quality jump doesn't come from a better prompt. It comes from context the agent reads every time.

Every project I work on gets a CLAUDE.md file in the repository. It's short and specific:

• How the project is structured, and where things live.
• The conventions to follow: naming, patterns, the libraries we use and the ones we don't.
• The rules that must never be broken, like which files are generated, which config is protected, and how commits are written.
• How to build, test and run the project locally.

Without this, the agent guesses, and its guesses look like a generic project from its training data. With it, the agent writes code that looks like it belongs in your codebase. This website's own repository has one, and it's one of the first things I set up when AI tools are part of a project.

2. Connect the agent to real tools with MCP

The Model Context Protocol (MCP) lets the agent talk to tools and services directly instead of me copying information back and forth.

In practice that means the agent can read what it needs from the systems a build depends on: documentation, design files, issue trackers, and so on. That removes a whole category of slow, error-prone copy-paste work and means its answers are based on the real source, not on what I remembered to paste in.

The rule here is access control. An MCP connection is only added when it's needed for the work, with the narrowest access that does the job, and never to a client's systems without their agreement.

3. Turn repeatable work into skills

Some tasks happen on every project: reviewing a change before it merges, running a QA pass in a browser, preparing a release, writing documentation. Instead of re-explaining them each time, I keep them as skills: written, reusable instructions the agent loads when the task comes up.

A good skill encodes the checklist a careful senior engineer would follow. The result is consistency: the review step doesn't get skipped on a busy day, and the QA pass checks the same things every time.

Skills are also portable. When I set up a workflow on a client project, the team keeps the skills and context files and can use them after I've moved on.

4. Use subagents for parallel work

Subagents are separate agent instances the main session can hand a focused task to. I use them for work that benefits from running in parallel or in a clean context:

• Exploring an unfamiliar codebase: "find every place this API is called and how errors are handled", without filling the main session with hundreds of file reads.
• Research: comparing approaches or checking how a library behaves while I keep working on the main task.
• Independent review: a fresh agent reading a change with no knowledge of how it was written is a surprisingly good second pair of eyes.

The main session gets the conclusion, not the noise. That keeps the work focused, and it's faster than doing each step one after another.

5. Keep a human in charge of what ships

None of this replaces engineering judgement. The rules I keep:

• I read every change before it's committed. If I can't explain a piece of code, it doesn't ship.
• The agent proposes, I decide. Architecture, data models and anything security-sensitive are my calls, made deliberately.
• Tests and the type checker are the referee. Generated code has to pass the same build and checks as hand-written code.
• Clients decide what AI touches. If code or data can't be shared with AI tools, I work without them on that project.

What this changes for a client

The visible difference is speed on the parts of engineering that used to eat days: understanding an inherited codebase, scaffolding a new module, writing the tenth similar endpoint, checking a change for regressions. The less visible difference is consistency, because reviews and QA follow the same checklist every time.

What doesn't change is accountability. You're still hiring an engineer who understands the system and owns the result. The tools just remove a lot of the slow parts.

If you want a product built this way, or want this workflow set up for your own team, here's how I approach AI-native engineering. For the bigger picture of what the term means, see what AI-native engineering actually means.