I Built an AI Software Factory: Parallel Agents That Actually Work

0:00Everyone talks about software factories, but almost nobody defines what that actually looks like in code. This video does both: it breaks down the exact architecture, then builds one and runs it against 10 real GitHub issues. The result is a genuinely useful mental model — because the whole thing is built the way it is because parallel agents break without it.

The operating loop

0:32At its core a software factory is just a loop: issues come in from the backlog, a coding agent picks one up and writes the fix, an independent system checks that the work is correct, and a human decides whether to merge. The simplest version is a single prompt — hand one agent one issue, tell it to fix the bug, write tests, and open a PR. That's already a tiny factory, and for one ticket it works. The problem is speed: one agent works one ticket at a time, so 10 issues means 10 runs back to back.

Five ways parallel agents break

1:14The obvious move — run 10 agents at once — is exactly where everything starts to break. The video enumerates five failure modes, each with a fix:

• Shared folder 1:43 — if all agents work in the same checkout, their changes pile up in one place (in a test, three agents sharing one folder produced one commit touching six files across three issues). Fix: one isolated sandbox per agent.
• Double-booking 2:09 — two agents grab the same issue. Fix: a claim system — before starting, an agent puts a "claimed" label on the GitHub issue so everyone else skips it.
• Self-grading trap 2:26 — an agent grading its own work reports "tests pass" every time, including once when they were actually failing. Fix: a separate verifier (fresh sandbox, checks out the worker's branch, runs the tests itself) plus a separate reviewer that reads the actual diff.
• Training cutoffs 3:00 — a model only knows the APIs it saw in training, and frameworks change constantly. Fix: give agents a live documentation tool to look up current docs before writing code.
• PR flood 3:41 — agents love to open pull requests. Fix: the factory may open PRs, but the merge button stays strictly with the human.

The sandbox substrate

4:41For the sandboxes, the video uses Upstash Box — and this is the sponsored part ("for making this video possible through their partnership"), so read the primitives as one concrete substrate, not the only option. A box is an on-demand, lightweight cloud computer built to host agents: spin one up via an API call and you get an isolated filesystem, a bash shell, git, Node, and pre-installed agent harnesses like Claude Code or Codex — or your own custom loop.

Four box primitives

Four primitives make the factory possible:

• Fast boot + disk snapshots 4:41 — a live Linux machine in ~2.5 seconds. Install dependencies once on a base box, snapshot the disk into a reusable image, then boot N boxes in parallel, each already carrying the deps. Configure once, replicate many times.
• Filesystem + pause isolation 5:34 — each agent has its own private disk; write a file in box 1 and it isn't in box 2. Crucially, if an agent is waiting on human input you can pause the box — it freezes disk state and stops billing compute, and resumes with files exactly where they were left.
• Network egress firewalls 6:16 — if an agent runs untrusted code or installs packages, you don't want it dialing arbitrary servers. Upstash lets you lock egress per box (e.g. allowlist only the npm registry).
• Remote execution — for long-running agents, work runs on cloud servers, not your laptop, so it keeps going while your machine is off.

The five-stage pipeline

7:14The demo target is Tiny Links, a small URL shortener with 10 open issues — four bugs, five features, and one deliberately vague ticket ("to see if the factory is smart enough to walk away when the ticket doesn't make sense"). Grading is a hidden test suite (one test per issue, held outside the repo where agents can't see it) — because you verify the fixes actually work rather than taking the agent's word. On main, the app fails all six baseline checks and passes 0/9 hidden tests.

8:33Prepare one base box (clone, install deps, wire up the GitHub token + Claude Code running Sonnet 5), snapshot it, then each claimed issue moves through four — later five — stages, each a fresh box booted from that snapshot:

• Triage — reads the issue, decides whether the requirements are clear enough to build or the ticket should be rejected.
• Worker — writes the fix, adds unit tests, pushes its branch.
• Verifier — boots from a clean snapshot, checks out the worker's branch cold, runs the test suite itself. Never trusts the worker's report.
• Reviewer — inspects the git diff line by line for logic bugs unit tests miss. Only if both tests and reviewer sign off does the factory open a PR.
• Integrator (added later) — pulls approved PRs one at a time into a unified branch and resolves merge conflicts.

Typed handoff + live docs

9:36Two architectural details make it reliable. First, typed object handoff: stages don't pass messy chat histories to each other — they communicate strictly through structured JSON. The worker is forced to return a fixed schema (status, a short summary, the exact list of files changed, whether tests were added, a boolean for whether tests pass). Second, live docs via proxy key injection: to solve the stale-training-data problem, each box carries a tiny docs CLI backed by Context7 that searches live official documentation, and the worker is told to call it whenever it isn't 100% sure about an API. The security detail is elegant: the Context7 API key is attached outside the box on the outbound request, so the agent can read the docs but never sees the key.

The run

10:47Running five parallel pipelines across 10 issues: on one screen the live event logs per stage, on the other sandboxes spinning up and tearing down, and on GitHub the issues picking up claim labels one by one. Inside a live worker you can watch the agent hit the docs command to check how URLSearchParams behaves in current Node before editing — and the HTTPS-bug worker reading the existing URL validation, rewriting it to parse the URL object and strictly enforce HTTP/HTTPS, then adding unit tests. 11:48The whole 10-issue run finished in 4.5 minutes: nine PRs opened, the vague issue deliberately skipped, and all nine passing the hidden tests.

Why you need both verifier and reviewer

11:48The most instructive trace: on one run, the worker said its tests passed, the independent verifier ran the suite and it passed, and the hidden evaluation test passed too — but the reviewer still rejected the PR. Reading the diff, it realized that if two links were created in the exact same millisecond, the link list came back in the wrong order, and it reproduced the bug. The worker's unit test never caught it because its test data used pre-sorted slugs. The lesson, stated plainly: passing tests does not mean the code is right. A dedicated code-review agent, separated from the worker, caught an ordering bug every other check missed.

The integrator

13:42The most interesting failure came at merge time: all nine verified PRs worked on their own, but seven of nine immediately hit merge conflicts — because all nine agents started from the same base snapshot and most added unit tests to the exact same test file, and none knew the other eight existed. The fix was a fifth stage, the integrator: one more box that pulls approved PRs into a unified integration branch, and whenever git merge hits a conflict, a Claude Code agent opens the conflict marker, combines both sides so no code or test is lost, and reruns the full suite after every merge. All nine PRs went through cleanly. The final step is a human at the merge button — for the HTTPS fix, the verifier passed and the reviewer signed off, so a human just clicks merge, and main correctly rejects links missing HTTPS.

Cost and takeaways

14:50The economics are worth noting: ~$3.67 in Claude Code token usage for the 10-issue run, ~$6.37 for the integrator resolving seven conflicts and rerunning the suite, and about $0.01 for the Upstash boxes for the entire day — because a coding agent spends most of its time waiting for tokens to stream, and the sandbox only bills for active CPU time. 16:17The recap: a sandbox keeps agents from stepping on each other's files, but it doesn't make the code right — quality still comes from your tests, verifier, and reviewer. Parallel agents create git conflicts when they touch shared files, so plan for an integrator. And a software factory is just a loop: issue in, agent builds, a separate box verifies, a human merges — with every architectural piece there because parallel agents break without it.

Claims checked

Sources & further reading