Warp Speed Systems — Warp 3: Sprint Lead

You stop pairing with one agent. You start briefing a team.

At Warp 2 you sat beside a single worker and reviewed every change. At Warp 3 the work no longer fits one agent — so you hand it to a briefed team: a sprint lead that coordinates, workers that implement, QA that checks. You are still the manager. You still schedule the work, set the standards, and gatekeep what merges. The new skill is mastering the checklists, tools, and environment well enough that the team can verify its own correctness while you watch.

The shift

Budget: $100/month, a team seat. You are still in session — this is not autopilot. The change from Warp 2 isn't that you step back; it's that you stop being the only pair of hands. One worker you can watch keystroke by keystroke. A piece of work with several moving parts can't be driven that way without becoming the bottleneck yourself.

So you delegate the coordination, not the judgment. A sprint lead breaks the work down and runs the workers; you stay above it, briefing the lead, answering its questions, and approving what ships. Sessions get longer and the output per session goes up — but you are more engaged, not less. This is the first warp where steering means writing the brief instead of writing the code.

Why one worker stops scaling

Warp 1 introduced the dial: a complexsystem is several independent lines of work bound by criss-crossing dependencies. The moment a task has more live threads than you can hold in one in-session review, a single pair-worker can't keep them straight — and neither can you, if you're also the one typing.

The answer isn't a faster worker. It's a structure: someone holds the whole picture and parcels out the pieces; others go deep on one piece each. That's a team. And the only reason a team of agents produces coherent work instead of three confident drafts that don't fit together is that they've been briefed — told who they are, what they own, and when to stop and ask.

The agent hierarchy

• You — the manager. Direction, architecture, quality standards, the priorities and context the agents lack. You decide what gets worked on and in what order.
• The sprint lead. Takes your brief, breaks it into concrete steps, coordinates the workers, runs QA, and surfaces blockers back to you. Writes no implementation code.
• Worker agents.Write code, run tests, push commits. No architectural decisions. When they hit a choice they can't make, they stop and ask — they don't guess.

The hierarchy works only when agents stay in their lane. A worker making architecture calls unilaterally produces output that's hard to review. A sprint lead that starts writing code recreates the bottleneck you were escaping.

Generic + role-specific instructions

At Warp 2 you had one CLAUDE.md for everything. That stops working when agents play different roles. A worker doesn't need to know how to coordinate; a sprint lead shouldn't be writing code; QA needs different escalation rules than either.

The fix: keep CLAUDE.md for what every agent must know — repo layout, naming, coding standards — and add a role file each agent loads on top of it. A worker reads CLAUDE.md + WORKER.md; a sprint lead reads CLAUDE.md + LEAD.md.

Same idea as Warp 2's instruction file — just specialized. Shared rules stay in one place; role-specific rules don't pollute every prompt. The brief you give the lead is no longer a one-off message; it's a role the next session inherits.

Information flow must be designed

The most common Warp 3 failure: a worker hits a design question, guesses instead of escalating, and the guess is wrong. Multiply by every worker the lead is running.

Escalation does not happen by default. It has to be in written instructions:

• Workers: “If you hit a design decision or ambiguity, stop and report options. Do not proceed silently.”
• Sprint lead: “If a question is outside your context, escalate to the human. Do not resolve it unilaterally.”

Agents optimize for completing tasks, not surfacing uncertainty. Your instructions must override that default. Because you are still in session, a well-designed flow pays off immediately: a worker's blocker reaches the lead, the lead surfaces it to you, and you answer in minutes — before the wrong guess becomes an afternoon of rework.

Checklists, tools, and the environment

A team moves faster than you can personally inspect every line — so “I'll review it myself” has to become “the team checks itself, and I verify the checks.” The mechanism is a process gate: a checklist the agent walks before taking an action. Before merging: tests pass? Secrets in the diff? PR description complete? Before deploying: did the build go green? Was the issue updated? A failed check is a hard stop, not a suggestion.

The critical step is taking every standard in your head and writing it as a gate condition. Anything that still requires judgment isn't a gate yet — it's a manual step you haven't formalized. That work is exactly what a sprint lead must master: the checklists, the tools that run them, and the environment they run in. A lead that doesn't know how to run the test suite, read the CI output, or reach the deployed environment can't actually verify anything — it can only claim it did.

You still gatekeep main

At this warp, delivery stays simple on purpose: main is what's deployed, and you decide what reaches it. The team works on branches, the gates run, and you — the manager — make the call on the merge. Production state is a question of which code is physically in the branch, and that's fine while you're still in the room to approve each one.

That gatekeeping is your steering wheel here. It only works because the volume is bounded by your attention: a team you brief and review can produce more than a single worker, but not so much that you can't personally sign off on what merges. The day that stops being true — when there's more shippable work than you can gate by hand — is the day the next warp begins.

What you must have first

One skill no tooling compensates for: specifying quality in writing, not just recognizing it. “I'll know it when I see it” doesn't survive delegation — the moment a worker, not you, is at the keyboard, your standard has to exist as words it can read.

This is what Warp 2 builds. After months of daily review, you should have a document of what passes and what doesn't — specific, writable criteria. That document is the foundation of your gates and the raw material for every role file. If it doesn't exist, go back to Warp 2.

The graduation condition

You're ready for Warp 4 when briefing a team feels routine: you can write a role file a lead executes without hand-holding, your gates catch what your eye used to catch, and the only thing still requiring you in the loop is scheduling— deciding what the team works on next and approving what merges. When that's the last manual job left, you're ready to hand even that to an agent.