# How I Run a Team of Claude Code Agents: My AI Coding Setup

> How I ship with four or more AI coding agents at once: plan first, delegate to worktrees, and let agents verify and ship their own work.

- Author: Aayush Bharti
- Published: 2026-10-20
- Reading time: 12 min
- Tags: developer-tools, claude-code, ai, workflow
- URL: https://aayushbharti.in/blog/my-ai-coding-setup

**TL;DR:** The setup is built around a loop, not an editor: plan each task in Claude Code's plan mode, delegate it to an agent in its own git worktree, run four or more agents side by side in herdr, make every agent verify its own work with type checks, tests and a real browser, and let it commit and open the pull request itself, with a quick look in Zed before it merges. Mistakes that keep coming back become a rule in CLAUDE.md or a hook, so they stop.

---
I barely type anymore. I talk to my agents — task descriptions, plan corrections, answers to their questions — and they write the code (yes, I talk to my Mac now).

On a normal day four or more Claude Code agents are running at once, and on a busy one it's eight or more. My job is everything around them: deciding what to build, splitting it into tasks an agent can finish alone, checking what comes back, and deciding what ships. Writing the code is the one part I've mostly handed off.

What follows is the loop I run every day, and the tools that hold each step of it.

## The loop behind it

Every task goes through the same five steps. The tools in the rest of this post exist to make one of them faster or safer.

```mermaid
flowchart LR
    P["Plan<br/>plan mode"]:::blue --> D["Delegate<br/>worktree + herdr"]:::violet
    D --> V["Verify<br/>checks, tests, browser"]:::amber
    V --> R["Review<br/>quick look"]:::cyan
    R --> S["Ship"]:::green
    R -. "repeat mistake" .-> H["Harness<br/>CLAUDE.md, skills, hooks"]:::rose
    H -.-> P
```

The dotted line matters most. A one-off slip gets fixed and forgotten. A mistake that keeps coming back means the setup is missing something, and fixing the setup instead of the prompt is what makes the agents better over time.

> The editor isn't where the work happens anymore. The loop is.

## Plan: decide before anything gets written

Almost every task starts in Claude Code's plan mode (Shift+Tab twice). The agent reads the code, asks questions and writes a plan, and it can't touch a file until I approve it. A correction here costs one sentence. The same correction after the code exists costs a rewrite.

For anything bigger than a bug fix, I let the agent question me before it plans. Three skills from Matt Pocock's [skills repo](https://github.com/mattpocock/skills) do this, and which one I reach for depends on how much is still undecided:

```mermaid
flowchart LR
    Q1{"Bug fix?"}:::amber -->|Yes| PM["Straight to<br/>plan mode"]:::green
    Q1 -->|No| Q2{"One<br/>session?"}:::amber
    Q2 -->|No| WF["wayfinder"]:::violet
    Q2 -->|Yes| Q3{"Domain<br/>terms?"}:::amber
    Q3 -->|No| GM["grill-me"]:::violet
    Q3 -->|Yes| GD["grill-with-docs"]:::violet
```

`grill-me` turns the usual direction around: the agent interviews me, one question at a time, until every branch of the design is settled. Each question comes with its recommended answer, so most replies are "yes" or a spoken one-line correction (this is where talking instead of typing pays for itself).

`grill-with-docs` runs the same interview against the project's own language. It keeps a `CONTEXT.md` glossary and records decisions as ADRs (architecture decision records), so the next agent reads them instead of asking me again. `wayfinder` is for work too big for one session: it charts the work as a map in [Linear](https://linear.app), one open decision per ticket, and agents settle them one session at a time.

The plan also decides the size of the task. An agent does well on something I could describe in a paragraph and check in a few minutes. When a plan grows past that, I split it, and each piece becomes its own agent.

## Delegate: one task, one worktree, one tab

Not every task should go to an agent, and `triage`, the fourth skill from the same repo, decides which ones do. It works straight on my Linear issues, moving each one through a small set of labels (Linear is the only place where tickets outnumber agents). For a bug, it tries to reproduce the problem first. An issue only becomes `ready-for-agent` once it has an agent brief: a spec complete enough that an agent can finish it with no one around to answer questions.

```mermaid
stateDiagram-v2
    state "needs-triage" as triage
    state "needs-info" as info
    state "ready-for-agent" as agent
    state "ready-for-human" as human
    state "wontfix" as wontfix
    [*] --> triage
    triage --> info : missing detail
    info --> triage : reporter replies
    triage --> agent : agent brief written
    triage --> human : judgment, access, manual tests
    triage --> wontfix
    agent --> [*] : cc
    class triage amber
    class info amber
    class agent green
    class human blue
    class wontfix rose
```

Once a task is ready, it gets its own agent. My shell has one alias for that:

```bash title="~/.zshrc"
alias cc="claude --worktree"
```

