492 Useful Commits on a Sunday

On Sunday, November 1, the Astrohacker monorepo got 492 useful commits on main by about 7 p.m. Chicago time. The day was not over. On Saturday, it got 447. That is about 939 useful commits in one weekend.

I typed none of them.

In 2024, I averaged 19.3 commits a day. Sunday, at 492, is about 25 times that average. That ratio is mine: I divided one good day by a whole year’s average, and the two numbers come from different methods. I explain both below. But the direction is not in doubt.

Last week I wrote I Make 156 Commits a Day Now. That post counted every commit since 2024 across all of my repositories. This post is about the next step: a stricter count, two days that beat the October average by about three times, and an honest look at the gap between where we are and where I want to go.

The count

The 156-a-day number and the 492 number do not come from the same script, so here is what each one counts.

The October post counted commits with my name in 572 repositories on my Mac, with each commit counted once, even when an import had copied it into another repository. It included merge commits. It covered whole years.

The weekend numbers are useful commits. They come from Commits, an SI agent whose only job is to audit every commit on main and measure the rate. Its definition is short: a useful commit is a unique non-merge checkpoint commit on main with my identity. In detail:

• Main only. The count covers the main branch of the Astrohacker monorepo, not every repository I own.
• No merges. A merge commit moves work. It is not work. It does not count.
• No replays. If the same change lands twice, Commits sees the same git patch-id --stable and counts it once.
• No padding. Empty commits, whitespace commits, commits that only change a timestamp and commits split only to raise the count are padding. The rule is simple: a padding commit is never a fix for a low number.
• The right identity. Each commit must have my name and my company address as author and committer. Commits with the wrong identity are excluded, even when the work is real.
• Chicago days. A day runs midnight to midnight, America/Chicago.

A checkpoint commit is one logical step that passes its checks. Our tool warns when a commit changes more than 300 lines or 8 files, and fails it above 600 lines or 15 files unless the message says why. So the commits are small on purpose. Small commits are easy to review and easy to revert.

Two notes on the comparison. First, the useful count is stricter in the two ways I know about: it drops merges and it drops replays. Second, it is narrower: it sees only one repository. The old best day, 433 on June 6, 2026, came from the broad method. The weekend days came from the strict one. I will not claim a clean record from two methods. I will say that both weekend days are above that old best.

Eight times, not a hundred

The October number, 156 a day, is eight times my 2024 rate of 19.3 a day. That is a monthly average, on one method, across almost three years of data. It is the number I trust most.

The weekend is a different kind of number. It is two days, not a month. Saturday, at 447, is about 2.9 times the October average. Sunday, at 492, is about 3.2 times. If the next month looks like this weekend, the average will move up a lot. I do not know that yet. Two good days are not a trend.

My goal is 100 times my 2024 rate. That is about 1,930 useful commits a day, every day. Sunday is about a quarter of that. So the honest summary is:

• Measured, as an average: about 8 times, in October 2026.
• Measured, on two days: about 23 times on Saturday and about 25 times on Sunday, against the 2024 average.
• Not measured: 100 times. That is the goal, not the result.

I write it this way because it is easy to say “100x” and hard to show it. I would rather show 25 and be right.

Where the gain came from

In the October post, I listed the steps in the curve. I will not repeat the list. The short version is in one paragraph from that post:

None of these steps made me type faster. Each one took me out of a loop that I used to be in. First the typing, then the solving, then the waiting.

The weekend adds a fourth loop: being there at all.

In April, I stopped writing code. In June, I set the goal and walked away, and agents solved whole issues with experiments while a second agent reviewed them. In September, I stopped running one agent. On September 13, I made 175 commits, about 2.6 times the 67.2 a day of the workweek before. I wrote then that it “does not mean 175 features or prove a controlled productivity gain.” That is still true, and it is true of 492.

On October 11, I made 380 commits. That was the month the agents started to run long and wide. On the EarthBucks 2.0 mine, one issue failed its goal after 181 experiments. A second issue, with a new plan, ran 135 experiments and, in a local test only, finalized 504,000 payments at more than 8,300 a second. EarthBucks 2.0 is not live. But the shape of the work is the point: long runs with an end, many of them at once.

