writing/ agent operations · · by Alex Bouchard
A very crowded Tuesday
I noticed the machine was well oiled and running hard on Tuesday, so I asked how many commits we’d made and how many pull requests we’d closed. The commit count came back at 520.
My next question was whether we were shuffling paper or actually moving the ball forward and shipping real work.
It was real, with qualifications. Those were distinct commits across 39 repository identities on October 13. There were merges in the pile, along with documentation, tests, tiny corrections, and work on branches that had not shipped. A commit is a step in the work, not a product delivered to somebody’s phone.
Still: 520 steps. I wanted to know what had made that possible.
01 / I stopped being the whole assembly line
For a long time, working alone meant that every task waited for me to touch it. I could have a good idea in the morning, know exactly how to build it, and still find it sitting there at night because another repo needed a test, a copy fix, or a release check. The queue was made of my own hands.
Now I have a team of agents. They do real work. They investigate a problem, write code and tests, check what changed, repair a failed run, and leave a record I can follow. I give them an outcome and the boundaries around it. They are allowed to move the ball forward, not just tell me what somebody else ought to do next.
That last part matters. A team that only reviews my work would give me better feedback and the same queue. A team that can build gives me room to make decisions while work advances elsewhere.
On Tuesday the work ranged from product changes to search measurement, infrastructure, copy, and the unglamorous things that make the next change easier. The commit counter got silly because the factory was running across many lanes at once. I was still one human being. The work no longer had to pass through one pair of hands.
02 / the factory has brakes
“Factory” can sound like I asked a model to produce code by the yard. That would be a spectacular way to produce code by the yard.
What I built is closer to a harness. A task has a place to live and a way to be picked up again. Tests ask whether behavior changed as intended. CI runs the checks away from the agent’s machine. Review and release gates ask a different question: is this the same change that was actually checked, and is it ready to cross the next boundary? Some changes need a preview; some need a live observation afterward. The agent can do much of the work, but a green test is not permission to invent a business decision.
Tuesday gave me several reminders that the brakes are part of the speed. A search probe’s test expected an indexed page and got an unknown state. The run failed. A dependency change left a lockfile that a clean install would not accept. Another gate rejected a review because the code had changed since that review. None of those red lights was a catastrophe. Each stopped a wrong assumption while it was still small enough to fix.
Most of the matched GitHub runs succeeded. Forty-six failed. I do not celebrate broken builds; I like a system that refuses to call one clean. The follow-up commits and green runs are in the record too. If I showed only those, I would miss the part that makes the system useful.
03 / trust is an operating decision
I trust the agents to take a task somewhere. That does not mean I treat every output as true, or turn off the checks so they can work faster. It means I let them own the next executable step: fix the test, trace the source, make the small edit, run it again, and tell me what happened.
I used to think of delegation as handing off a finished idea. This feels more like having capable people in the build room. They can disagree with a premise. They can find that a test was asking the wrong question. They can finish a piece of work while I am deciding whether the piece belongs in the product at all.
The human work gets sharper, not smaller. I still have to choose what we build, decide what can be published or charged for, and notice when a convincing answer is missing its evidence. I also have to make the boundaries legible enough that an agent can act without asking me to approve every keystroke.
There is a tradeoff in that. On a day like Tuesday, the repository history is much larger than one person can read commit by commit. The answer is not to pretend I personally inspected 520 diffs. It is to make the important failures visible, keep the work small enough to reverse, and be honest about what a check did and did not prove.
04 / what the number means
The number is fun. I am going to enjoy it for another minute.
But it does not say that 520 features shipped, that every change was perfect, or that nothing broke in production. Git cannot tell me any of those things. The audit found real failed checks, fixes, and later green runs. It did not measure every user’s experience or every deployment.
What the number does show is a different shape of work. One founder can keep several products and systems moving when the agents are trusted to build, the checks can say no, and the decisions that need a human still reach one.
I asked for a count and got a story about the machinery around the work. There were 520 commits. The more interesting number may be one: the number of people who still had to decide what mattered.
Next step
Want to talk it through?
Book a 30-minute call. I will tell you plainly whether I can help and what I would test first.