Two people, six AI agents, 296 merged PRs in 12 days

Between October 15 and October 26, 2026, 296 pull requests were merged into Operum's product repository. That's about 25 a day, or about 12 per person per day. There are two of us, running teams of six AI agents.

I'm Alex, one of the two. This post covers what those 296 PRs were, what had to happen before they could merge, and why I think the number is the least interesting thing about them.

The setup

Operum is a desktop app that gives you an AI team with six roles: PM, Architect, Engineer, Tester, Marketing and Community. They work through GitHub: issues, labels, branches, PRs and CI. We build Operum with Operum. Most of what follows is the team working on its own product. If you're starting today, I'd recommend Cursor as the engine: it's the app's default, and each role can run its own model, so the Architect can plan on Grok while the Engineer and Tester work on Composer.

A typical loop looks like this:

1. I tell the PM what I want in plain language.
2. PM files an issue. If it needs design, the Architect reviews it.
3. The Engineer builds it on a branch and opens a PR.
4. CI runs.
5. The Tester (also an AI agent) reviews the change and approves the exact commit it tested.
6. The PR merges. Either one of us clicks Merge, or PM merges it when we've turned auto-merge on for that team.

Mission Control. Screenshot from one of our own Operum projects (v0.58.0, Oct 13, 2026); team name and handles blurred.

The rule that made 296 possible

280 of the 296 merges needed two things: green CI, and the AI Tester's approval of the exact commit being merged. The other 16 were almost all the team's own audit-record files, which skip QA by design.

The second half matters more than it sounds. If the Engineer pushes again after the Tester approves, the approval doesn't carry over to the new commit, so the Tester has to look again. "QA passed on an earlier version" is not accepted.

Here's what the Tester's evidence looks like in practice. It lists what it checked locally, what CI ran, and, just as importantly, what nobody checked:

An issue and its linked PR, with the "not covered by any test" list at the bottom. Handles and a package name blurred.

That last section is the part I read most closely. An agent saying "all 14 checks passed" is easy. An agent saying "these three behaviours are not covered by any test, and here is how to check them by hand" is the one I trust.

What the 296 PRs actually were

PR count on its own tells you very little, so we sorted the PRs by title. This is rough: it comes from titles, not a careful audit of every diff.

About half of everything merged was something a user can see. About a quarter was the team maintaining itself: tests, CI, refactors, and the records and docs the agents use to stay consistent from one session to the next.

That quarter is the tax of running an AI team. A team that doesn't share a memory needs written rules, audit records and guardrails. Someone has to keep them current, and in our case that someone is mostly the agents. I don't think the tax is waste, but I'd be misleading you if I counted those 79 PRs as product.

How that compares

There's no clean benchmark for this, so here are three rough reference points.

A 50-person company two years ago. Our own estimate: such a company might have had 25–35 engineers. At 2–4 merged PRs per engineer per week, that's roughly 100–200 PRs in 12 days. This is our assumption, not measured data. The big caveat is that our PRs are small, so a fair comparison would weigh size, not just count.

AI-native teams at large companies. Anthropic reports that PRs per engineer per day rose 67% with Claude Code adoption, and that 70–90% of their code is written with Claude Code.

A single heavy user. Boris Cherny reported 259 PRs in 30 days. That figure is self-reported.

None of these is like-for-like with two founders running agent teams on one product. What they share is direction: the cost of producing a merged change has dropped sharply.

So what's the bottleneck now?

It's no longer writing code. It's judgement.

Over those 12 days, my time went to:

• deciding what to build next, and what not to;
• reading the Tester's "not covered" lists and clicking through the things only a person can check;
• answering the decision questions the PM brings me ("alerts first or spam filter first?");
• merging, or deciding that today auto-merge can do it.

The founder's whole contribution to this merge is one word. PM's reply still names what hasn't been checked in production.

The Workflow board. Each column belongs to a role. Screenshot from the same project; handles blurred.

When code is cheap, the expensive mistakes are building the wrong thing and shipping something nobody checked. Both are judgement calls. In my experience the agents make the second one rarer, because they say what they didn't verify. The first is still ours.

PR count is the wrong scoreboard

So why lead with 296? Because it's verifiable, and because it's a useful warning sign rather than a trophy. A team that can merge 25 PRs a day can also merge 25 wrong PRs a day. What actually tells you a team is working:

• how often a merged change has to be reverted or re-fixed;
• how much of the output a user can see;
• how long a person waits for a decision they need.

Those are the numbers I'd rather report, and they need a month of data, not 12 days of anecdotes.

What's next

We're launching Operum on Product Hunt on Tuesday, November 10. If you build software and have felt that AI helps with tasks but nobody owns the outcome, that gap is what we're trying to close. Try it, and tell me honestly where the loop breaks for you.

— Alex