The box score

My given name is Michael. My dad nicknamed me Mickey the day I was born, after his favorite ballplayer, Mickey Mantle, and it stuck. Anyone who knew me growing up still calls me Mickey. Everyone else knows me as Mick.

My dad is an even bigger stats guy than I am. He worked in computers for Western Electric and AT&T back when a computer filled an entire room and ran on punch cards. He had a high school education, and he taught himself Fortran and COBOL. His mind is built for calculating and measuring things, which is probably also why he is an expert craftsman, a gift I sadly did not inherit. Long before I wrote a line of code, he was the programmer in our family.

So I was nicknamed for a Yankee. But I was a kid from Atlanta, and my player was Dale Murphy, whom I got to watch nearly every night on TBS Superstation.

I played the game, too. I was the shortstop and captain of my high school team, though I was probably a more gifted center fielder and pitcher, and I kept playing in a very competitive men's league in Atlanta until my early thirties. I could handle just about any fastball. The curveball was my nemesis.

What stayed with me longest, though, was the numbers. No sport on earth treats statistics the way baseball does. I collected baseball cards as much for the backs as the fronts, and I can still tell you exactly how Ronald Acuña, Matt Olson and Michael Harris are hitting this season. I can also tell you that my Braves won fourteen straight division titles, from 1991 to 2005, still the longest run in major league history. Every great stat has an asterisk, and that one's is the strike-shortened 1994 season, which crowned no division champions, so the streak steps right over it.

Somewhere along the way I became a person who keeps score. Of ballgames. Of sales revenue, which is the best scoreboard there is. And lately, of commits in a repository and tokens exchanged with an AI.

In the spring I published a field report called Coding at the Speed of Thought. It covered forty-five days, from March 4 to April 20, in which I went from a former software executive who had not written code in thirty years to shipping three production codebases with Claude, Anthropic's coding agent, as my partner.

The most common response was some version of the same question, asked politely. Sure. But will it last?

It was a fair question. Forty-five days is a honeymoon. Anyone can sprint. I have watched plenty of executives fall in love with a tool in March and forget its password by June. I have been one of them.

So I did what I have always done. I kept score. This is the follow-up: two hundred and eleven days of data, measured the same way as the first report, with the method shown. It includes the parts that went well, the parts that did not, and one thing I nearly lost along the way.

The pace held

The honeymoon became the habit.

Here is the number that answers the question people asked. During the forty-five days in the first report, I averaged a little over four commits a day. Over the five months since, I have averaged about four a day. Since the sprint ended, no full month has dropped below 78 commits.

That does not mean every month looked the same. The sprint was concentrated: three codebases, all of them new, built in a burst. The months since have been spread across more work. A second client site joined the list. So did a website for the wedding of my oldest son, Connor, to Maria. It is the least commercial thing I have shipped this year and, given the client, easily the most important one to get right.

The pattern I see in the commit log is not a sprint followed by a fade. It is a sprint followed by a working rhythm. Some weeks are heavy and some are nearly empty, because some weeks are full of client work. The tool did not become a hobby. It became how I work.

What four billion tokens actually means

Big token numbers sound impressive, and I put one on the cover of the last report. This time I looked underneath it, and what I found changed how I think about the number.

More than ninety-seven percent of those tokens are Claude rereading context it has already seen: the code, the conversation so far, the rules of the project. Only about three tokens in every thousand are Claude writing something new. Every time I ask a question in a long session, the entire working context comes along with it, and Claude reads it again before it answers.

That is not waste. It is what makes the work coherent. A partner who remembers the whole project every time you speak is a different kind of partner from one you have to re-brief. But it tells you where the cost of this work really sits. It sits in context, not in output. That matters for anyone thinking about the consumption pricing I wrote about last time. You will pay to keep your partner informed, and that cost is worth managing on purpose.

For a sense of scale: Anthropic publishes the typical daily usage of a developer on Claude Code. On the days I worked, my usage ran a little over three times that average, and above where nine in ten developers land. I am not a developer. That is rather the point.

The factory worked

What I built for myself became what I build for clients.

The first report ended with a claim I could not yet prove. I said that each deliverable, done right once, becomes a template, and each template becomes a reusable unit of service.

It held up. The way I sized the RedLine site for real laptop screens became a written playbook, and it went to a client. The whole-site audit I ran in September became a portable playbook for client sites, framed so that my conclusions are treated as hypotheses to verify on their site, not rules to impose. The hard-won setup for contact forms and conversion tracking became a playbook too. When Rocket Partners, the firm that built CodeVine, asked for help with their own site, I went from a standing start to eighty-five commits in September, largely because so much of the method already existed.

None of that is code you can see. It is the factory. It is the part of the first report I believed most and could show least, and it is now the part I would defend hardest.

I almost lost the evidence

When I sat down to reproduce the numbers in the first report, I discovered something I should have known. The detailed history of my work with Claude lives in local files on whichever machine did the work, and I did most of the spring work on a different computer from the one I use today. Claude Code also cleans up old session history on a schedule by default.

The history from March and April is gone from both machines. Git remembered every commit and every line. But the record of how the work happened, every question asked, every correction made, every dead end abandoned, is gone for those first two months.

In the first report I argued that the most valuable thing a company's best people produce is not their output but their method, and that organizations which fail to capture it will watch it walk out the door. I meant it about engineers at large companies. It turns out I needed to hear it myself, about a two-computer, one-person firm.

So, three pieces of practical advice for anyone doing this work.

Decide where your history lives, on purpose. If you work on more than one machine, know which one holds the record. If the history matters to you, change the cleanup setting.

Write down your method while it is fresh. The playbooks in section 06 survived because they were written down. The session history did not, because I assumed it would always be there.

Count the same way every time. Baseball has an official scorer for a reason: a hit is a hit only if everyone counts it the same way. I could compare seven months to forty-five days only because the method could be reconstructed from data that survived. Write the method down next to the number.