How To Run Claude Like a Tech Lead, Not a Senior Engineer

A month ago I wrote about treating Claude like a junior teammate instead of a search box brief it properly, plan before code, review the diff.

That article is still the floor.

This one is the next floor up.

Because somewhere around July, the thing I was doing stopped being pair programming with an AI and started being something else.

I had four Claude Code sessions open.

One was building a feature.

One was testing it in the iOS Simulator.

One was chewing through a migration in a worktree.

One was reviewing a PR I hadn’t read yet.

I wasn’t writing code.

I wasn’t even briefing a single agent anymore.

I was running a team.

And running a team is a completely different skill from being good at the work.

Every engineer who has been promoted to lead knows the feeling: the thing that made you good doing it yourself, carefully is now the thing slowing everyone down.

That’s exactly where most Claude Code users are stuck right now.

Not because they’re bad at prompting.

Because they’re still operating as one very good individual contributor with a very fast assistant.

Here’s how to stop.

Step 1: Stop opening a session. Start opening a team.

The first habit to break is cd into a repo, run claude, and treat that one window as “where Claude lives.”

That window is one teammate.

You have a team.

Run this:

claude agents

claude agents

That’s the agent view one screen for every Claude Code session you have running.

What’s working, what’s blocked on you, what’s finished.

Rows show a colored state word and a headline describing what that session is actually doing, and sessions tied to a pull request or merge request get labelled with the PR number.

The first time I opened it I had six sessions alive and had genuinely forgotten about two of them.

This is the tech lead’s screen.

Not the terminal the board.

The mental shift is small and it changes everything: you stop asking “what is Claude doing” and start asking “what is blocked.”

Step 2: Split the work the way you’d split a ticket

Here’s the workflow that made this click for me, and it’s stupidly simple.

Two sessions.

One named developer.

One named QA.

The developer session gets the PRD and builds.

The QA session installs a simulator harness, runs the app, taps through the flow, and reports what broke.

Neither of them is doing both jobs, which is the entire point

the session that wrote the code is the worst possible reviewer of it.

Then this happened, and it’s the feature that turns two sessions into a team instead of two tabs:

Your sessions can message each other. Claude finds your other sessions with ListAgents and sends with SendMessage either when you tell it to, or on its own when something it changed affects what another session is working on.

You can just say it in plain English:

Tell the session working on the payments API that users.name is now users.display_name

Tell the session working on the payments API that users.name is now users.display_name

The other session shows a Message from row.

Press Ctrl+O to expand it.

Or type @ in the prompt to mention another session by name directly.

If the name matches exactly one live session, it goes straight through no confirmation step.

Run /list-agents to see who’s reachable.

Sessions on one machine keep unique names, so if you start a second session with a name that’s taken, Claude Code renames yours to a name-word-word variant and tells you.

This is available on macOS, Linux, and since late August native Windows.

What this replaces is the thing you didn’t realise was costing you an hour a day: re-explaining context. Copying a decision out of one terminal and pasting it into another, badly, with half the reasoning missing.

A lead doesn’t re-brief every person individually.

A lead makes sure information moves sideways.

Step 3: Know when to fork and when to open a new session

These look similar and they are not.

A fork is a side task that already knows everything you’ve discussed. Fork mode is on by default in interactive sessions now, so Claude can spawn a fork subagent that inherits the full conversation and the prompt cache instead of starting cold.

/subtask draft unit tests for the parser changes so far” data-toggle-ms=”1200″ aria-label=”Copy code” data-nosnippet=”” class=”code-copy-btn absolute right-3 top-1/2 -translate-y-1/2 size-8 p-1.5 flex items-center justify-center bg-black/50 text-white rounded-md transition-colors duration-200 cursor-pointer hover:bg-black/70″>

> /subtask draft unit tests for the parser changes so far

> /subtask draft unit tests for the parser changes so far

It appears in the panel below your prompt, runs in the background, and its result drops into your conversation when it’s done.

You keep working the whole time.

Notice the phrase “so far.” That’s what a fork is for — work that only makes sense in the context of this conversation.

Tests for the thing we just built.

A summary of the decision we just made.

A second opinion on the approach we just argued about.

A new session is a parallel track. Different problem, different context, its own head. /fork copies your conversation into a new background session, and — this is the important part — it makes its code changes in a worktree of its own, not in your checkout.

The rule I use:

