Eight repositories in eleven days. Six died within three.

I can date my worst habit precisely, because it is in the commit history and there is no arguing with it.

Between the twenty-first of June and the first of July this year — eleven days — I created eight repositories. A command-line agent, a small language model, a shell, a fine-tune, a reminder app, and three others. Six of those eight received their last commit within three days of being created. Two did not, and those two became the agent fleet that is still in active development two months later.

At the time this felt like the most productive stretch I had ever had. Every few days something worked that had not worked before. That is a genuinely intoxicating feeling and it is why the habit is difficult to see from the inside.

#The mistake was not speed

I want to be careful about the lesson here, because the obvious one is wrong. "Slow down" is not it. Building quickly is the entire advantage of the way I work and I would not give it up.

The mistake was that I treated the moment a thing worked as the moment it was finished. Those are separated by a very long distance, and almost all of the distance is unglamorous: the states nobody tested, the second device, the error that only appears when the network is slow, the interface that made sense to me because I built it, the security model nobody looked at twice.

A working version is a demonstration. A finished one is a product. I was collecting demonstrations and calling it a portfolio.

Several of those six are not failures, and I want to be fair to them. A couple became genuine published artefacts with real numbers behind them. But they arrived at the state of being interesting and then stopped, because I had already started the next thing, and interesting is not the same as useful to somebody else.

#Why this happens more now

This failure has always existed among people who build things. What has changed is the ratio.

When getting to a working version took three weeks, the cost of starting something new was high enough to make you think about it. When it takes an evening, there is nothing to stop you, and the reward — the feeling of a thing existing that did not exist this morning — arrives immediately and repeatedly. Refinement offers no such reward. Nothing visible happens on the day you fix the eleventh edge case.

#What the two survivors had in common

Not better ideas. I do not think the fleet was a more promising concept than the shell or the model — in some ways it was less so. What it had was that I came back the next week, and the week after.

Everything that makes those two projects worth anything today happened after the point where the earlier six had stopped. The evaluation harness, the interface someone else can operate, the failure handling, the part where it keeps running when I am not watching it. All of that is week three, week five, week nine work. None of it is exciting and all of it is what separates a thing that exists from a thing that is used.

#What I do differently

1. One thing at a time gets refinement. I still start things quickly — that is not the problem — but only one project at a time is allowed to be in the polishing phase, and it stays there until it is genuinely done.
2. A working version is logged as a prototype, explicitly, in my own head. It does not go on the site, it does not count, and it is not described as shipped.
3. The test is whether somebody else could use it without me in the room. Not whether it runs. Almost everything runs.
4. When I want to start something new mid-refinement, I write the idea down and carry on. The urge is real and it passes, and the note costs nothing.

The honest summary is that for a stretch I was optimising for the feeling of progress rather than for progress, and the two are close enough to be mistaken for each other for quite a long time. The commit history is what eventually made the difference visible, which is a reasonable argument for occasionally looking at your own.