7 Agents, One Weekend: What Happens When You Let an AI Swarm Build Your Product
Seven agents. Six phases. Each in its own git worktree, each with a prompt file and a mandate to ship. One finishes, the next spawns.
By Sunday night: 213 tests passing, 15 Go packages, a fully working CLI tool. Seven concurrent agents, orchestrated by an AI companion, steered by a human with a clear vision.
The Setup
ContentAI is a Go CLI for AI-powered content creation. Voice profiling, article drafting, QA, hero images, publishing, social scheduling. The kind of tool that would take a solo developer two to three weeks of focused work.
Instead, it went to an agent swarm. Each ticket became a Codex agent with a detailed prompt, a fresh git worktree branched from main, and exactly one job. Phase 1 ran four agents in parallel: project scaffold, LLM client, content store, template engine. Phase 2 added the init wizard and knowledge base. Phases 3 through 6 stacked on top as dependencies cleared.
The named insight from this build: "The merge is the work."
What the Agents Actually Did
The agents wrote code. Good code, mostly. The LLM client came back with 80% test coverage and clean provider abstraction. The template engine embedded eight prompt files correctly on the first try. The knowledge base parsed RSS, OPML, and markdown with proper test fixtures.
They also forgot to commit. Three separate agents completed their work, tests passing, code written, and just exited. No commit, no signal. So we built an agent-wrapper script that catches this: when the tmux session dies, it checks for uncommitted work, runs tests, auto-commits if green, marks the ticket done in the tracker.
That wrapper solved the single biggest reliability problem in the entire swarm.
Where It Broke
One agent, the portability auditor, went rogue. Given instructions to "remove hardcoded values and make the codebase portable," it deleted 2,216 lines of working social adapter code. The entire X and LinkedIn integration, gone. Its reasoning: these files referenced external services, therefore they were "hardcoded."
Two legitimate fixes got cherry-picked. The rest went in the bin. The codebase had been clean all along. The agent confused "calls external APIs" with "contains hardcoded values."
This is the failure mode nobody talks about in agent demos. Broad instructions plus eager execution equals destruction. The agent didn't lack capability. It lacked judgment about scope.
The Dashboard Changes Everything
Midway through the build, we hit a problem: agents finishing silently, trackers resetting, no visibility into what was running or stuck. So we built a live TUI dashboard.
agent-swarm status --watch gives you a real-time view of every ticket: status, phase, progress, dependencies. Press r to respawn a failed agent. Press g to approve a phase gate. Press p to switch between projects. It refreshes every second and shows exactly what you need: who's running, who's done, who's stuck.
That dashboard turned a chaotic multi-agent build into something you can actually manage. Without it, you're flying blind. With it, you're an air traffic controller.
The Swarm Worked
Here's the part that surprised me: the swarm mostly just worked. Agents picked up tickets, wrote code, ran tests, committed. The automation chained spawns as dependencies cleared. Phase after phase completed without manual intervention.
The bugs we hit were in the tooling, not the agents. A watchdog script writing to relative paths in the wrong directory. Branch name collisions preventing worktree creation. Tracker state getting overwritten during merges. Each bug got fixed, and the pipeline got more reliable.
By the final phase, the pattern was smooth: agents spawn, agents build, wrapper catches the exit, tracker updates, next wave launches. The human steered. The AI orchestrated. The agents executed.
The Merge Is the Work
Seven agents writing code in parallel produce seven branches that each assume they own the project. Every merge required conflict resolution. The final integration pass needed manual fixes to the command registry because three different agents had added their commands to root.go in three different ways.
Writing code is now cheap. An agent produces a working package with tests in twenty minutes. But integrating seven of those packages into a coherent codebase that builds and passes? That's the engineering.
What Shipped
ContentAI: a portable, open-source Go CLI. Sixteen commands. Pluggable LLM providers. Voice profiling, QA with auto-fix, hero image generation with palette rotation, HTTP and static publishers, X and LinkedIn social adapters, scheduling. 213 tests. Published to GitHub. Installed as an OpenClaw skill.
Built in a weekend by a swarm of agents, a companion who handled the orchestration, and a human who knew where it needed to go.
I'd do it again tomorrow.
