How to Build a Swarm of AI Agents That Ships Production Code While You Sleep

I will break down how to build a swarm of AI agents that replaces most of what a software team does day to day.

Let's get straight to it

I'm building developer tooling and agentic systems for a living. My focus is how AI agents behave once they touch real production pipelines, not toy demos. DMs are open for collaborations.

In my last post I said I'd walk a handful of builders through their first agentic pipeline setup. A few people already went through it with me, and one is running a full self-shipping loop right now.

The offer still stands. If you're building something similar, reply or DM your current setup and I'll point out the gap between it and a real swarm.

Most developers still ship code the way they did a decade ago. They open a ticket. They write the function. They write the test. They open a pull request. They wait. They merge. They watch the dashboard.

They are the pipeline.

The most productive teams building with AI right now have stopped doing that. They build swarms instead. Each agent owns one stage. The stages run in parallel. Releases go out while the team sleeps.

An engineering lead at a fast-growing AI startup put it simply not long ago:

"I stopped writing code. I write the loop that writes the code now."

That single line is why swarms matter here.

Shipping software is already a pipeline: spec, implementation, tests, review, deploy, monitor. Every well-run engineering org already runs this sequence. The only difference used to be that it needed a dozen engineers sitting inside each stage. It doesn't anymore.

I've spent the last few weeks building this swarm. It reads the ticket overnight. It drafts the implementation plan. It writes the code. It writes and runs the tests. It reviews its own diff against a second model. It opens the PR and flags anything risky before a human ever looks at it.

By the end of this post you will know the architecture of a five-agent shipping swarm, the setup to build it in a weekend, and the three failure modes that break most first attempts.

Let's get into it.

Part 1: What a Swarm Actually Is

A prompt asks a question once and stops.

A loop keeps working, checks its own progress, and continues until the task is actually finished.

A swarm is several loops running in parallel, each one a specialist, each one's output feeding the next.

That's the entire mental model.

Part 2: The Setup That Runs It

Hand-rolling this with plain scripts breaks fast. It breaks the moment one agent needs to wait on another. It breaks the moment you need state to persist across cycles. It breaks the moment you want five loops running in parallel on five different models.

What you actually need is an orchestration layer that can:

fan a single task out into specialized loops

assign any model to any step

hold state between runs

keep running until a real, checkable condition is met

Step 1: Install the CLI

Step 2: Connect Your Models

Use a fast, cheap model for boilerplate steps like spec writing, implementation, and testing, and a stronger reasoning model for the review step.

Step 3: Draft The Loop

Tell the CLI what you want in plain language:

draft me a program that runs five agents in sequence: spec writer, implementer, tester, reviewer, deployer. run it every time a new ticket lands. use the fast model for the first three agents and the strong model for review.

Here's roughly what the resulting loop looks like:

That's the whole swarm. One file. Five agents. Runs forever.

Part 3: The Five Agents

Every serious engineering org runs the same five stages of shipping. Here is the swarm that replaces them.

The maker never reviews the maker's own work. The Reviewer always runs on a separate, stronger model than the one that wrote the code.

Part 4: How This Replaces a Team

Overnight shipping. The swarm works through the backlog while the team sleeps. Every morning there are pull requests already implemented, tested, and reviewed, waiting on a human decision instead of human labor.

Burst mode. A large backlog or a big refactor gets thrown at the swarm and dozens of tickets get attempted in an afternoon instead of a sprint.

Regression watch. The swarm reruns the full test suite continuously and flags decay before users ever see it.

Part 5: Failure Modes That Break Most First Attempts

Skipping a separate review agent. Letting the same model that wrote the code also approve it guarantees blind spots.

No state persistence. A swarm without memory retries the same broken approach every cycle instead of learning from the last rejection.

No real stopping condition. "The agent says it's done" is not a stopping condition. Use something checkable: tests passing, error rate under threshold, coverage above a set number.

Respect these three and the swarm produces production-grade shipping output.

Summary

Shipping software is already a pipeline. Five stages: spec, implement, test, review, deploy.

A swarm of five specialized agents can run every stage for you, each one on the model that fits its complexity, running continuously instead of waiting on a human to move the ticket to the next column.

You stop being the pipeline. You become the architect.

Are you still the one moving tickets through the board by hand, or are you the one who built the swarm that moves them while you sleep?

Prompts

npm install -g agent-orchestrator
mkdir ship-swarm
cd ship-swarm
orchestrator init

orchestrator /providers

export default async function shipSwarm(orchestrator) {
  while (true) {
    const ticket = await orchestrator.nextTicket();
 
    const spec = await orchestrator.agent('spec-writer', {
      model: 'fast',
      task: 'Turn this ticket into a structured implementation plan: ' + ticket.body
    });
 
    const code = await orchestrator.agent('implementer', {
      model: 'fast',
      task: 'Write the implementation against the plan.',
      spec
    });
 
    const tests = await orchestrator.agent('tester', {
      model: 'fast',
      task: 'Write and run unit and integration tests. Report coverage gaps.',
      code
    });
 
    const review = await orchestrator.agent('reviewer', {
      model: 'strong',
      task: 'Check the diff for correctness, security issues, and style drift.',
      code, tests
    });
 
    if (review.passed) {
      await orchestrator.agent('deployer', {
        model: 'fast',
        task: 'Deploy to staging. Monitor error rates for two hours. Roll back on regression.',
        code
      });
    }
 
    await orchestrator.sleep('new-ticket');
  }
}

Article tables: