Eight AI Builders, One Afternoon, and a Live Client Site (How Parallel Agents Actually Work)

TLDR

At 3 PM on September 22, I sent one long message about the Oregon Ghost Conference’s live site. By a little after 9 PM, one lead AI agent and eight AI builders working in parallel had shipped a cleaner menu, a rarer ghost, a second haunt performance with its own phone version, printable class rosters, a fixed ticket date, a door register that takes cash, cards, and Tap to Pay, and five paid extras built, tested, and switched off. That’s 81 commits on the public site and 41 on the dashboard that day. The trick isn’t the agents. It’s how the work gets split so nobody steps on anybody, and who’s allowed to touch production. Here’s the setup, and the honest list of what parallel agents are still bad at.

The Message at 3 PM

It wasn’t a spec. It was a list of everything I wanted done, in one breath:

• Clean up the navigation, because the menu had gotten crowded and the EMF meter was sitting on top of the year next to the logo
• Make the ghost rare, on a clock that runs across the whole site instead of restarting on every page
• Add a new ghost act where the figure peeks in, looks around, and dashes across the screen, in a wide version for desktop and a vertical version for phones
• Build everything left on the project list, including an in-person register for selling passes at the door

That’s four or five days of work for one developer, maybe more. And it’s all on a live site with real ticket buyers.

Why Parallel Is Hard

The obvious move is to throw more agents at it. The obvious problem is that agents working on the same thing at the same time behave exactly like people working on the same thing at the same time, only faster.

• Two builders edit the same file and one overwrites the other.
• Two builders run the same database change.
• One builder deploys half-finished work while another is testing on the live site.
• Nobody knows which version is the real one.

I learned the deploy part the hard way back in April, when a copied config file came within one command of shipping the wrong project onto a live site. That near-miss is why a rule in my harness says the deploy target gets stated out loud before anything ships.

So parallel work needs three things: separate copies, separate lanes, and one owner for anything that touches production.

Worktrees: One Copy Per Builder

Git has a feature called worktrees. It lets one repository have several working folders at once, each on its own branch. Think of it as giving every builder their own desk with their own copy of the project, while everything still lives in the same filing cabinet.

Every builder got its own worktree: its own folder, its own branch, its own copy of the code. A builder working on the ghost’s timing couldn’t accidentally overwrite the builder working on the menu, because they weren’t editing the same files on disk. Their work only met when the lead merged it.

The split followed the work:

• The menu
• The ghost’s site-wide clock
• The new ghost act
• Banner images and printable rosters
• A schedule solver for next year, built from rules pulled out of the founder’s own planning recordings
• A cleanup tool for vendor and speaker bios
• The door register
• The paid extras: a two-way venue map, a raffle for people who catch the ghost, and reminder and review emails

The Lead’s Job

The lead agent doesn’t build features. Its job is the part that makes parallel work safe:

1. Split the work into lanes that don’t share files. If two tasks had to touch the same file, they went in the same lane.
2. Brief each builder with its own checklist. What done looks like, and how to prove it.
3. Review every branch before merging it. Not just “does it build.” Does it do what the checklist says.
4. Merge one at a time, so a problem shows up next to the change that caused it.
5. Own every deploy. Builders never touched production. Only the lead shipped, and it checked the target every time.
6. Verify on the live site after each deploy. A passing build is not proof. The live site doing the thing is proof.

That last one matters more than anything. The lead’s job is the job a senior engineer does on a team: less typing, more checking.

What Shipped by 9 PM

Everything below was checked on the live site after it deployed:

• A new “More” menu that moves the lower-traffic links out of the way. A QA script checks that nothing overlaps at any width from 1024 to 1920 pixels: 17 of 17 checks passing on the live site.
• A rarer ghost. The apparition now runs on a clock of visible time across the whole site. First sighting somewhere between one and three minutes in, then every five to twelve minutes, and page loads never reset it. The timing QA passes 14 of 14.
• A fix for an invisible error. The ghost’s code ran a tiny test to decide which format it could play, and the site’s security rules were blocking that test, which logged two errors on every page. Now it tests without the blocked request: zero errors.
• The second act. The figure peeks in, looks around, and dashes across the screen, with smoke hitting the far edge. Phones held upright get their own vertical take, because the wide version left the figure about 175 pixels tall. A forced sighting passed on the live site on both desktop and phone, and when the real scheduler ran, it picked the new act in four of six tries.
• Banner images on every profile and class page, and printable class rosters in the instructor portal.
• A data fix: one ticket type still showed last year’s dates in checkout, confirmation emails, and the attendee portal. Corrected and audited.
• One sender for every email. Sign-in links, order confirmations, and reminders now all come from the conference’s own director address. The proof was a live sign-in email at 9:00 PM with the sender’s authentication checks all passing.

