The Dark Factory Pattern Part 4: Scaling the Factory

A single agent executing a single spec is a proof of concept. A factory is many agents running many specs in parallel, continuously, with predictable cost and quality. That's the gap between Level 4 and Level 5 — and most teams stall here. They have spec-driven development working for one feature at a time, but the moment they spin up three agents simultaneously, costs spike, merge conflicts multiply, and nobody knows which agent broke the build.

This guide covers the three systems you need to run a dark factory at scale: multi-agent orchestration (running agents in parallel without collisions), cost control (keeping your token bill under control as throughput grows), and observability (knowing what your factory is actually doing). By the end, you'll have a production-grade setup where you can push five specs in the morning and review five PRs after lunch — or let them auto-merge entirely.

Why Does the Single-Agent Model Break Down?

In Part 3, you built a pipeline: write a spec, hand it to an agent, agent implements and validates, you review the PR (or auto-merge). It works beautifully — for one spec at a time. But real codebases don't have one task. They have a backlog of 20-50 items at any moment. Running them sequentially means your factory has a throughput of maybe 3-4 features per day per human.

The fix seems obvious: run multiple agents. But naive parallelism introduces three failure modes:

Google's 2025 DORA Report found that 90% AI adoption correlated with a 9% increase in bug rates, 91% increase in code review time, and 154% increase in PR size. These aren't problems with AI coding — they're problems with unstructured parallelism. The factory pattern solves them with isolation, routing, and monitoring.

How Do You Run Multiple Agents Without Collisions?

The answer is git worktrees — separate working directories that share the same repository history but have independent file systems and branches. Each agent gets its own worktree, works on its own branch, and never touches another agent's files. Merges happen through PRs, not through shared filesystem access.

Option 1: Manual Worktrees (DIY)

The simplest approach. Spin up Claude Code in separate worktrees using the --worktree flag:

# Terminal 1 — agent works on auth refactor
claude --worktree feature-auth

# Terminal 2 — agent works on webhook fix
claude --worktree fix-webhooks

# Terminal 3 — agent works on dashboard
claude --worktree feat-dashboard

# Each gets its own branch and working directory at:
# .claude/worktrees/feature-auth/
# .claude/worktrees/fix-webhooks/
# .claude/worktrees/feat-dashboard/

This is the pattern most developers start with. You're the orchestrator — you decide which specs go to which agent, monitor progress manually, and handle merges. It works well for 2-3 parallel agents.

Option 2: Agent Teams (Coordinated)

For 3-5+ parallel agents, Claude Code's Agent Teams feature adds coordination on top of worktree isolation. One session acts as the team lead, spawning teammates that communicate through a shared task list and messaging system.

# Enable agent teams (experimental)
# Add to .claude/settings.json:
# { "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } }

# Then tell Claude what you want:
> Create an agent team to implement these three specs in parallel.
> Each teammate should work in its own worktree.
> Use Sonnet for implementation, require plan approval before coding.

The Decomposition Rule

Parallelism only works when tasks are truly independent. The decomposition rule: if two specs touch the same file, they must run sequentially. Your spec backlog should explicitly declare file ownership. When two specs overlap, the orchestrator (you, or the team lead agent) sequences them.

# Spec: Rate Limiting Middleware
files_owned: [src/middleware/rate-limit.ts, src/middleware/index.ts]
depends_on: []

# Spec: Auth Token Rotation
files_owned: [src/auth/token.ts, src/auth/refresh.ts]
depends_on: []

# Spec: Auth Audit Logging  ← depends on token rotation
files_owned: [src/auth/audit.ts, src/auth/token.ts]
depends_on: [auth-token-rotation]
# ↑ Can't run in parallel with token rotation — they share token.ts

How Do You Control Costs at Scale?

The average Claude Code developer spends ~$6/day. A dark factory running five parallel agents on Opus can burn $50-100/day without optimization. At team scale (10 engineers, each running 3-5 agents), that's $1,500-3,000/day. Unoptimized, the economics don't work. Optimized, they're transformative — the equivalent of hiring 5-10 additional engineers for a fraction of the cost.

Monthly cost per developer running 3 parallel agents (estimated)

Strategy 1: Model Routing

Not every task needs Opus. The 80/20 rule applies: ~70% of coding tasks perform equally well on Sonnet, which costs 60% less ($3/$15 per MTok vs $5/$25). Route Opus to complex architectural decisions, multi-file refactors, and subtle bug fixes. Route Sonnet (or even Haiku for trivial tasks) to implementations with clear specs, test writing, and documentation.

# In your agent team prompt:
> Spawn implementation teammates using Sonnet.
> Use Opus only for the architect role that reviews plans.

# Or per-subagent in .claude/agents/:
---
model: sonnet
---
You are a test-writing agent. Given a spec, write comprehensive tests.

# For headless automation:
claude --model sonnet -p "Implement the rate-limiting spec"

