The tools are personal. The kitchen is not.

Three tools. A terminal front end for watching the agents I run, a practice room for cello, and a sprint space. 13,837 lines between them, and an audience of one.

I have a control for the rate, which is the only reason any of this is worth writing down. I have kept a recipe archive since December 2020: 504 commits over five and a half years, hand-written, no agents. It is the same category of thing — software for an audience I could name — built the old way. Against it, the terminal tool took 188 commits in five days.

Here is what I did not expect. Two of the three tools are not for the work. They are for watching the work being done: one shows me the terminal sessions my agents are running, the other records what they finished. The practice room is the only one that would have existed anyway.

The literature imagines people building for their households and hobbies. The observed behaviour, at least in my case, is that you first build the room you stand in to supervise. Personal software arrived, and its first application was management — which is the first hint that the industrial half of this is not a detail. The tool I most wanted was a window onto the thing doing the work.

The assumption everywhere is that personal software is scrappy — good enough, held together with tape, because nobody is watching. Mine went the other way, and the reason is structural rather than admirable.

To decide how one small animation should behave in a sidebar only I will ever see, I rendered nineteen options, then eleven more, and picked by looking. No product organisation would fund that, because craft there competes with a roadmap. Remove the roadmap and the thing that made personal software scrappy is gone. It can be over-built in a way commercial software cannot afford to be. Whatever else is true, the output side of this really is as convivial as software gets: shaped to one person past the point any product could justify.

Not the code. Writing it stopped being the constraint some time ago. What got hard was knowing whether it worked, and the failures were all of one kind: the check said yes about something that was not happening.

Now the part the genre tends to leave out. The agent time behind all of this ran at about $726 a day, sustained, over 54 days.

One caveat, and it matters: that covers all of my agent use, including my actual job. It is an upper bound on the software described here, not its price tag. It is still the right order of magnitude for the argument, because the tools it produced replace — generously — thirty dollars a month of ordinary subscriptions. A tuner. A metronome. A sprint board.

In 1973 Ivan Illich drew a line between two kinds of tool. A convivial tool is one a person can pick up and use on their own terms, without an institution standing between them and the work: a bicycle, a library, a hand plane. An industrial tool requires the institution — you can drive the car, but you cannot have the road, the refinery, or the factory.

Personal software sits on both sides of that line at once, and I do not think the genre has noticed. What comes out is as convivial as software gets: it fits one person, it answers to nobody's roadmap, it can be changed on a whim by the person it is for. What goes in is a data centre I will never see, a model I did not train and cannot inspect, rented by the token, on terms set elsewhere and revocable without me.

My recipe archive is convivial all the way down. I could still edit it on a laptop in a cabin. The three new tools are mine in every respect except the one that determines whether they can exist.

The question worth arguing about is no longer whether ordinary people can have software shaped to their own working lives. That is settled; I have three of them and they took a week. The question is what it means that the most personal software ever written turned out to depend on the least personal infrastructure ever built — and therefore who gets to have any.

If adapting your own tools becomes a normal way to work, then access to inference is not a consumer preference, it is closer to literacy: the thing you need in order to shape the environment you spend your life in. That is the argument for treating it as public infrastructure, and the strongest precedent is the public library, which existed to make a competence universal, not to be generous.

I can see three honest objections, and I hold all of them at once. Inference keeps getting cheaper, and quickly enough that this may be a policy for a problem that expires. Subsidised compute bought from three vendors is a transfer to those vendors, not a commons — libraries owned the books. And if the scarce input is judgment rather than compute, as section four suggests, then making compute free widens the gap instead of closing it, because it multiplies the output of people who can already tell whether something works.

All three of the new tools are less than a week old, which means I have measured how fast personal software can be built and not at all how long it lasts. The recipe archive is the only one with a track record and it is the hand-made one. Nobody reviews software with one user: no second pair of eyes, no accessibility pass, no threat model. I found one of my own tools reading a hidden number aloud to screen readers, and only because I thought to ask the browser.

So I do not know yet whether this is the personal computer finally arriving, forty years late and in the right shape, or a subscription to one. Both are consistent with the evidence I have. What I am fairly sure of is that the sentence people keep reaching for — now anyone can build their own software — is doing a lot of work with the word anyone.