Wave-Dispatched SDD: 75% Less Time From Project Start to Code Complete

This is the sidebar to The Spec Is the Ceiling. The parent post argues that every step of agent-driven engineering downstream of the stakeholder spec is commoditized. This is the receipts version. One engagement. Real numbers. Real friction. Reportorial, first-person, no client identification.

The before state

The team had a Claude Code license and a habit. Tickets came in one at a time. An engineer picked one up, asked the obvious clarifying questions in Slack, and started building. AI was in the loop, but mostly at the keystroke layer: autocomplete, occasional refactor, the odd test scaffold. Throughput at the engineer level had gone up. Throughput at the team level had not.

The slow part was upstream. Specs were thin. A ticket would say “build the X flow” and leave the rest to the engineer in the chair. That engineer would absorb the ambiguity, make the tradeoffs in the moment, and surface the decisions at PR time. Half the review cycle was the rest of the team catching up on choices that should have been made before code was written.

I have written about this shape before, both in the chunking post and in the spec-is-the-ceiling argument. The team had the tools. The team did not have the pipeline.

What we changed

We did not change the agents. We did not change the IDE. We did not change the ticketing system. We changed where the work started and how it flowed.

The new pipeline had six steps. It is the same shape I describe in the parent post.

flowchart TD
    A[Stakeholder Spec<br/>flows + data per flow] --> B[AI Engineering Agent<br/>surfaces hidden reqs, scaling, failure states]
    B --> C[Technical Brief<br/>scoped, testable, bounded]
    C --> D[PM Agent<br/>cuts tickets in Linear]
    D --> E[Engineering Agent<br/>breakdown + dependency DAG]
    E --> F[Wave of Build Agents<br/>parallel, isolated worktrees]
    F --> G[Wave of Review Agents<br/>code quality, security, build hygiene]
    G --> H{Verdict}
    H -->|pass| I[Merge]
    H -->|fail| F

The shape sounds obvious. The work was upstream.

Step one used to be “write a Jira ticket.” We replaced it with a stakeholder-readable document. Flows the system supports, data each flow captures, what is out of scope, what success looks like. The format is not exotic. It looks like this, anonymized:

# Spec: <Capability Name>

## What this is for
One paragraph describing the stakeholder problem in their own
language. No implementation hints. No system names.

## Flows in scope
1. <Flow A, plain English>
2. <Flow B, plain English>
3. <Flow C, plain English, including failure path>

## Data each flow captures
Flow 1: <ordered list of fields>
Flow 2: <ordered list of fields>
Flow 3: <ordered list of fields>

## Out of scope
Bullet list. Explicit. Easier to read than to infer.

## External touchpoints
APIs, services, jobs, queues we depend on. Versions where known.

## Non-functional
Latency budgets, throughput, retention, compliance flags.

## What success looks like
The shortest possible statement of done from the stakeholder's POV.

That document is what the human and the stakeholder iterate on. Once it stabilizes, an AI engineering agent reads it and surfaces what the spec left unsaid. Scaling assumptions. Failure modes. External API quirks. Build-quality tradeoffs the stakeholder did not know they had to make. The agent does not invent answers. It writes back the questions. The human takes those questions to the stakeholder. The spec sharpens. Two or three iterations later, it is testable.

Then a PM agent reads the sharpened spec and writes Linear tickets with acceptance criteria, scope tags, and dependency notes. An engineering agent reads the tickets and produces a breakdown plus a dependency DAG, calling out which work can run in parallel and which work has conflict edges that force serialization.

Then wave dispatch. One build agent per ticket in the current wave, each in its own worktree. From the orchestrator, the dispatch looked like this. Anonymized, but the shape is intact:

// Wave 1: three independent tickets, no conflict edges.
// Each agent gets the spec path, the ticket scope, and a "done when" clause.

await Promise.all([
  Agent({
    subagent_type: "engineer",
    description: "ENG-<n> flow A",
    isolation: "worktree",
    prompt: `
      Implement ticket ENG-<n> (<flow A>).
      Spec: docs/specs/<capability>.md
      Files in scope: src/<area>/<flow-a>/*
      Done when: tests pass, PR opened against main, ticket linked.
    `,
  }),
  Agent({
    subagent_type: "engineer",
    description: "ENG-<n+1> flow B",
    isolation: "worktree",
    prompt: `
      Implement ticket ENG-<n+1> (<flow B>).
      Spec: docs/specs/<capability>.md
      Files in scope: src/<area>/<flow-b>/*
      Done when: tests pass, PR opened, ticket linked.
    `,
  }),
  Agent({
    subagent_type: "engineer",
    description: "ENG-<n+2> flow C",
    isolation: "worktree",
    prompt: `
      Implement ticket ENG-<n+2> (<flow C>).
      Spec: docs/specs/<capability>.md
      Files in scope: src/<area>/<flow-c>/*
      Done when: tests pass, PR opened, ticket linked.
    `,
  }),
]);

