tough crowd

Can one engineer merge 500 PRs a week with zero incidents?

One engineer, a crowd of coding agents, and a public scorecard that summarizes every merge, every production issue, every incident, and most importantly the lessons I take away from them.

Follow @ericbouck on X ↗

Why I'm doing this

Eric Bouck
Eric Bouck@ericbouck

Is this a good idea? Maybe? Maybe not? Can I accomplish this in the near future? I think so, but I'm not sure. Will there be incidents? You bet! Hopefully I can keep them to a minimum.

This challenge is all about finding out what it takes and where things break. How to generate enough useful work, knowing when PRs are safe to merge, and catching problems in production as soon as possible.

I want this to be fairly transparent so you can judge for yourself whether I'm building something real. And hopefully we can all learn some best practices from this effort.

I'm using this partly to dogfood my own product, but I'm pretty convinced that most of the lessons will be transferable to whatever coding environment you are using.

Wish me luck!

— Eric

It's impossible to review all the code manually at 100+ PRs a week

How my code review process evolved as my PR volume rose dramatically.

Read the lesson →

Weekly scorecard

Weekly totalsLast 6 weeks · through Oct 19

Weekly scorecard loaded.

Week
Aug 3– Aug 9
Aug 10– Aug 16
Aug 17– Aug 23
Aug 24– Aug 30
Aug 31– Sep 6
Sep 7– Sep 13
Sep 14– Sep 20
Sep 21– Sep 27
Sep 28– Oct 4
Oct 5– Oct 11
Oct 12– Oct 18
Oct 19ongoing
PRs mergedto main
126
111
108
191
157
136
111
117
130
116
54
0
Bugs openedand closed
+2−1
+8−3
+22−23
+53−36
+31−36
+16−23
+12−9
+15
+5−24
+22−24
+2−1
Open bugsat week end
1
6
5
22
17
10
13
28
9
7
8
8
Uptime99.57%
Monday · Aug 3100.00%Degraded12mWeighted downtime0m
Friday · Aug 2892.96%Partially available5h 39mWeighted downtime1h 41m
Wednesday · Sep 292.44%Partially available6h 3mWeighted downtime1h 49mThursday · Sep 381.56%Partially available14h 46mWeighted downtime4h 26m
PRs merged to maintarget 500
111
117
130
116
54
0
Sep 14–Sep 20
Sep 21–Sep 27
Sep 28–Oct 4
Oct 5–Oct 11
Oct 12–Oct 18
Oct 19 ongoing
Bugs opened/Bugs closed
+12−9
+15
+5−24
+22−24
+2−1
Open bugs at week end
13
28
9
7
8
8
Uptime · one square per day100.00%
uppartially availableunavailablefuture
Weekly pull requests, production bugs, open bugs, and average daily uptime
MetricAug 3–Aug 9Aug 10–Aug 16Aug 17–Aug 23Aug 24–Aug 30Aug 31–Sep 6Sep 7–Sep 13Sep 14–Sep 20Sep 21–Sep 27Sep 28–Oct 4Oct 5–Oct 11Oct 12–Oct 18Oct 19–Oct 25 (ongoing)
PRs merged to main126111108191157136111117130116540
Bugs opened2822533116121552220
Bugs closed132336362390242410
Open bugs at week end16522171013289788
Average daily uptime100.00%100.00%100.00%98.99%96.29%100.00%100.00%100.00%100.00%100.00%100.00%100.00%

Fine print

How to read the scorecard

  1. One engineer. It's just me and the agents. Agents are designing, writing, and reviewing all of the code. I step in and give more detailed guidance and reviews for the most critical features.
  2. What counts as a PR. Pull requests can be of all different sizes. They can be anything from a piece of a large feature to fixing the wording on a button. I will soon have commit and LoC metrics so you can judge how significant the average PR is.
  3. Bugs before August. Obviously we had bugs before Aug 3. What we didn't have was a formal bug tracker.
  4. Opened ≠ introduced. The chart shows when we discover bugs and open them. Obviously, that's not the same as when we introduce them.
  5. Incident vs. bug. An incident is a significant impact on the site, not a more localized bug. My goal is to ship at a super-high velocity without taking the site down. There will be bugs that users see. Hopefully we keep them to a minimum and fix them quickly.
  6. Uptime. I'm using Atlassian Status Page's methodology for calculating uptime. During an incident, our system can be unavailable, partially available, or degraded. Unavailable subtracts 100% of the time for the uptime calculation. Partially available subtracts 30% of the time. Degraded does not count against uptime.
  7. Weeks. A week is from Monday to Sunday, Pacific Time. The chart shows partial info for the current day.
  8. Freshness. The numbers are within 10 minutes of realtime. There can be discrepancies in the history when bugs are reopened or issues are reclassified as bugs or not bugs.

Weekly changelog

What shipped last week

October 12, 2026 · October 5–11

Read the full changelog →

Track how much your team ships with Productivity

Productivity shows merged pull requests over time, including how many came through Tough Crowd. Filter by repository and switch between daily, weekly, and monthly views to see how coding-agent work contributes to your team’s output.

A new phone navigation experience

Bottom tabs now put Sessions, Issues, Productivity, and Me within reach, with quick actions for starting a session or creating an Issue. Detail screens have consistent back navigation, and switching tabs preserves your place, filters, and scroll position.

The installed app also supports pull-to-refresh and opens external links separately. Scrolling fixes keep session activity and detail screens usable on narrow displays.

Follow-up changes can open a new pull request after a merge

If the attached pull request merges before the latest session changes reach it, publishing can now open a follow-up pull request for the remaining work. This also handles a merge that happens while publication is being reconciled, so new changes do not get stuck waiting on the already-merged pull request.

Smoother session and Issue creation

Submitting a new session no longer briefly flashes an empty composer while navigation finishes. New Issue text stays visible during creation, and repository names display correctly in the Issue composer.

More reliable GitHub updates and sandbox cleanup

Pull-request synchronization now respects GitHub rate-limit cooldowns, and transient repository-read failures get more accurate retry handling. Branch lookups also handle larger responses.

Sandbox cleanup no longer lets stale observations overwrite a destroyed state, and expected pauses or shutdowns produce fewer misleading evidence warnings.