tough crowd

The 1/500/0 Challenge

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 Sep 13

Weekly scorecard loaded.

Week
Jun 22– Jun 28
Jun 29– Jul 5
Jul 6– Jul 12
Jul 13– Jul 19
Jul 20– Jul 26
Jul 27– Aug 2
Aug 3– Aug 9
Aug 10– Aug 16
Aug 17– Aug 23
Aug 24– Aug 30
Aug 31– Sep 6
Sep 7ongoing
PRs mergedto main
8
75
122
161
126
84
126
111
108
191
157
133
Bugs openedand closed
+2−1
+8−3
+22−23
+53−36
+31−36
+16−23
Open bugsat week end
0
0
0
0
0
0
1
6
5
22
17
10
Uptime99.51%
Monday · Jul 2794.48%Partially available4h 25mWeighted downtime1h 20mFriday · Jul 3197.78%Partially available1h 47mWeighted downtime32m
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
126
111
108
191
157
133
Aug 3–Aug 9
Aug 10–Aug 16
Aug 17–Aug 23
Aug 24–Aug 30
Aug 31–Sep 6
Sep 7 ongoing
Bugs opened/Bugs closed
+2−1
+8−3
+22−23
+53−36
+31−36
+16−23
Open bugs at week end
1
6
5
22
17
10
Uptime · one square per day99.21%
uppartially availableunavailablefuture
Weekly pull requests, production bugs, open bugs, and average daily uptime
MetricJun 22–Jun 28Jun 29–Jul 5Jul 6–Jul 12Jul 13–Jul 19Jul 20–Jul 26Jul 27–Aug 2Aug 3–Aug 9Aug 10–Aug 16Aug 17–Aug 23Aug 24–Aug 30Aug 31–Sep 6Sep 7–Sep 13 (ongoing)
PRs merged to main87512216112684126111108191157133
Bugs opened0000002822533116
Bugs closed0000001323363623
Open bugs at week end000000165221710
Average daily uptime100.00%100.00%100.00%100.00%100.00%98.89%100.00%100.00%100.00%98.99%96.29%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

September 7, 2026 · August 31–September 6

Read the full changelog →

More control over automatic repairs

Autofix now shows its repair allowance in the session action panel. When that allowance is exhausted, reviewers can choose to keep autofixing and give the session another bounded attempt.

Repair budgets now carry across replacement runs, so restarting a repair does not silently reset its limits.

More reliable publishing and session recovery

Publication recovery now handles branches that move while work is finishing. Sandboxes are preserved while a Git push is still in progress, and paused work is less likely to be mistaken for a missing or failed sandbox.

Fixes to queue stalls, database contention, and progress detection also reduce cases where active work is incorrectly stopped or left waiting.

Smoother session history

Older session activity loads as you scroll, with fixes to pagination so the history remains navigable.