I Let 3 AI Agents Build a Rails Feature. Here's What Broke

The problem

Three AI agents built this coupon form. All thirty seven tests pass, and a reviewer bot read every line of the diff. Now watch the error message. It's green. Today I let a bot lead two coding agents, and I believe none of them until I see the result myself. And at the end, the same ticket against one agent working alone. One ticket, two builders, Codex and Claude Code, each in its own git worktree. And a chief that builds nothing and checks everything.

The solution at a glance

The pattern has three roles. The chief coordinates: it splits the ticket, writes the failing tests and checks the results. Two builders write the code, each in its own worktree. And the board is their shared memory: the brief, the tests, and git.

Eight steps

The run has eight steps. Split the ticket. Write the brief. Write the failing tests and watch them go red. Delegate. Let the builders work in parallel. Run the tests yourself and read the diff. Send back what is wrong. Merge, and run the whole suite once more.

Setup

The ticket, in our demo shop: customers redeem a coupon code on their order, and a code works only once. Today an order has a product and a total, and nowhere to enter a code. The brief is the contract. It fixes the interface, apply coupon on the order, and gives each builder its own files. Part A, model and data, goes to Codex. Part B, controller and Turbo Stream UI, goes to Claude Code. And one sentence, on purpose, says nothing about concurrency: a code works once. AGENTS dot md holds the house rules every agent reads: the commands, the Rails conventions, and one line that will matter. Done means you ran the whole suite, it is green, and you paste the output. Two git worktrees, two branches, one repository. Each builder gets its own directory, so nobody overwrites anybody else's files. And git worktree list shows all three: the main checkout, and one folder for each builder, each on its own branch. In OpenMausBot, three bots. Chief runs on Claude Opus. Builder-A runs on Codex, Builder-B on Claude Code, and each builder has its own working folder: wt-a and wt-b. The chief is the only one I talk to.

Building it

Before anyone writes code, the chief writes the tests: eleven for the model, six for the controller. Thirty seven runs, seventeen errors, all because there is no coupon yet. Red. Now there is something to prove. And the chief found the hole in my brief before a single line of code. A code works once, it wrote, is only true if the database enforces it. So one of its red tests demands a unique index. Then it hands out the work: Builder-A gets the model, Builder-B the UI, each in a thread of its own, both at the same time. Builder-B is done in about a minute. Its report is honest: the suite is still red, because the coupon model is Part A's job, and it says it could not test the Turbo Stream against a real coupon. Builder-A gets stuck. Its question: the controller tests need a route from Part B, so how can its suite ever be green? That one went through me, and then to the chief. Its answer: a mistake in my brief, not in its work. The gate for Part A is everything green except exactly those six route errors. No stub, no touching my tests. And look at the header: teammates working. The run is long over, but that first hand-off never closed. Even the status line needs checking. Builder-A reports done. The chief doesn't take its word for it. It runs the tests itself, in Builder-A's worktree: six errors, all six the missing route. Everything else passes.

Part A, as the chief read it

Then it reads the diff. Codes are unique regardless of case, and an order's coupon is unique too, both in the database. If two requests redeem the same code at once, the loser gets a clean error instead of a crash. Nothing to send back. Merge. Part A first, then Part B on top, no conflicts. And the whole suite, on the merged result: thirty seven runs, a hundred and sixteen assertions, no failures. And in the shop. Spring ten on this order, and the total drops from twenty five dollars to twenty two fifty, in place. The same code on a second order is refused. In green. No test checks a color, and the chief read the code, not the screen.

What the team cost

What did it cost? About thirteen minutes. The chief, a dollar forty two. Builder-B, fifteen cents. Builder-A on Codex, twenty seven cents, from the OpenAI dashboard, because OpenMausBot shows no price for Codex. A dollar eighty four in total. The Claude figures are what the API would charge; I ran them on my subscription.

Gotchas

Where does this go wrong? First, check where your agents really work. In my first try the chief delegated from a group chat, and both builders landed in the room folder, not in their worktrees. The chief caught it and refused to hand out any work.

Where this goes wrong

More traps. A split ticket needs a split definition of done, or a builder can never get green. Give schema dot rb and routes dot rb one owner each. SQLite keeps a test database per worktree for free; with Postgres, name one per worktree. And the chief is a bottleneck: every question waits for it.

Team vs. one session

And now the same ticket, one Claude Code session, alone. Three minutes sixteen, seventy three cents, thirty five tests green. And its error message sits in a red box, with the coupon shown on the order. For a ticket this size, one session wins: four times faster, less than half the price, and the better result on screen.

Wrap-up

So when does a team pay off? When the parts are truly independent, and big enough to run in parallel. The chief earned its keep before any code existed: it found the hole in my brief. But the last check was mine, on the screen. Which task would you give an agent team? Tell me in the comments.