In the last 30 days, 575 pull requests merged into CompleteCoach. The median time from a PR opening to it merging was 32 minutes. And 99.4% of merged PRs had green checks on their final commit.
Since August it’s been me and a team of AI agents.
I don’t type most of the code, and I don’t read every diff. Sounds reckless, I know. It’s less reckless once you see where the review went. So here’s the setup, the numbers behind it, and the bits that broke along the way.
The numbers
All of this comes straight from the GitHub repo, pulled on 1 November:
575 PRs merged in the last 30 days, the best 30-day window the repo has had.
589 merged in October, the best calendar month so far. Call it 600 if you squint.
Peak week, 19 to 25 October: 238 merged. That’s about a 1,000-a-month pace, for one week.
Median 32 minutes from open to merge. 64% of merged PRs landed within an hour.
99.4% green checks; 878 of 883 merged PRs.
25 releases in 13 days, from v0.2.0 on 18 October to v0.6.0 on 30 October.
Test files went from about 200 to nearly 1,200 between 31 August and 1 November.
First, a correction. I once posted “1,000+ PRs a month”. When I actually pulled the data, that only held for the peak week. No calendar month has hit it. Agents are great at producing output, but you still have to measure it honestly, and that includes measuring yourself. Turns out I’d been quoting my lap record as my average.
The method
The whole thing rests on one shift: I approve intent, not code.
If one person reviews every diff from a team of agents, that person becomes the bottleneck. Approving intent takes minutes. Reviewing a big PR properly takes an hour. So I put my attention where it does the most good.
Step 1: a request and design pair
Every piece of work starts with two documents. The request says what I want and why, in plain language, and ends with acceptance criteria; the exact things that have to be true before the work counts as done. The design maps that onto the product: which screens, which data, who’s involved and what each of them can do.
The acceptance criteria matter more than anything else in the request. They’re how the agents know they’ve finished, and they’re what verification checks against later.
I took this request/design pairing from @poteto. What it really does is get the intent written down before any code exists. Most agent failures I’ve seen aren’t bad code. They’re good code that does the wrong thing. Agents rarely refuse to build something; they just confidently build what they think you meant.
Step 2: interactive mockups of the real app
Next, Claude Code turns the design into a clickable mockup of the actual app, not a wireframe. I click through it the way a coach would and see how my intent turns into screens and flows.
This is where misunderstandings show up, while they cost a paragraph to fix instead of a PR. If a flow feels wrong, I change the design and the mockup regenerates. Rejecting a mockup takes me minutes. Rejecting a finished feature means a rebuild and another full review.
Step 3: the team builds, tests, fixes and verifies
Once I approve the mockup, the agents take it from there. They build it, write the tests and fix what fails. I’m not in that loop. I only step in for two things: key decisions and genuine ambiguity.
Verification is where most of the safety comes from. From the request, the design and the acceptance criteria, the process generates a use case matrix: every actor, every path, and the edge cases that matter. Two it’s caught so far: a to-do list that was meant to show only your own items but showed everyone’s in your organisation, and a meal plan that didn’t save all of its items. An agent then works through that matrix in a real browser on staging, end to end. It’s basically user acceptance testing on every feature, and it catches the stuff that would otherwise bite us in production.
Step 4: gates instead of reviews
The speed is only safe because of the gates. These are the ones that matter:
Nothing merges without green checks. That’s how 878 of 883 merged PRs ended up green.
CompleteCoach now runs on a state machine for every PR. It makes sure each PR is in the right state and actually complete, and when there’s a gap, my AI team has to go fill it before the PR moves on. Nobody gets to wave it through, me included.
A pre-merge check script runs on every PR that’s about to merge. It validates the PR and fixes what it can deterministically, before an agent has to burn time on it. That saves time, gets more merges through first go and stops problems leaking into other work.
Agents merge to staging, not production. 818 merged PRs went into staging. Production only moves through release PRs, and each one needs my yes. There have been 65 of those so far.
Risky changes get labelled and routed to me. Security, tenant boundaries and database migrations each have their own label, so I see them before they ship.
Writing code is cheap now. The engineering is in the gates.
What broke, and what fixed it
None of this worked first time. These are the lessons that changed the setup.
Reviewing diffs didn’t scale. Early on I tried to read everything. Once PR volume climbed I was the slowest part of the system, and the least reliable too, because nobody reviews well on their 40th PR of the day. Fix: move review upstream to the request, design and mockup, and let the checks and the verifier handle the diff.
Parallel agents collided. Once several agents were working at the same time, they started tripping over each other; two going after the same work, or merging and deploying on top of one another. Think pit crew with everyone grabbing the same wheel. Fix: one controller agent hands out the work, and every merge and deploy has to take a slot from it. The agents still run in parallel, but merges and deploys queue up one at a time.
Agents tracked state by hand, and it drifted. They’ll happily carry state around forever if you let them, and sooner or later something gets dropped. Fix: the state machine above. State gets derived and checked, not remembered, and gaps get sent back to the team to fill.
Agents assumed everyone sits at the same screen. This one surprised me. When an action needed a second person’s approval, the agent would pop a modal right there, which is fine if the approver is sitting next to you. A coach and a client are rarely in the same room, and often not on the same continent. Fix: I taught the agents about the physical world. Now the design starts with who needs to act, where they are and which channel reaches them, then builds the handoff as a message or email with one clear action, plus a state that waits for the answer. Approval flows went from an afterthought to the first thing the agents plan.
Speed produced hotfixes. 48 of the 883 merged PRs were hotfixes, about 5%. That’s the cost of moving this fast, and it’s why staging and release PRs exist. A bad change usually gets caught on staging long before a release PR reaches me.
Not every attempt deserves to merge. 103 PRs were closed without merging, and none of the 20 PRs from one batch of experimental agent branches made it in. Closing work is part of the system working. If everything an agent opened got merged, I’d be worried.
Lessons for builders
Approve intent, not diffs. Put your attention on what gets built and let automation check how.
Make the agents show you before they build. An interactive mockup is the cheapest place to find out you were misunderstood.
Write acceptance criteria first, then test against them. Turn them into a use case matrix and verify it in a real browser. Unit tests tell you the code works; the matrix tells you the product works.
Give parallel agents one traffic controller. Running in parallel is where the speed comes from. Merging in parallel is where things break.
Don’t let agents carry state in their heads. Put it in a state machine and make them fill the gaps.
Gate production behind a human yes. Agents can merge to staging all day. Production should only move when you say so.
Tell agents about the real world. They know screens, not distance. Spell out who the actors are and where they are, and the design follows.
Measure honestly. Pull the real numbers before you post them. Mine were good enough without rounding up.
Grow the tests with the code. Test files went up nearly 6x in two months. Make tests part of done, not an extra.
What I’m building
All of this goes into CompleteCoach, coaching software for online fitness coaches, PTs and nutritionists. It covers programs, nutrition, check-ins and client messaging, plus the business side: CRM, tasks and team.
Next up is Aura, coming soon to CompleteCoach. Aura will read each client’s weekly check-in alongside their recent history and give the coach a one-minute read on progress, follow-up priority, data confidence and engagement risk. The coach still makes every decision. We’re designing it with the same intent-first process I’ve described above.
If you coach for a living, come find us at completecoach.fit.