If the task needs to know what we just said, fork it. If the task needs to not care what we just said, give it its own session.

Getting this wrong is why people’s parallel Claude experiments turn into a mess.

They spawn five sessions on the same checkout and then wonder why the diffs are fighting each other.

Step 4: Isolate, or your own AI will give you a merge conflict

This is the part a senior engineer skips and a tech lead never does.

Four sessions editing one working copy is not parallelism.

It’s a race condition with your name on the commit.

Worktrees are the answer, and they got serious:

claude --worktree https://github.com/org/repo/pull/128

claude --worktree https://github.com/org/repo/pull/128

That branches a session from the pull request itself.

GitLab merge request URLs work the same way.

Worktree isolation now blocks more than file edits

it blocks Bash commands and git redirects that try to reach back into the main checkout, in every session type and in that session’s subagents.

So a background agent can’t quietly git checkout its way into your working directory.

And background sessions that changed code in a worktree commit and push before they finish, open a draft pull request when the task actually calls for one, and follow the git instructions in your CLAUDE.md.

Read that last part again, because it’s the actual unlock: your CLAUDE.md is now team policy, not personal config. Branch naming, commit message format, whether to open a draft

PR write it down once and every session you spawn follows it.

That’s what a lead does.

Not review every commit message.

Write the convention down so nobody has to.

Step 5: Write the roles down instead of re-explaining them

If you find yourself typing “you are a reviewer, be strict about concurrency, don’t touch the module structure” for the fourth time, stop.

That’s a role, and roles belong in a file.

Drop this in .claude/agents/ios-reviewer.md:

---
name: ios-reviewer
description: Reviews Swift changes for concurrency and API-compatibility problems. Use after any change to a shared module.
tools: Read, Glob, Grep, Bash
model: opus
effort: xhigh
isolation: worktree
maxTurns: 8
---

You are a senior iOS reviewer on a securities trading app.
Assume concurrent access everywhere. Flag any change that alters a
public API surface without a migration note. Do not propose refactors
that were not asked for. Report findings as a numbered list with file
and line references.

---
name: ios-reviewer
description: Reviews Swift changes for concurrency and API-compatibility problems. Use after any change to a shared module.
tools: Read, Glob, Grep, Bash
model: opus
effort: xhigh
isolation: worktree
maxTurns: 8
---

You are a senior iOS reviewer on a securities trading app.
Assume concurrent access everywhere. Flag any change that alters a
public API surface without a migration note. Do not propose refactors
that were not asked for. Report findings as a numbered list with file
and line references.

Look at what that frontmatter is doing. tools is an allowlist, so this reviewer physically cannot write to a file. isolation: worktree gives it its own copy. effort: xhigh spends real reasoning on a hard job. model: opus picks the right person for the task.

You can pin it to the whole session:

claude --agent ios-reviewer

claude --agent ios-reviewer

Or call it by name and guarantee you get it:

@"ios-reviewer (agent)" review the order confirmation flow

@"ios-reviewer (agent)" review the order confirmation flow

Agents live in .claude/agents/ for a project, ~/.claude/agents/ for everything you do, or inside a plugin for a whole team.

This is the highest-leverage twenty minutes in this entire article.

A role you wrote down once is a teammate you never have to onboard again.

Step 6: Set the limits before you need them

A lead sets guardrails for the team.

Here are the ones that matter.

Concurrency. Twenty subagents can run at once by default. Past that you get Concurrent subagent limit reached. Raise it in settings if you genuinely need to:

{
  "env": {
    "CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS": "30"
  }
}

{
  "env": {
    "CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS": "30"
  }
}

Depth. Subagents can nest three layers below your conversation by default. Set CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH to 1 to switch nesting off entirely. I keep it shallow on anything touching production code

a four-level-deep agent chain is a thing you cannot meaningfully review.

Permissions. Since August 14, auto mode is the default permission mode for new sessions on Pro, Max, and Team.

A classifier reviews each action and lets safe ones through while blocking risky ones, and those classifier calls don’t count against your usage limits.

Auto mode is good.

It is not a reason to relax on the paths that matter.

On anything touching money, auth, or persistence I still run tight permissions, because “the classifier thought it was fine” is not a sentence I want to say in a post-mortem at a securities company.

Effort. Match it to difficulty, per agent. Standard for the boring work, xhigh for the concurrency bug, max for the genuinely brutal one-off. Running the whole team at max is slower and more expensive for no benefit

