I Treat Claude Code Like a Small Dev Team

Most people use agentic coding tools the way they used the old autocomplete, they type a vague request, hit enter, and hope.

I did that too for a while. I would describe a feature in one paragraph, get back a wall of code, skim it, and accept it because reading it carefully felt slower than writing it myself. Sometimes it worked. Often it quietly broke something three files away that I did not notice until later. The shift that actually changed my output had nothing to do with a better model. It came from one reframe and four habits that follow from it. I decompose the work into independent units, isolate each one so they cannot collide, anchor every unit in durable project context, and verify what comes back before it merges. Those four things are exactly what makes agentic AI useful, and exactly what most people skip.

The reframe behind them is simple. I stopped treating the tool like a faster keyboard and started treating it like a small dev team that I direct. A team does not get more done because each person is a genius. It gets more done because the work is split into pieces that do not step on each other, each person has the context to do their piece, and someone checks the result before it merges. That is the same structure the four habits impose on an agent.

This is how I ship things like toolindex.net without a team behind me, and the biggest reason I can cut development time roughly in half with AI. Here is the breakdown.

Decompose Into Independent Units

The single biggest lever is decomposition, and it is the one people resist most because it feels like overhead.

When I get a task, I do not hand the whole thing over as one prompt. I first split it into units of work that do not depend on each other. Add a new settings panel to the frontend, write the migration for the new column, update the API endpoint, and add the tests. Those are four units, and three of them barely touch each other. The settings panel does not need to know how the migration is written. The migration does not care about the test file.

Once the work is split that way, I dispatch a separate subagent for each independent unit and let them run at the same time. Unrelated work happens in parallel instead of in a slow single-file line. While one agent is writing the migration, another is building the panel, and a third is drafting tests against the agreed interface. The same fan-out scales to jobs far bigger than one feature, which is how I run large generation and audit work as a fleet of agents instead of one giant prompt.

The discipline here is honesty about dependencies. If two units genuinely need each other, do not fake parallelism, you will just get two agents guessing at an interface that does not exist yet and producing two halves that do not meet in the middle. Parallel only works on truly independent slices. The skill you are building is not prompting, it is the same task breakdown a tech lead does before handing tickets to a team. The model can write the code. It cannot decide for you where the clean seams are.

Isolate Parallel Work In Worktrees

Running several agents at once creates an obvious problem. If they all edit the same checkout, they collide. One agent saves a file, another overwrites it, and you end up with a tangled working tree where nobody's change is intact.

I solve this with git worktrees. A worktree lets a single repository have several working directories checked out at once, each on its own branch, sharing the same history. So each parallel agent gets its own worktree, its own branch, its own copy of the files on disk. They cannot stomp each other because they are physically working in different folders. When a unit is done, that branch gets reviewed and merged back like any normal feature branch.

This maps directly onto how a human team avoids chaos. Two people do not edit the same file in the same checkout at the same time and pray, they branch. Worktrees give your agents the same isolation. The bonus is that each piece of work stays a clean, reviewable diff on its own branch instead of one giant blended change you have to untangle afterward. If one agent went wrong, I throw away that branch and nothing else is affected. Isolation is what makes the parallelism safe rather than reckless.

Give The Agent Durable Project Context

An agent that guesses your conventions produces confident, wrong code, and the fastest way to make it guess is to never write the conventions down.

An agent starting cold does not know that your backend folder is called back and not backend, that you never use em dashes in your copy, that migrations live in a specific directory, or that this project bans a certain dependency. If you do not tell it, it will invent something reasonable that happens to be wrong for your codebase. Then you spend your saved time correcting style and structure.

So in each repository I keep a durable context file, a long-lived markdown file at the root that the agent reads automatically before it does anything. It encodes the conventions, the folder layout, the exact paths things live at, the naming rules, the commit message format, and the hard do-not-do list. I think of it as the harness the project wears. The agent follows the project instead of guessing at it.

The reason this matters more than any single clever prompt is that it is durable. A good prompt helps once. A good context file helps on every task forever, and it compounds. Every time I catch the agent making the same wrong assumption twice, I do not just fix the code, I add a line to the context file so it never makes that assumption again. Over time the file becomes the accumulated judgment of the project. New work starts already aligned. This is the difference between onboarding a teammate properly and re-explaining the codebase to a stranger every morning.

Capture Repeated Workflows And Verify

Two habits close the loop. The first is capturing repetition. The second, and the one you can never skip, is verification.

When I notice I am walking the agent through the same multi-step procedure more than a couple of times, I stop and turn it into a reusable skill or a slash command. Releasing a build, scaffolding a new module in the house style, running the pre-merge checks, these are recurring workflows. Once captured, I invoke the workflow by name instead of re-describing it from scratch. It is the same instinct as writing a shell script for a command you keep typing. The payoff is consistency, the procedure runs the same correct way every time, not however I happened to phrase it that day.

But none of the speed counts if the output is wrong, and an agent will state that something works with total confidence whether it does or not. So I verify, every time. I read the diff, I run the tests, I actually exercise the change in the running app, I confirm the thing it claimed to fix is fixed. Trust the model to produce, never to grade its own work. This is identical to a human team, you do not merge a pull request because the author swears it is fine, you review it and you run it. The agent is a fast, tireless contributor. It is not a substitute for the reviewer, you are still the reviewer.

What Actually Creates The Leverage

Notice what is missing from all of this. None of the four habits is a prompting trick, and none of them depends on which model is underneath. They are the things that have always made a group of people ship more than a single person, applied to a contributor that happens to be software. The model supplies the labor, but the leverage comes entirely from how you direct it.

That is the part people miss when they say AI coding either changes everything or changes nothing. Handed a vague request with no decomposition, no context, and no verification, it changes very little, you get a fast first draft that you slowly fix by hand. Given the same structure you would give a real team, it changes a lot. The model got good enough a while ago, so the discipline rather than the model is the bottleneck now, and the discipline is entirely learnable.

I build things like this for clients, full-stack apps, AI agents, and automation pipelines, usually shipped faster than expected because I work with AI tooling every day. If you want something built, book a call.