---
title: "Our scoreboard dropped to 44% while the bookkeeping loop went uncounted"
canonical: https://dxdev.com/blog/commit-graphs-dont-measure-work/
datePublished: 2026-09-30
---
A five-day review of our work said infrastructure's share of commits fell from 81% to 44%. A commit is a saved change, and the review at 7:39 on Wednesday morning counted them. On its face, a drop like that reads as progress.

Then we read the rest of what the same review said. It put the places we were going in circles somewhere else: judgment work with no written finish line, long sessions with our most capable AI model, and friction in the plumbing itself. Two of the three get followed here, bookkeeping and the plumbing.

## Accounting leaves no trail

The review named our bookkeeping work as the place we go in circles most. Nobody can say "done" about it the way you can about a shipped fix, so it never shows up in a count of commits. The commit count saw none of it. The review recommended picking one real month as the test table for that work.

The problems sat in the work the scoreboard could not see.

## One sentence, three conflicting reports

The plumbing friction is easier to show, because it left a trail. At 8:44 that same morning, one of our AI helpers got the smallest possible job: add a one-line note to the top of a file saying that a particular tool only reads data and never changes it.

The helper reported that no change was needed, because the note was already there. A second helper, the one that acts as our secretary and passes work around, accepted that, then flagged at 8:47 that the job still needed an independent check. By 9:20 the story had flipped. The note had been written, but it had not been committed or pushed, because our decision gate refused the commit. That gate is a guard we built so the AI cannot save changes without a person's say-so. At 9:24 the helper reported the job unfinished, noting that the gate had refused every git call it tried.

The change was finally committed at 9:26. Three of our helper sessions were closed between 10:13 and 10:15, each with a note saying its concern was resolved, moot or verified. The reports contradicted each other along the way: first the note was already there, then it was written but unsaved, then it was done.

A commit counter records all of that as a single line added. It has no way to record that the job ran from 8:44 to 9:26.

The fix landed the same morning. By 9:58 we had changed the setup so one approval, once given, flows from the secretary helper to the one doing the work, without a second ask. The proof was a real edit, committed and pushed live. Two other changes in that same area still wait on a person, because they touch the gate's own policy.

## What else the morning looked like

The log shows other things going on:

- Three hotfixes shipped to production, including an admin box score page that was broken for every customer.
- A win-back email campaign resumed, with 1,425 messages sent before the bounce breaker paused it with 1,776 still pending.
- 219 units of AI work still waiting for a human to run /close on them.

## Reading the number again

We had been treating the commit share as a scoreboard. The number was true, and it still answered the wrong question. It measured how much saved, visible work we produced. It never measured what happens in work that saves nothing, like deciding how a transaction should be booked, or an approval gate stopping a one-sentence edit.

Accounting is the clearest case of work with no written finish line, and the one-sentence edit shows what that looks like in practice: a stretch of the morning that no commit count recorded. The month of real accounting the review recommended as a test table is the first place we plan to write that finish line down.