How I Merged 141 Pull Requests in One Day

Yesterday, Saturday, November 14, my GitHub account created 145 pull requests across four repositories, and merged 141 of them. Every one of the 141 was also created that day. I didn’t write any of the code. Teams of AI agents did, and other agents reviewed it.

I have written about the tools and the job before. This post is about one real day: the count, what ran, what I did, and what comes next.

The count

All four repositories are private, so I give numbers, not links. I counted with gh search prs, by creation date and by merge date, from midnight to midnight Central time.

Repository	Created	Merged
Astrohacker	65	65
ahfact	38	37
Botpenny	23	20
ryanxcharles	19	19
Total	145	141

Two details matter. First, no merged pull request was left over from an earlier day: each repository’s merged count equals its count of pull requests created and merged the same day. Second, of the four that didn’t merge that day, one in ahfact merged the next morning, and three in Botpenny are still open.

One repository, start to finish

I can show the most detail for this site, ryanxcharles, because its whole record is in its own repository: issues, pull requests, reviews and the release journal.

The first two issues opened at 5:36 a.m.: a post and its cover. The last pull request merged at 3:31 p.m. In between, 19 issues were filed and 19 pull requests merged. The deploy role published 18 releases of the site and verified each one over HTTPS.

The work was ordinary for this site, which is the point:

• Four posts, each with a pair of covers, including Rent the Factory or Own It? and Industrial Revolution 2.0: The One-Person Factory.
• Design changes: the CV timeline labels, the Light-mode hero, a new style for every Astrohacker ad, post-card hover and a new band on the home page.
• Tooling: the cover check in the test suite, faster browser tests and automatic retries for a flaky deploy check.

From filing to merge, the median issue took 34 minutes. The fastest took 9 minutes and the slowest 102.

Who did the work? Every pull request records the agent that wrote it and the agent that reviewed it. Claude Code coding workers wrote 10, Codex coding workers wrote 5, and Codex image workers made 4 cover pairs. Claude Code reviewers passed 12 and Codex reviewers passed 7. In 6 of the 19, the author and the reviewer ran in different harnesses.

Reviewers asked for changes 6 times. Each time, the author fixed the findings in one revision, and the pull request then passed. No pull request needed a second round.

What was running

The same kind of multi-agent workflow ran in all four repositories. For this site, the tool is rxc, and the rules live in its AGENTS.md and .agents/skills/.

• One issues session. I talk to it. It researches, checks for overlap and files each issue with a clear outcome and a way to verify it.
• Role sessions. Separate code, review, image and deploy sessions ran at the same time, in Claude Code and Codex.
• One worker per item. Each role session watches GitHub. When an issue or pull request becomes eligible, it claims it and starts one worker, which stays with that item through merge and cleanup.
• The flow. A coder works in its own linked worktree and opens a pull request. A reviewer in a separate session, often in a different harness, checks the exact commit and merges it. The deploy role releases each merged revision and verifies it over HTTPS.

They coordinate through the repository.

The rules do the supervising

141 pull requests in a day is too many for me to read. I don’t try. The tool enforces the rules that make the output trustworthy, the way I argued in Verification Is the New Programming:

• Claims and leases. One worker holds each item. If it goes quiet on its turn, its lease runs out and another session can take over.
• Unanswered discussion. A pass or merge is refused while the pull request or its issue has a question or decision the author hasn’t answered.
• /rxc-approve. Some issues need my own approval comment on the current commit before they can pass. Agents never post it.
• Covers first. A post is linked merge-after its cover, so it can’t merge until the cover does.
• test:affected. Each change runs the browser tests mapped to what it touched.
• No reduced motion. A scanner fails the tests if anyone adds code that turns the site’s motion off.

The rules also changed during the day, by the same process. At 9:09 a.m., a release stopped and waited for me: a network timeout during the check of production before publishing. Nothing had been published, and the site was healthy. A minute later, issue #295 was filed to retry network-only failures instead of holding for me. Its fix merged at 10:03 a.m.

The browser tests got the same treatment. That morning, #297 split them into a quick smoke suite and runs mapped to each change. A post’s change went from the full 18.8-minute suite to 47.8 seconds plus the build.

What I did

I gave direction. I told the issues session what I wanted, in plain language, and said “file it”. Every one of the 38 issues and pull requests in this site that day carries only comments signed by agents. My words reach GitHub quoted in the issues, as “Ryan’s direction”.

I made taste calls. In the morning I asked for a “marbled endpaper” look for the Light-mode hero. It merged at 10:21 a.m. I didn’t like it. The next issue records my verdict, “horrible”, and asks for plain paper again. That merged at 10:53. Changing my mind cost half an hour and no code from me.

I approve designs and handle holds when they come up. That day, none of the site’s issues needed my /rxc-approve, and the only hold was the deploy timeout, which became an issue of its own.

Two posts in 22 minutes each

The best example from the day is the fast lane for posts. A post issue and its cover issue are filed together. The image role makes the cover while a coding worker researches and writes the post. The post can’t merge until its cover does.

Industrial Revolution 2.0 went from filing to live in 22 minutes. The two issues opened at 2:09 and 2:10 p.m. The cover pull request opened at 2:15 and the post’s at 2:19. The post merged at 2:30 and was verified live at 2:31.

An hour later, Delegate All Your Grunt Work to AI Agents did it again. Both issues opened at 3:10 p.m., both were claimed at 3:12, the post merged at 3:31 and it was live at 3:32. Its reviewer left two notes, and the writer answered them before the merge.

Both posts beat a 45-minute target by more than half.

What comes next: the Astrohacker factory

Today this workflow is a set of role sessions, a tool per repository and rules in AGENTS.md and skills. It works, but it is still a workshop: each repository has its own tool, and I start each role session myself.

The next step is the Astrohacker factory. We are turning this workflow into a factory at Astrohacker: more automated, and run across many repositories instead of one at a time. In Inside the Software Factory That Writes All My Code, I described its shape: a graph where each item ends either deployed or waiting for a person, and agents that ask the factory for work. Most of the parts already existed then. The factory isn’t done, and I’ll write about it when it is.

141 pull requests in one day is where this workflow is today. The factory is how it gets better.