the same mistake as putting your best engineer on a copy change.

The part nobody warns you about: you become the bottleneck

Here’s the honest section.

The first week I ran four sessions, I shipped less than when I ran one.

Not because the agents were bad.

Because I couldn’t review fast enough.

Four sessions produced four diffs, and I skimmed all four instead of reading one properly.

One of them changed an error path in an order-confirmation flow in a way that looked completely reasonable and was completely wrong.

I caught it.

In review.

Barely.

That’s the tech lead’s actual failure mode, and it exists with humans too: you scale the team past your ability to keep quality, and the thing that breaks isn’t throughput, it’s judgment.

So the constraint isn’t how many sessions you can run.

It’s how many diffs you can genuinely read today.

For me that number is three.

Sometimes two.

On a day full of meetings, one.

Run more than that and you’re not leading a team, you’re rubber-stamping one.

Step 7: Review the team, not just the code

Reviewing four agents is different from reviewing one.

Let review run in parallel with the work.

/code-review runs as a background agent at every effort level now, and /review is an alias for it. Kick it off and keep going.

Use a fresh set of eyes for anything real.

/ultrareview sends a fleet of bug-hunting agents into the cloud and the findings land back in your CLI or desktop.

The point isn’t that it’s smarter it’s that it wasn’t in the room when the code was written and has nothing to defend.

Read the agent view like a standup.

Which sessions are blocked on you?

Blocked sessions are the ones costing you throughput, and they’re invisible if you’re heads-down in one terminal.

Check in without sitting there.

Run claude remote-control on your machine and it appears as a device card at the top of the Code tab in the Claude app.

I’ve kicked off a migration, gone to lunch, and read the diff on my phone.

You can change the effort level from your phone and it applies to the session on your machine.

And the rule that hasn’t changed and never will:

You still sign the commit. Not the agent that wrote it, not the agent that reviewed it. You.

A realistic end-to-end day

Here’s how it actually fits together on a normal feature:

1. Open claude agents. See what’s still running from yesterday. Clear the blocked ones first.
2. Start the build session in plan mode with a proper brief scope, constraints, definition of done.
3. Start a second session named QA in its own worktree. Its job is to run the app and break the feature, not to help build it.
4. While the build runs, /subtask a fork to draft the unit tests, since it already has the full context.
5. When the schema changes, tell one session to message the other. Don’t re-explain it yourself.
6. Kick off /code-review in the background before you read anything.
7. Read the diff. Actually read it. This is the job now.
8. If something’s wrong, rewind that session to a checkpoint and fix the brief don’t argue with the agent.
9. Commit, with your name on it, because you reviewed it.

Notice what you’re not doing anywhere in that list: writing code, and re-explaining context.

Notice what you are doing: assigning, unblocking, and reviewing.

That’s the job description of a tech lead.

It always was.

The five habits that separate leads from power users

If you remember nothing else:

1. Run a board, not a terminal. claude agents is your standup. Blocked sessions are the ones costing you time.
2. Let information move sideways. Sessions message each other. Stop being the copy-paste layer between your own agents.
3. Fork for context, spawn for isolation. If the task needs what you just said, fork it. If it doesn’t, give it its own session and its own worktree.
4. Write roles down once. A subagent file with a tool allowlist is a teammate you never re-onboard.
5. Cap the team at your review capacity. More sessions than diffs you can honestly read is not leverage. It’s a slower way to ship bugs.

The engineers getting real leverage out of Claude Code in 2026 are not running better prompts than you.

They’re running a smaller number of well-scoped agents, with clear roles, in isolated branches, and reading every diff that comes back.

Which is, when you think about it, just good engineering management — applied to teammates who happen to type faster than anyone you’ve ever worked with.

The tools finally caught up to the metaphor.

The question is whether you’re going to keep doing the work, or start leading it.

Skills Never Fire
Skills Never Fire I have eighteen skills installed. Last week I used three, and I typed the name of all three myself. I…

If this was useful, follow me for more no-fluff guides on AI tooling, iOS development, and shipping software that survives production.

Follow me on Medium Jerry PM for more iOS / AI / developer writing.

Thank you for reading! If this saved you an afternoon of merge conflicts, please consider clapping and following for more updates 👏

Before you go:

Developer resources and templates: https://zerix1.gumroad.com