The reason it exists is real, and I can point at it. I tried to use my aliases on an Ubuntu server and could not: the server ran bash, my functions were zsh, and zsh functions in bash do not fail. They run and quietly do nothing. That is a genuine problem, I have the commits that fix it, and it is not why I started.

The bash mismatch was the first thing I noticed and the least interesting. The box also had aliases for tools that were not on the box — commands standing ready to fail, in my own handwriting. And it had the binaries. The dotfiles repo carried 61MB of committed third-party executables, duckdb and ngrok among them, and they arrived on that server because they arrived everywhere. I did not need duckdb there. I might need it on the next machine. The repo had no way to hold both of those facts at once, because nobody had ever told it there was more than one machine.

That is not a configuration. That is luggage.

What was wrong was not any of those three things on its own. It was that cloning a dotfiles repo replays a machine. It re-enacts the history of the laptop it grew on — that zsh is there, that duckdb is wanted, that ngrok is on PATH — onto a machine with a different history. Every assumption travels, because the repo is a record of where I had been rather than a description of what I wanted.

So I wrote something that renders. One catalog of aliases and functions, one configuration file holding the personal parts — who I am in git, where my projects live — and a command that writes a single file the shell sources. The binaries stopped travelling: they are declarations now, fetched on the machine that wants them and checksummed before they go on PATH. Two shells, two platforms: the same catalog comes out four different ways, and the repo keeps all four on file.

A replay has one output. A render has as many as there are machines.

The server was not the first time. It was the last one. I had installed that setup on other machines before it, and the wanting had been building the whole way. The server is only where I stopped absorbing it.

Which brings back the phase order. The bash backend came last for a defensible reason: once the generator had a backend interface, a second dialect stopped being the hard problem, so it waited because it could afford to wait. That is true, and I would say it in a code review.

It is also not the reason. Bash was the excuse. I already wanted to build this, and the server handed me something I could say out loud.

There is a second one. Before I started I looked at chezmoi, stow, dotbot and the other tools that already exist, and concluded that none of them solved everything I wanted solved. I believe that too. And I really just wanted to build my own. I am not sure the research would have changed my mind if it had come out the other way.

The third is the web interface. loadout ui serves a page on localhost for composing the configuration, and it exists because I wanted to build a web interface. That one has no sayable version. I did not go looking for one.

It is also the most expensive thing in the project. A page that edits what your shell runs at login is a remote code execution API for your own account, so three checks precede every request: a per-run token, an Origin that has to be ours, and a Host that has to be loopback. The last of those is the defence against DNS rebinding, and there is a note in the repo telling me not to loosen it.

It broke in the stupidest way available. The interface served no CSS and no JavaScript at all, because the guard demanded a token on every request and a <script> tag cannot present one. A blank page — produced by the security I added to protect the feature I wanted for no reason.

None of that makes the tool fake. The problems were real, and looking at them now they are one problem wearing three coats: each of them failed without saying so.

The zsh functions on that Ubuntu box did not error. They ran and did nothing. The aliases for tools that were not installed did not announce themselves either — they waited until I typed one. And loadout env, the command that prints export lines for the active credentials, wrote them to stderr, so eval "$(loadout env)" — the exact line in my own README — did nothing at all. Nothing had ever run it end to end. Everything that had looked at it had looked at the text, and the text was right.

So the parts of loadout I am least able to claim I built for fun are the parts that make silence audible. loadout doctor walks everything the catalog asks for and reports what this machine does not have. loadout describe says what a command needs before you call it.

And doctor only reports. The alias for the missing tool still gets written into your file: the render varies by shell and by platform, not by what happens to be installed. So the second of my three failures is the one loadout does not fix — it makes it audible, which is not the same thing. That is at least consistent. loadout does not edit your shell config for you either; the line that sources the generated file is yours to add.

The four outputs from earlier have a name. They are golden files: the complete generated shell for both dialects on both platforms, pinned in the repository. Any change to a template or the catalog shows up as a diff across them, and that diff is the review — because the alternative is that a one-line edit to an alias becomes a silent change to every shell that runs apply next.

One more cost, and it is the one I pay rather than the one I shipped. Secrets in loadout live in the OS keychain and never in the generated file, because a generated file is plain text on disk. Something therefore has to fetch them at runtime — and the line that does it, if you put it in your shell config, reads the keychain every time you open a terminal and puts your tokens into the environment of every process you launch from it. The README lays both sides out and refuses to choose between them.

I chose. The line is in my .zshrc. I wrote that cost down before I took it.

It is on that server now. In bash. Working. My configuration lives in a git repository and moves between the machines, which was the founding problem and is not one any more.

