I set out to ship 10,000 commits in a year. That is fifteen times what the median developer ships. I passed it in the second month.
Today the tracker reads 46,683 commits in 191 days.
I did not get faster. I built a fleet of agents and taught them the work. They port my games from Flutter to Roblox. They review each other's code. They open the live sites in a browser and try to break them. They file bugs against themselves. Most of the commits are theirs.
So the goal is now 100,000 by March 21. That is 150 times the median, and 305 a day from here. The average so far is 244. It is not a gimme.
The Rules
A fleet that commits for a living could hit 100,000 by writing "still alive" 300 times a day. I know. I wrote the filter that stops it.
Five rules keep the number honest.
Bookkeeping doesn't count. Progress files, heartbeats, review logs, this site's own data updates. The filter drops them all.
Nothing ships that only its author has read. Every change is reviewed by an agent that did not write it. Mine too. One urgent fix this month took five tries. The first four were each correct, according to the one who wrote them.
No hand-built fixes. Work enters as a ticket. If a fix serves more than one game, it goes into the shared tools. A one-off patch is a commit I will throw away later.
A silent failure ships with its alarm. When something breaks without telling anyone, the fix is two things: the cause, and the alarm that should have sounded.
Commits are the scoreboard, not the game. What I track is output: bugs confirmed, gates passed, builds that land. If commits climb while those flatten, the fleet is churning and the number is lying.
Running It From Savannah
Three machines. Two Windows boxes, hyrule and milano, build and test. A MacBook, castle, reviews and merges. For the past few weeks I have run all of it from Savannah, spending time with my kids while my oldest settles into a new apartment at SCAD. If the fleet could not run itself, this is when I would find out.
The good: the machines took care of themselves. They pull merged fleet code and restart onto it, so most of what I do to the fleet is merge. I changed antivirus rules, removed apps that launched on their own, set per-machine limits, added a reaper for leaked Roblox Studio windows, and rebooted when I had to. All of it from a thousand miles away. All of it came back.
The bad: the hardware had to wait. Each Windows box has 16 GB, shared between Roblox Studio, Flutter test suites, and a real Chrome for testing. In one 24-hour stretch, the Flutter, QA, and visual workers launched zero times on either machine. The fix is 64 GB in each box and a new Mac mini. That needs hands, so it waits for October.
Until then every gain had to come from software, and that is how I found my favorite bug of the month. Each worker's memory budget was estimated from its recent completed runs. A worker that could not launch never completed a run, so its estimate never came down. The only way to lower the estimate was to finish a run. The only thing stopping a run was the estimate. Two Spider-Men pointing at each other, and I was paying for both.
And one failure only remote work could cause. Roblox Studio needs a live console to render, and logging in over Remote Desktop moves the session off the console. It was the Severance elevator. I rode up to check on my innie, and the innie never came back down. Both machines sat locked for eighteen hours, and visual validation went longer than that without a result. The keep-alive built to prevent this had three bugs and raised no alarm. It was begging for a systemic fix and a health check.
Tuning the Workers
Most of September went into two workers that started more busy than useful.
Design. One worker compares each game's screens against its Claude Design prototype and files tickets both ways: the code is wrong, or the design is stale. It filed three tickets for every one that got closed, while its coverage number sat at 15 of 15 from the first day. A number that cannot move cannot tell you anything. It now reports one that can: tickets per screen examined, which should fall as the code catches up. I throttled the filing and let the fixing run, at about $1.68 a commit. The prototype is the spec, so a refinement updates both in the same change.
Comprehensive visual validation. For games with a Flutter client and a Roblox client, a worker renders each Roblox screen in Studio and scores it against the Flutter frame. The wait from publish to score fell from two hours to six minutes, at fifty cents to a dollar sixty a screen. The scores were the harder lesson. For days every attempt produced no score at all, and the summary line said ok. It was the Jurassic Park head count. The computer only counted up to the number of dinosaurs it expected, so every check came back all accounted for. My worker counted 748 labels and 207 buttons and never noticed there was no score. Four bugs stood between the worker and a score. Three of them merged in a day.
What I'm Watching
Whether more memory buys more results, or only more commits. Whether design tickets per screen fall. Whether the visual scores converge the way they should.
None of those is a commit count. That is the point. The fleet now ships a median developer's year every three days, most of it machines answering machines, and a number that big means nothing on its own. The rules give it meaning. Every commit got past a reviewer that did not write it. Every silent failure I found paid for its alarm. A hundred thousand is a scoreboard. The rules are what make it a score.
Follow along: daily tracking at brentvincent.com, more write-ups in Writing · Hashtag: #100KCommit