What changed for the weekend is that the work no longer waits for me to be at my desk. The SI agents commit with my identity, through the same rules, on a schedule. A weekend is just two more days.

I am not alone in this. Boris Cherny, the head of Claude Code, told Fortune in June: “I haven’t written a line of code by hand in, I think, eight months now.” Steve Yegge described the first weeks of his own agent system in Welcome to Gas Town: “17 days, 75k lines of code, 2000 commits.” That is self-reported, like mine. Neither of us ran a controlled study.

A commit is not a feature

I said this in October and I will keep saying it. A commit is not a feature.

Many of the 492 are plans, results, records and reviews. In our workflow, each experiment has a plan commit and a result commit. Agents keep journals. A standup is a commit. So is a one-line fix to a note. The checkpoint rule makes each commit small, and small commits mean more commits for the same work. That is a choice, not a trick: we want the history to be easy to read and easy to undo. But it means you cannot divide my commits by yours and learn who ships more.

There is a better reason to be careful. In 2025, METR ran a controlled trial with experienced open-source developers. Its result: “When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts.” Worse, “developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%.”

People can feel faster and be slower. That is why I count, and why I count the same way each time.

METR’s February 2026 update is worth reading too. They write that “it is likely that developers are more sped up from AI tools now — in early 2026 — compared to our estimates from early 2025.” But they also say their new data “gives us an unreliable signal of the current productivity effect of AI tools,” and give the reason: “a significant increase in developers choosing not to participate in the study because they do not wish to work without AI.” The best measure of the change is now hard to run because of the change. I find that funny, and also a warning. Nobody has a clean number. Count your own, and say what it counts.

Other teams count pull requests, not commits, and I will not mix the two. Stripe writes that “Over a thousand pull requests merged each week at Stripe are completely minion-produced, and while they’re human-reviewed, they contain no human-written code.” In part 2, that is “Over 1,300.” At Uber, the software factory post says: “More than 70% of pull requests are attributed to local or cloud agents.” OpenAI’s harness engineering post describes a team that steered agents instead of writing the code itself, and it also measures in pull requests. A pull request is a bigger unit than one of my commits. These are peers on the same path, not entries in the same table.

What 100x would take

The math is plain. 100 times 19.3 is about 1,930 useful commits a day. Sunday was 492. We need about four Sundays in every day, including the real Sundays.

More agents is part of the answer. It is not all of it. Addy Osmani opens Your parallel Agent limit with this: “More agents running doesn’t mean more of you available.” And later: “What scales is your throughput of supervision, not your throughput of understanding.”

That matches what I see. Stripe says it too: “in a world where one of our most constrained resources is developer attention, unattended agents allow for parallelization of tasks.” The agents are fast. The limit is the decisions that still come back to a person.

So 100 times is not a typing problem or a model problem. It is an attention problem, and the way to solve it is to take me out of more loops:

• Length. Each agent must run longer before it needs a decision. That means goals it can check by itself, a reviewer in a fresh context, and a clear end: done, or stop and ask.
• Width. More agents at once, each with its own worktree and a task that does not share an interface with the others.
• Review that is not me. I wrote in October that “If you read the diff yourself, you are the slowest and least reliable reviewer in the loop.” At 1,930 commits a day, that stops being an opinion. It is arithmetic.
• A router that is not me. Today, I still start agents and move work from stage to stage. The software factory design gives that job to a work graph and a queue: agents ask the factory for work, and each item ends as deployed or human required. That graph and queue are in progress. They are not shipped.
• A backlog that refills. Agents that finish need the next ready issue. If the queue is empty, the rate falls, and no amount of compute fixes it.
• Shared plumbing that keeps up. When hundreds of commits land on one branch, sync and push become the slow step. That is a tooling job, and it is on our list.

None of this needs a smarter model. It needs more agency: better decisions about what to do next, and a system that lets each decision drive more work.

Count yours

Here is the method in four steps:

1. Pick one repository and one branch, the one that ships.
2. Count non-merge commits for each day in your time zone.
3. Count each change once, even if it landed twice. git patch-id --stable does this for you.
4. Write down what you excluded and why.

Then count a normal week. Change one thing about how you work: run one agent longer, or run one more. Count the next week with the same method.

I will count again too. 492 is not the goal. It is the number to beat.