Strategy 2: Prompt Caching

Prompt caching reduces repeated context costs by up to 90%. When every agent loads the same CLAUDE.md, AGENTS.md, and project structure, those tokens are cached after the first request. The 5-minute cache window means parallel agents running simultaneously all benefit — a cache hit costs just 10% of the standard input price.

Strategy 3: Context Discipline

The biggest hidden cost isn't the model — it's bloated context. Each unnecessary file read adds thousands of tokens that compound across every subsequent message. Factory-grade context discipline:

Strategy 4: Budget Gates

Set hard limits so a runaway agent can't burn your monthly budget in a single loop. Use workspace spend limits in the Claude Console, and per-session awareness with /cost. A factory-grade rule: if any single spec execution exceeds $5, kill it and investigate. Most well-written specs complete for under $1.

// .claude/settings.json — cost-aware configuration
{
  "env": {
    "MAX_THINKING_TOKENS": "16000",
    "CLAUDE_CODE_EFFORT_LEVEL": "medium"
  }
}

// Use "high" effort + full thinking only for complex specs
// Use "medium" or "low" for straightforward implementations

How Do You Monitor a Factory You Can't See?

A dark factory that runs without visibility isn't autonomous — it's abandoned. The "dark" in dark factory means no human writes or reviews code, not that nobody is watching. You need three categories of metrics:

Building Your Dashboard

You don't need a fancy platform to start. The raw data is already available:

# Track token spend per session
claude --output-format json -p "implement spec" | \
  jq '.[] | select(.type == "summary") | .cost'

# Track specs completed (count merged PRs from agent branches)
gh pr list --state merged --author @me --json number,title,mergedAt | \
  jq '[.[] | select(.title | startswith("feat:") or startswith("fix:"))] | length'

# Track rollback rate
MERGED=$(gh pr list --state merged --limit 100 --json number | jq length)
REVERTED=$(gh pr list --state merged --limit 100 --json labels | \
  jq '[.[] | select(.labels[]?.name == "reverted")] | length')
echo "Rollback rate: $(echo "scale=1; $REVERTED * 100 / $MERGED" | bc)%"

For production-grade monitoring, pipe these metrics into your existing observability stack (Grafana, Datadog, or even a spreadsheet). The key insight: treat your factory like a production service. It has SLOs, dashboards, and alerting — just like any other system you operate.

What Happens When an Agent Fails?

Every factory has defect rates. The question isn't "will agents fail" — it's "how fast do you detect and recover." There are three categories of failure in a dark factory:

Circuit Breakers

Borrow the circuit breaker pattern from distributed systems. If your factory hits any of these thresholds, stop auto-merging and investigate:

• 3 rollbacks in 24 hours — something systemic is wrong (bad AGENTS.md, broken dependency, flawed spec template)
• Holdout pass rate drops below 85% — the spec quality or scenario coverage has degraded
• Daily spend exceeds 2x your rolling average — agents are looping or context is bloated

What Do Humans Do in a Dark Factory?

The shift from "developer" to "factory operator" is the hardest part of this transition — not technically, but psychologically. Your day looks radically different at Level 5:

Deloitte research shows that 86% of HR leaders recognize "digital labor integration" as central to strategic planning. The dark factory isn't replacing developers — it's changing what developers do. You become the person who decides what should exist and how well it should work, rather than the person who types it into existence.

Your Four-Week Scaling Plan

Does the Math Actually Work?

Let's be concrete. A mid-level developer costs a company roughly $150,000-200,000/year (fully loaded). A well-optimized dark factory setup:

StrongDM reports spending roughly $1,000/day per engineer on tokens in their unoptimized factory. That sounds expensive until you realize their three-person team ships more code than a conventional team ten times their size. The ROI comes from throughput, not from cheap tokens.

For most teams, a more conservative approach works: $200-400/month/developer on tokens, producing 3-5x the output. That's a ~95% reduction in cost-per-feature compared to hiring additional developers.

Pitfalls When Scaling

Frequently Asked Questions

References

• Orchestrate Teams of Claude Code Sessions — official documentation for Agent Teams: setup, coordination, and best practices
• Manage Costs Effectively — Claude Code Docs — token tracking, team spend limits, model routing, and context reduction strategies
• Common Workflows — Claude Code Docs — git worktrees for parallel sessions, subagent delegation, and session management
• How StrongDM's AI Team Build Software Without Looking at the Code — the original deep dive into a real-world dark factory running at production scale
• StrongDM Software Factory — StrongDM's public-facing documentation of their autonomous software development system
• Unlocking Exponential Value with AI Agent Orchestration — Deloitte — enterprise adoption economics, the $8.5B market projection, and organizational transformation
• Dark Factory Architecture: How Level 4 Actually Works — Infralovers — architectural patterns for NLSpec, holdout-set scenarios, and digital twin universes