One person who is not me has installed loadout. A colleague. No bugs reported, and nothing in the tool changed when they installed it, because I had already built it so that someone besides me could use it. There is a CODE_OF_CONDUCT.md in that repository, and a CONTRIBUTING.md, and a Homebrew tap in a repo of its own, and an install script served from a domain I own. The user base is one colleague. I built for an audience that has not arrived.

loadout is the first of several. makery.tools is where the rest of them go.

So "I wanted to build my own" is not something that happened to this project. It is the practice. The excuse changes every time. The sentence underneath it does not.

I have written more consequential English in this project than TypeScript. Not documentation — nobody reads it as documentation. A file of rules, in prose, that gets enforced on work I am not watching, at a level of detail I could not sustain by reviewing. It is the highest-leverage artefact in the repository and it is not code.

A seed script in this project was about to grow a line reading body: project.body ?? null. It looks like a default. What it does, on every run of yarn db:seed, is overwrite every hand-written project writeup with nothing.

It never ran. What stopped it was not a test, because there are none. It was not review, because I never saw the line — it existed for about a minute, between being written and being rewritten. It was a sentence in the rules file, ten days old, a rule I had set and the agent had written down while building the thing the rule describes:

It does not delete, so it will not eat rows created through the dashboard.

The agent read its own note back, checked the line it was about to add against it, and stopped.

That sentence is not unusual. It is one line of the second of three layers, and the three are worth separating because they fail differently.

1. yarn verify — three suites, about a hundred and seventy checks, covering everything a machine can assert. A forged session cookie is refused. No form is nested inside another. Two rows never share a position. A reorder does not move updatedAt.

2. CLAUDE.md — everything a machine cannot. A stale NOW block is worse than none. Position is not content. Mono means data. No invented statistics. A missing value is an em dash, not a plausible sentence.

3. My eye. The last resort.

Layer one cannot express taste. Layer three does not survive a long afternoon. Layer two is prose, and it is the only one of the three that scales to work I am not watching.

Layer three earns its place, and the way it earns it is stupid.

Eleven words, typed while looking at a screen: "on project edit page, selecting categories does not have any indicator." That was my entire contribution. What it turned out to be was every filter chip in the application carrying a selected state that did nothing at all — four of them, in four files: the project editor, two admin lists, and the public work grid.

The cause is a cascade rule almost nobody has needed to know. The design system's classes are plain, unlayered CSS. Tailwind's utilities live in @layer utilities. Unlayered CSS beats layered CSS no matter how specific the layered rule is — so bg-foreground on a selected chip lost, silently, to the class's own background: none.

A selected chip and an unselected one computed to the same value: rgba(0, 0, 0, 0), both. It had shipped, and it had passed review, because there is nothing in a diff to see. The code says bg-foreground and it means it.

I found it by saying a sentence a five-year-old could have said. The agent found the cause in about a minute once it was pointed at it. Neither half of that was optional.

Except that layer three has a shape, and the shape is not flattering.

Everything I caught was visible. A chip with no selected state. A page that had drifted from the design. A whole case-detail page that was simply missing. A cover restating the title of the page it sat on. All of it found the same way: by looking at a rendered screen and saying a plain sentence about it.

Everything I missed was invisible mechanics. The seed line is the example that got close enough to matter — a default that reads as a default and behaves as a delete.

That is not a lapse I can fix by concentrating harder. It is a property of eyes. A rendered page is the only artefact I review at full attention, and a whole class of mistake never appears on one.

Which is what the second test suite actually is. Not insurance, not documentation, not a style guide — the layer that covers precisely what a person looking at a screen cannot see.

The version of this era I keep reading has the engineer prompting and merging. That is not the trade.

The typing did shrink — genuinely, and more than I expected. What replaced it was not free time. It was checking: the logic, the interactions, the edge cases, whether the thing that was built is the thing that was meant. More time, not less.

The other half of the trade is stranger and nobody mentions it. Planning got cheaper. Describing what I actually want, in detail, before anything exists, used to be a tax paid against a slow build — you could think for a day and still wait a week. Now the build is the fast part, so thinking in detail up front is the cheapest move available.

So the work did not shrink. It moved to the two ends and left the middle: intent at the front, verification at the back, and a rapidly filled gap between them that I no longer type by hand.

Which leaves the question the title was avoiding.

My own instinct was that this makes me a product owner: thinking in product rather than in code. Right instinct, wrong word. A product owner sees the visible, and I was good at that here — but a product owner would not know that ?? null in a seed script eats content, or that a reorder must not touch a timestamp the site derives its freshness from, or that an unlayered class beats a layered one. None of those are product judgements. They are the reasons layer two has anything in it, and only someone who can read the code knows to write them down.

So: product thinking chooses what to build. The engineering is knowing what will quietly go wrong, and saying so in advance, in English, in a file something else will read.

Every rule in layer two started as something that went wrong once. Which means the file is not a style guide. It is a list of things I have already paid for.