On the dashboard side, production deployed twice that afternoon, the second time with the door register.

Built but Switched Off

Five of the lanes built features the client hasn’t bought yet: the two-way venue map, the ghost raffle, reminder and review emails, the bio cleanup tool, and the first-pass schedule for next year.

They’re done, tested, and off. Each one sits behind a switch in three separate places: a file on the public site, a file in the dashboard, and a setting on the server. The production build never flips any of them on, so they can’t turn on by accident.

Each one also has a live demo copy, so the client can click through the real thing before deciding whether it’s worth paying for. The schedule solver, for instance, rebuilt this year’s schedule with 67 of 67 sessions placed and zero hard rule violations.

This is my new favorite way to sell. A proposal describes a feature. A working demo sells it.

Two Reviews Before the Money Path

The door register was the one lane that got extra scrutiny, because it takes real money from real people standing at a real door.

It went through two separate review rounds before shipping, and both found real problems:

• Making sure a cash sale can’t be recorded twice
• Tying each Tap to Pay payment to exactly one sale, confirmed by the last four digits of the card
• Holding the seat from the moment the tap starts, so two people can’t buy the last one
• Locking down the test accounts used to set it up
• Showing “charged, refund owed” clearly at close-out if something goes sideways

After it deployed, the lead ran a check that touches no money: send a random order reference and confirm the register refuses it cleanly. It did.

What Parallel Agents Are Still Bad At

Here’s the honest list, including what that afternoon didn’t prove.

Real phones. Every phone test that day ran in browser emulation, not on actual iPhones and iPads. The fix for a faint haze that used to show up only on real iPhones is unconfirmed on real hardware. I’ll trust it when I’ve watched it on a phone in my hand.

Anything that needs a real card. The register’s Tap to Pay path was built and reviewed, but the client’s account has never taken an in-person payment. One real sale and one real refund at the door, before the conference, are on my list, not the agents’.

Taste. The agents can build the new ghost act. They can’t tell me whether it’s scary. That call is mine, from the recordings, not theirs.

Decisions that belong to the client. How co-taught classes split instructor payouts, what the raffle prize is, which rooms hold how many people. The agents flagged every one of those instead of guessing, which is exactly right, and they’re all waiting on people now.

The lead’s attention. Eight builders produce a lot of branches. The lead’s review is the bottleneck, and if it gets sloppy, parallel work just produces bugs faster. More builders isn’t automatically better. More builders than the lead can properly review is worse.

The research for this series of posts ran the same way, for what it’s worth: six research agents in parallel, each reading a different part of my notes and history, and one lead pulling their findings together. Same rules. Separate lanes, one owner, and every claim checked against a source.

How to Try This Without Breaking Anything

If you want to run parallel AI builders on something real, start smaller than eight:

1. Start with two lanes. Two tasks that clearly don’t touch the same files.
2. Give each one its own worktree. Separate folders, separate branches. No shared desk.
3. Write a checklist for each lane before it starts. What done looks like, and the test that proves it.
4. One owner merges. One owner deploys. Builders never touch production.
5. Put anything the client hasn’t approved behind a switch, and give it a demo copy.
6. Double-review anything that touches money, logins, or personal data.
7. Check it live after every deploy, and write down what you couldn’t check.

The speed is real. But the speed comes from the structure, not from the number of agents. Eight builders with no lead is chaos. Eight builders with a good lead is an afternoon.

I appreciate you reading through this one. If you’ve got a site or a system that needs a lot built without anything breaking, that’s exactly the kind of work I do. Book a call from the home page, or see the Oregon Ghost Conference build for the full story of the platform this afternoon was built on.

Build first, learn fast.