Running parallel AI coding agents: how I got to 400 commits a week solo

In seven weeks I pushed 1,439 commits and shipped a working AI product, alone, nights and weekends, alongside my consulting work. Output went from about 70 commits a week to about 400. That 6x did not come from better prompts. It came in three stages: I stopped being the only reviewer, then I stopped improvising and turned the whole thing into a system with governing plans, settled decisions, and a review loop that runs itself. Peer review between AI sessions got me roughly 2x. Systematising it got me the rest.

Almost every guide to building with AI coding agents is really a guide to prompting. I'll just say it: prompting stopped being my constraint weeks ago.

The constraint is trust. You can only ship as fast as you can believe what comes back, and for a while my only mechanism for believing it was reading all of it myself. That works, right up until it doesn't.

Here's what actually changed, measured from git rather than remembered.

Stage 1: I was the bottleneck, and quality was never the problem

For the first three weeks I read every line of AI output myself before anything merged. Every change, by hand.

The work was good. That's the part people get wrong about this stage (and it's why "just review everything" sounds like such reasonable advice). Nothing was broken, nothing was sloppy, and the review caught real things. The problem was arithmetic: I could only move as fast as I could personally read, which turned out to be about 70 commits a week. Weeks one to three ran 73, 71 and 52.

Week three was the slowest stretch of the entire project. That is not a coincidence and it is not a dip in effort. It is what a human review bottleneck looks like when the thing behind it is capable of producing far more than the human can absorb.

Stage 2: sessions reviewing other sessions, which roughly doubled it

The first unlock was giving up the idea that I had to be the reviewer.

I started having AI sessions review other sessions' work, with my input on what to look for, and surfacing only the calls that genuinely needed me. Output roughly tripled week over week and settled at about 150 a week.

This is where a lot of people stop, and I understand why. It feels like the whole answer. Sessions can critique each other, the obvious errors get caught, and your throughput goes up immediately. But it is only half a system, and the half it is missing is the one that compounds.

Stage 3: the part that actually produced the 6x

The second unlock was stopping the improvisation.

Up to that point every session got a hand-written brief, and I was the only thing holding the shape of the work in my head. Turning that into a system took six pieces.

If you're starting Monday, build them in this order. The written record of decisions first, because everything downstream reads from it. Then one session in charge. Then the mechanical checks. The rest can wait.

Two documents everything obeys. A strategic plan carrying the product thesis, the market read, and what actually makes this different. Under it, an execution roadmap. Both are versioned in the repo and both get revised constantly, roughly 80 times each so far.

A written record of settled decisions. Sixty-two ratified rulings, each one a call I made that no session is allowed to relitigate. The format matters: when I change my mind, the entry gets rewritten in place rather than patched with an exception. I learned that the hard way. A register full of amendments-to-amendments is unreadable, and unreadable law gets ignored.

One session in charge. It writes the brief for each work stream, reviews every change before it lands, merges, and spawns follow-on work when a session turns something up. It runs on the strongest model available because this is the seat where judgment actually happens.

A review loop that runs itself. That session re-arms its own watch on a 30 to 45 minute cycle. It re-derives state, checks the running streams, and most passes send nothing at all. The point is not constant intervention, it is that nothing sits unnoticed for a day because I got busy.

Model tiering per stream. The top tier for thinking, evaluation and the review seat. A mid tier for execution. A cheaper tier for well-specified mechanical work. Every brief carries an explicit model recommendation with a one-line reason, so the choice is deliberate rather than habitual.

Prove one, then fan out. Nothing scales until a single instance is proven end to end, by hand, by me. The last large wave went one pilot, then three sequential provers each de-risking a different pattern, then parallel batches, then eighteen of eighteen done. Fan out before the pilot is proven and you find the flaw fourteen copies later.

The number that justifies all of it

About half of what comes back from a working session has something wrong or stale in it.

Not obviously broken. Confident, well-organised, and off in some detail you have to go looking for. This is the thing nobody tells you about running multiple AI coding agents in parallel: you do not get parallel work, you get parallel confidence. That single figure is the entire argument for a review seat, and it is why the checks are mechanical rather than cultural. Thirty-two named failure modes live in the repo, each one ending in a command to run rather than advice to remember.

Because here is the thing I keep relearning: knowing a failure mode by name does not stop you committing it. Sessions have written up a failure mode and made its sibling mistake two hours later. Guards, not goodwill.

The clearest example: a change that would have silently deleted every second tip in a core flow. No type error. No failing test. It was caught only by deliberately reinserting the old defect and watching whether the guard fired. If the guard had been a code review comment instead of a command, that ships.

What it does not do

It does not replace my judgment. It stops wasting it.

The system's real job is surfacing the handful of calls that genuinely need me, in a fixed shape: situation, recommendation, and the specific weigh-in needed, ideally answerable in one word. Everything else gets decided against the written record without me.

Two to four streams run at once, seven at peak. I am still the only human on it. I make more decisions per week than I did in stage one, and I read almost none of the code.

The product this built

It is called Build Me, it is free, and it is at build-me.org.

It helps people work out which career actually fits them by doing the work rather than reading about it, through day-in-the-life simulations and real projects run with an AI assistant. If you try it, tell me where it is wrong. And if you know someone working out their direction, a teenager, a new grad, anyone mid-switch, I would genuinely like to interview them.

Common questions

How do you stop parallel AI coding agents from breaking each other's work?

Isolated git worktrees, one change per session, and a single reviewing session that holds the merge. The isolation stops them writing over each other mechanically; the review seat stops two individually-correct changes from combining into something broken.

Does this only work because it is a side project with no users?

Partly, and that is worth saying plainly. Pre-launch means no production incidents competing for the review seat's attention. But the constraint the system solves, more capable output than one person can verify, gets worse with scale, not better.

What is the honest gap in the measurement?

Wake cycles are not logged as first-class events. They are reconstructable from commit clusters and close-out notes, but there is no telemetry, and the same is true of model routing. So "it wakes every half hour" is configuration plus scattered receipts, not an instrumented log. The commit and pull request counts are exact.

Would you run this on a team instead of alone?

The layer that would change is the decision register, which currently only has to satisfy me. With more humans it needs a ratification path that is not one person's judgment. Everything else, the review seat, the mechanical gates, the ledgers with owners, gets more valuable with more parallel work, not less.