Three PRs land within the same window. Then a wave of review agents goes after them in parallel. Each reviewer is read-only, single-PR, with no shared context across the wave. Pass moves to merge. Fail kicks back to a build agent with the reviewer’s notes attached. The orchestrator monitors and steps in only when an agent escalates.

That is the whole pipeline. The mechanics are not exotic. The discipline upstream is what makes them work.

The numbers

Two figures matter.

75% reduction in time from project start to code complete. Project start meaning the first stakeholder conversation about the capability. Code complete meaning all PRs merged and acceptance criteria green. Measured against the team’s prior cadence on comparably scoped work, before the pipeline change.

Requirements gathering plus ticket creation: weeks to 2 days. This is the spec-phase compression, and it is the part I want a VP of Engineering to read twice. The phase that used to swallow two or three calendar weeks of back-and-forth now resolves in two working days. Stakeholder spec, iteration with the engineering agent, technical brief, and Linear tickets all close inside that window.

Honest caveat: one engagement, one team, work scoped comparable to what the team had been shipping. The spec discipline was rebuilt in parallel with the wave-dispatch change. The 75% number is not attributable to wave dispatch alone. The spec rebuild is the heavier load-bearing piece, which is the point the parent post is making.

The friction

I am not going to pretend this was smooth. Three things hurt.

Merge conflicts between parallel waves are annoying. When the engineering agent’s breakdown got the dependency DAG slightly wrong, two build agents in the same wave touched overlapping files. The merge conflict surfaces at the end of the wave, not during it, which means you find out you have a problem after both agents have already done the work. The fix is tighter conflict-edge detection in the breakdown step, plus shorter waves so the blast radius of a bad split stays small. Worth it, still annoying.

Engineering agents need a lot more direction in decision-making than the original scoping assumed. This is the part I would warn another team about first. The agents will happily make load-bearing tradeoffs unilaterally. Caching strategy. Schema decisions. Retry semantics. Whether to introduce a new dependency. None of that should be an agent decision, but inside a worktree with a brief that says “implement this flow,” the agent will pick something and keep going. By the time the PR opens, the decision is baked in and reviewing it costs more than making it would have.

The fix was more human review loops, not fewer. That is counterintuitive against the AI-replaces-engineers narrative, and it is the real story. We added a pre-build check where the orchestrator scans the engineering agent’s breakdown for tradeoff decisions that should have been resolved upstream, and kicks them back to the spec before any build agent runs. We added a mid-wave check where the orchestrator reviews the agents’ early draft commits for the same pattern. We added a post-wave check before review where a human looks at the PRs as a set, not individually, to catch decisions that drift across PR boundaries.

None of that subtracts from the 75%. It is a tax inside the 75%. The point is that the human is not gone. The human is doing different work, at a different layer, with a much bigger blast radius per decision. The pipeline runs faster because the humans are deciding things humans should be deciding, and the agents are doing the mechanical work agents are good at.

The generalizable lesson

The pipeline is reproducible. The six steps are not secret. The dispatch code is twenty lines. The worktree isolation is a flag. Any team with Claude Code or Cursor background agents, a ticketing system with an API, and worktree orchestration can run this shape next week.

What is not reproducible without the spec rebuild is the 75%.

If a team adopts wave dispatch without fixing intake, they will get throughput without quality. The agents will be fast. The agents will also be quietly making tradeoff decisions no one signed off on, inside worktrees no one is watching, on PRs that look fine until two months later when the caching strategy and the schema decisions and the retry semantics all collide in production. The throughput number will look great. The codebase will degrade underneath it.

The other half of the lesson is that the spec phase shrinks dramatically when the spec is the load-bearing artifact. Weeks of back-and-forth is what happens when the spec is implicit, distributed across Slack threads and Jira tickets and Loom recordings, and the engineers in the chair absorb the ambiguity. Two days is what happens when one document is the source of truth, the AI engineering agent’s job is to surface what the document left unsaid, and the humans in the loop are deciding the things only humans can decide. The compression is not magic. It is what happens when the decision moves to where the decision belongs.

The 100x engineer in 2026 is the person who can shape a spec that ten agents can run against without drifting, and who has the instinct to spot which tradeoffs the agents will quietly make if the spec leaves them open. That is the work. The wave dispatch is the easy part.

Where to go from here

If the numbers here look like the order of magnitude you want, the question is not “what agents should we use.” It is “what does our spec process look like before any agent gets involved.” Same shape as the parent post argues, and the same shape the chunking-problem post explains one layer down: the deciding does not compress. The building does.

For a different domain with the same intake discipline, the web3 gaming engagement rolled this shape across five departments.

If you want help shaping that intake before the agent dividend gets eaten by entropy, book a call.