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 31

Weekly scorecard loaded.

Week
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 19– Oct 25
Oct 26ongoing
PRs mergedto main
111
108
191
157
136
111
117
130
116
54
39
36
Bugs openedand closed
+8−3
+22−23
+53−36
+31−36
+16−23
+12−9
+15
+5−24
+22−24
+2−1
Open bugsat week end
6
5
22
17
10
13
28
9
7
8
8
8
Uptime99.60%
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
117
130
116
54
39
36
Sep 21–Sep 27
Sep 28–Oct 4
Oct 5–Oct 11
Oct 12–Oct 18
Oct 19–Oct 25
Oct 26 ongoing
Bugs opened/Bugs closed
+15
+5−24
+22−24
+2−1
Open bugs at week end
28
9
7
8
8
8
Uptime · one square per day100.00%
uppartially availableunavailablefuture
Weekly pull requests, production bugs, open bugs, and average daily uptime
MetricAug 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 25Oct 26–Nov 1 (ongoing)
PRs merged to main111108191157136111117130116543936
Bugs opened8225331161215522200
Bugs closed323363623902424100
Open bugs at week end65221710132897888
Average daily uptime100.00%100.00%98.99%96.29%100.00%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 19, 2026 · October 12–18

Read the full changelog →

Easier filtering and sorting on your phone

Sessions and Issues now have redesigned phone controls for filtering and sorting, with clearer sort choices and direction controls. The iPhone tab bar also stays in position more reliably, with more consistent icon sizing.

The New Issue form places repository selection below the description and lets long repository names wrap. Desktop navigation also clears its scrollbar correctly after menus close.

See changed-file counts before opening Files

Coding sessions now show the number of changed files without requiring a visit to the Files tab first. The count also recovers after missed live updates, keeping the session navigation in sync with the work.

Source code stays out of session replay recordings

Source-code displays are now blocked from the app’s usability replay recordings, protecting code shown in file and diff views while preserving the surrounding interface for diagnosing usability problems.

New guides for getting started and evaluating Tough Crowd

The public site now includes a getting-started guide, pricing information, and expanded security documentation. Setup examples cover agent credentials, model selection, and automatic Review configuration and instructions.

Navigation menus work more reliably on older iPads and remain reachable in short browser windows. Public pages also have new social-preview cards for sharing.