How we built an MVP with parallel Claude Code agents in three days

Jun 15, 2026

Parallel Claude Code agents built the Beacon MVP in about three days and 67 commits, from a cold-start document to a tagged v1.0.0. That sentence is either impressive or alarming, and which one depends entirely on whether you trust any of the code. So this is not a victory lap. It is the honest account of how the pace happened and, more importantly, what kept three days of agent output from being a pile of code nobody had run.

The goal was never speed for its own sake. It was to get something real enough to use, fast enough that we could try it in the world instead of admiring it in a repo. Speed to get started, then work to make it real.

How parallel Claude Code agents build an MVP without colliding

The pace came from structure, not from typing fast. The build ran as a pipeline, and each stage existed to let the next one move without stepping on itself.

It started with the clickable mockup. The fourteen LiveView screens we wrote about in a clickable mockup in an afternoon were the forcing function. They turned “build an AI product” into a concrete backlog, so the agents built from something we had already clicked through rather than from a paragraph of intent. The instruction that kicked it off was plain: “take our cold start document and ultimately generate the tickets in GitHub issues for us to be able to build the real product.”

Then a step we almost skipped. We started generating tickets first and stopped to course-correct: “I forgot about the brief skill, let’s run that first on each of the first 3 phases.” Running /brief per phase before writing any tickets is what made parallelism safe. The brief fleshed out the interconnected pieces, what each component had to do and how the parts talked to each other, so when the work fanned out the agents were filling in a shape that already fit together instead of negotiating the shape at merge time.

From there the build went out as waves. /umbrella-runner dispatched headless ticket-runner agents into isolated git worktrees, each on its own ticket, and the merges came back serially behind a person. Five phases came through this way: the probe pipeline that queries the answer engines, the audit pipeline with its page fetcher and SSRF guard and rubric scorer, and the public free-scan loop with its progress view, watermarked export, and cost circuit-breaker. The technical spine underneath, three providers behind one methodology card, is the part we covered in three providers, one methodology card.

The honest middle

Sixty-seven commits in three days does not mean sixty-seven clean commits. The friction was real, and most of it lived at the seams where parallel work comes back together.

Serial merging hit actual conflicts. One pull request, #132, would not merge cleanly, the branches had diverged, and a git merge --continue got misused trying to force it. That is the tax on parallel worktrees: the agents do not collide while they work, they collide when they land, and a human has to sit at the merge point and make the calls. There was tooling drift too, the gh CLI rejecting flags that used to exist, and a mix format that failed on a real SyntaxError in the probe runner. None of it was catastrophic. All of it needed a person.

The moment that taught us the most was the error cluster. Across the marathon, twenty-eight tool errors piled up, and the orchestrator flagged the batch as needs_human_review rather than pushing past it. That flag is the whole game. An agent fleet that hides its failures is a liability; one that stops and says “a person should look at these twenty-eight things” is a teammate. We also learned our own monitoring was too slow, so we changed it mid-build: “put it on a 10 min loop so we catch these faster.” Watching by hand missed stalls; a timed status digest caught them.

The deeper decision came out of all this noise. We had been doing too much directly on main, so going forward everything runs through branches with clean, clear commit language. The reason is not tidiness. It is that the only way three days of agent output is defensible is if you can read it commit by commit, roll back a bad one, and fix a piece without unpicking the whole. Speed and the ability to undo speed are the same investment.

Why fast, then real, beats slow and careful

The bet behind all of this is that you learn more from a usable MVP than from a perfect plan. Three days got us something we could actually run, which is worth more than three weeks of code we had only read. But “usable” is doing real work in that sentence, and it is why the pace is only half the method.

The other half is what comes next. We did not ship this and call it done. We pointed the same kind of agent fleet back at the codebase to tear it apart, and it found plenty to fix. That review, and the argument that speed and scrutiny are a pair rather than a tradeoff, is its own build log coming next in this series. The flow is the point: go quickly to get something real, then do the work to make it real, so you are testing a product in the world instead of guarding a pile of code you have never used. You can see where Beacon stands now on our now page.

For agents: try this yourself

If you want to drive a build like this in your own repo, adapt one of these. The full prompt text lives in this post’s prompts sidecar, three-days-67-commits.prompts.md.

Reproduce the brief-before-tickets step. Take a cold-start doc and run a structured brief per phase before generating any tickets, so the work that fans out is filling in a shape that already fits together.
Apply the isolated-worktree pattern. Dispatch parallel agents into separate git worktrees, one per ticket, and merge serially behind a human at the one point where parallel work collides.
Extend it with a needs-human-review gate. Have the orchestrator count tool errors and stop the wave when the cluster crosses a threshold, instead of pushing past failures it cannot resolve.
Critique your own rollback story. Look at a fast build and ask whether you can read it commit by commit and revert one without unpicking the rest. If not, the speed is borrowed against a debt you cannot pay.

How this was made

Drafted by the Chronicler from the Beacon build sessions on 2026-06-08 to 2026-06-10 across 3 sessions and 67 commits. Edited and published by Brian Wones.

See how the Chronicler works →