`--worktree` starts Claude in a fresh git worktree on its own branch. With eight agents on one repo, that's the difference between parallel work and agents overwriting each other's files. If I don't like the result, I delete the folder (the cheapest code review there is).

### herdr keeps track of the team

Running eight agents is easy. Knowing which of them needs you is the hard part, and [herdr](https://herdr.dev) is what solved it for me.

It's a terminal workspace manager built for coding agents. It runs inside Ghostty, keeps one workspace per repo, and reads each pane to show whether its agent is working, blocked or done. I look at the sidebar and go straight to the agent that's waiting, instead of cycling through tabs to find it.

herdr also keeps the agents running on a background server. Its Claude Code integration (`herdr integration install claude`) records each session's ID, so after a reboot every pane comes back with its conversation attached.

Agents can drive herdr too. Its CLI and socket API let an agent split a pane, start another agent, and wait until that one finishes. With a herdr skill installed, one agent can hand a subtask to a second agent in the next pane and pick up the result.

```mermaid
sequenceDiagram
    autonumber
    participant Me
    participant A as Agent A
    participant H as herdr
    participant B as Agent B
    Me->>A: Task with an approved plan
    A->>H: Split pane, start Agent B on a subtask
    H->>B: Launch in the new pane
    A->>H: Wait until B is done
    Note over B: Works in its own pane
    B-->>H: Done
    H-->>A: B finished
    A->>A: Reads B's output, carries on
    A-->>Me: Ready for review
```

## Verify: agents check their own work

This is the step that changed the quality of the output the most. An agent that can run a check fixes its own mistakes before I ever see them. One that can't hands me a guess, written with total confidence (they're always confident).

In this site's repo, the agent has three ways to check itself:

- **`bun run check`** runs the linter (Ultracite on Biome) and the TypeScript compiler. Strict types catch most wrong guesses about an API.
- **`bun test`** runs the unit tests next to the code. For logic, the agent writes the test first with the `tdd` skill.
- **[agent-browser](https://agent-browser.dev)** gives the agent a real browser. For any UI change, it opens the page, clicks through it, takes a screenshot and looks at the result.

My global `CLAUDE.md` says to act on evidence, not assumptions. In practice, an agent saying "tests pass" counts for nothing until it shows the output.

## Review: a quick look before it merges

Agents commit their own work and open the pull request with [gh](https://cli.github.com/). The PR body comes from the `pr` skill, also from [Matt Pocock's repo](https://github.com/mattpocock/skills): a small diagram or diff-sketch of what changed, before-and-after evidence like a screenshot or a test run, and a "merge danger" note on how easy the change is to undo and how far it reaches.

That body is most of my review. By the time a change reaches me, the checks have run and the agent has looked at the UI, so I don't read it line by line. I look at the shape of it: did it touch files the task didn't need, and did it quietly invent something, like a fallback, a placeholder or a number in the copy? If it looks right, it gets squash-merged, so `main` stays one commit per change.

That quick look happens in [Zed](https://zed.dev). When the editor's main job is skimming changes rather than typing them, Zed fits: it's fast with no setup, and I run it on the VS Code keymap with vim mode off. The git panel opens a file's diff on click, and the split diff view shows old and new side by side. When I'd rather talk to the agent next to the file, Zed's agent panel can host Claude Code through ACP (the [Agent Client Protocol](https://agentclientprotocol.com/)).

```json title="~/.config/zed/settings.json"
{
  "base_keymap": "VSCode",
  "vim_mode": false,
  "format_on_save": "on",
  "diff_view_style": "split",
  "git_panel": {
    "entry_primary_click_action": "file_diff",
    "group_by": "staging"
  },
  "agent_servers": {
    "claude-acp": { "type": "registry" }
  }
}
```

For a bigger change, a review skill or the `code-simplifier` agent goes over the branch first, so my look starts from their notes.

## The harness: repeat mistakes become rules

The loop works because of the files around it. Claude Code reads them at the start of every session, and they're where I put what I learn.

- **`CLAUDE.md`** holds the rules. A global one in `~/.claude` covers how I like to work everywhere. One at each repo root covers that project: commands, architecture quirks, the voice for copy.
- **Memory** holds smaller lessons Claude saves itself when I correct it, one fact per file, loaded in later sessions.
- **Skills** are instructions for a kind of task, loaded only when the task matches: TDD, diagnosing a bug, writing a handoff note for the next agent, stripping AI tells out of prose (yes, the agents have a skill for not sounding like agents).
- **Hooks** are for anything that must happen every time. A rule in `CLAUDE.md` is advice; a hook is a command that always runs.
- **Plugins** add tools and skills on top, like current library docs through Context7, code review, and Vercel.

Most lines in my `CLAUDE.md` and memory started as a mistake, but not every mistake earns one. A one-off gets corrected in the session and forgotten. When the same thing goes wrong a second or third time, the fix goes into one of these files instead of my next prompt, so every later session starts with it.

Memory needs the same care as code. A wrong memory is worse than none, because every later session trusts it, so I prune it and delete what turns out to be wrong.

## Where it breaks

None of this is free, and pretending otherwise would make this a sales page.

Every worktree is a fresh checkout. It needs its own `bun install`, and the `.env` files have to be symlinked in, so each new agent pays a small setup tax before it writes a line. Eight agents means eight installs.

The quick-look review only works because the checks are strong. Strict types, tests and a browser catch the boring mistakes, which frees my attention for the interesting ones. In a repo without those, I'd be back to reading every line, and eight agents would be eight times the reading.

Context is the other limit. The status line in Claude Code shows how full the context window is, and when it fills up fast, that's usually a sign the task was too big and should have been split. It also shows a dollar figure for the session, which is what the work would have cost on the API. I'm on Claude Max, so the real bill is a flat monthly subscription (that number on the status line is still a good way to feel guilty).

## The terminal underneath

All of this runs on a MacBook M5 Pro, inside [Ghostty](https://ghostty.org/): a GPU-fast native terminal that works well out of the box, so the little config I have is a few lines in one plain-text file (tabs and splits behind a `Ctrl+Space` prefix, mostly). The shell is zsh with no framework: autosuggestions and syntax highlighting sourced directly, [Carapace](https://carapace.sh/) for completions across most CLIs, and [Starship](https://starship.rs/) for a prompt that shows the branch and whether I'm inside a worktree. With agents creating worktrees all day, that last part saves real confusion.

```bash title="~/.zshrc"
eval "$(starship init zsh)"
eval "$(zoxide init zsh)"
source <(carapace _carapace)

alias ls="eza --icons=always --no-user"
alias cc="claude --worktree"
```

The small tools I keep are the ones agents use as much as I do: [ripgrep](https://github.com/BurntSushi/ripgrep) for search (it respects `.gitignore`, so agents don't drown in `node_modules`), [zoxide](https://github.com/ajeetdsouza/zoxide) to jump between repos, [eza](https://github.com/eza-community/eza) for listings, and [portless](https://portless.sh), which gives each local dev server a named URL so several worktrees can run at once without fighting over ports.

[Raycast](https://raycast.com/?via=aayush) is the launcher, with snippets and window management on the same key. The rest of the desk, hardware included, is on my [uses page](/uses).
## Where that leaves you

I started this post saying I barely type anymore, and that's the real change. The keyboard used to be where the work happened. Now it's my voice, a sidebar of agents, and a diff I skim before it merges.

The tools in this post will change, probably within the year. The loop won't: plan before code, one agent per task, let it prove its work, take a quick look before it merges, and turn repeat mistakes into rules. If you take one thing from this, start with the verify step. An agent that can check itself is worth more than any editor or terminal on this page.

If you're curious how this site is built, I wrote that up in [building a blog with Next.js and MDX](/blog/build-a-blog-with-nextjs-and-mdx), and if you're earlier in the journey, [what I wish I knew before learning to code](/blog/what-i-wish-i-knew-before-learning-to-code) is the place to start.

## Frequently asked questions

### What is the best AI coding setup?

The tools matter less than the loop around them. A setup that works plans each task before any code is written, gives every agent its own git worktree, lets the agent check its own work with type checks, tests and a browser, and keeps a quick human look before anything merges. Mine uses Claude Code for the agents, herdr to run them in parallel, and Zed to review.

### How do you run multiple Claude Code agents in parallel?

Start each task with claude --worktree so every agent gets its own checkout and branch, then run each session in its own tab. A workspace manager like herdr shows which agents are working, blocked or done, so you only switch to the ones that need input.

### What is herdr?

herdr is an open source terminal workspace manager for AI coding agents. It runs inside your existing terminal, keeps one workspace per repo, shows whether each agent is working, blocked or idle, keeps agents running when you disconnect, and restores their sessions after a restart. Agents can drive it too, through a CLI and socket API.

### How do you make AI coding agents produce better code?

Give them a way to check their own work. Type checks, linters, tests and a browser the agent can drive turn a guess into a feedback loop. Then treat every repeated mistake as a bug in the setup: add a line to CLAUDE.md, a skill, or a hook so the agent can't make it again.

### What are the grill-me, wayfinder, triage and pr skills?

They're agent skills from Matt Pocock's open source skills repo. grill-me has the agent interview you about a plan, one question at a time, until every decision is resolved. grill-with-docs does the same while keeping a CONTEXT.md glossary and decision records up to date. wayfinder turns work too big for one session into a map of decision tickets on your issue tracker. triage labels issues and writes agent briefs for the ones an agent can take on alone. pr writes the pull request body: a diagram of the change, before-and-after evidence, and how risky it is to merge.

### Why use Zed with Claude Code?

When agents write and commit most of the code, the editor's main job is skimming changes. Zed is fast with no plugin setup, has a split diff view and a git panel built in, and can host Claude Code in its agent panel through the Agent Client Protocol.