Published on [Permalink]
Reading time: 4 minutes

Documentation as a by-product

Nobody writes documentation. Especially not for their own machine.

It’s the work everyone agrees is important and nobody does. The reasons are obvious. It’s tedious. It’s never urgent until something breaks. And by then the person who set the thing up (you, six months ago) has forgotten the bits that matter.

This weekend I added complexity to my Mac that I knew I’d regret. I installed Ollama. Pulled down nine local models, ~115 GB of weights. Set up Open WebUI as a front end. Wired up LiteLLM to gateway through to the Anthropic API so I can hit Claude from any tool that speaks OpenAI. Five new launchd services running at login. Several new ports listening. An API key that I (cringe) initially left in plaintext inside a YAML file.

I am not a CLI guy. I know enough to be dangerous. What I don’t know is what each service is doing, what’s auto-starting at login, what depends on what and where to look when one of them stops answering.

So I did something I wouldn’t normally bother with. I asked Claude Cowork to document the lot.

Cowork is Claude with hands. It runs on my Mac, sees my filesystem, runs shell commands on my behalf and writes back into the same Obsidian vault where I keep my reference notes. The thing doing the discovery is the same thing writing the documentation. Same conversation. No copy-paste, no tab-switching, no “now go and write this up”. That last bit is what changes the economics of documentation. The friction that normally kills it (the gap between figure out what’s there and write down what you found) collapses to zero.

It took about an hour. It read my ~/Library/LaunchAgents/ directory and parsed the plists. It ran brew services list and launchctl list and lsof to see what was actually running on what port. It noticed Open WebUI was crashing on startup (silent failure, exit code 1, missing WorkingDirectory in its plist) and fixed it. It noticed my Anthropic API key was sitting in plaintext and moved it into macOS Keychain via a wrapper script. It drew an architecture diagram showing how Open WebUI talks to Ollama for local models and to LiteLLM for cloud Claude calls, with the API key flowing in from Keychain at service start.

By the end of the session my Obsidian vault had a REFERENCE/Mac Services/ folder containing nine notes: an index, an architecture overview, one note per service, a launchd how-to, an Ollama models inventory and a documentation backlog. Plus a REFERENCE/Shell/ folder with a shell cheatsheet and a zsh quirks note (I let it fix my long-running “# is not a comment” annoyance while it was in there).

The notes are wikilinked. They cross-reference. They have frontmatter so I can tag-search later. They include the actual launchctl and curl commands I’d need to operate or troubleshoot each service. They flag known issues. They include the paths to backup copies of every config touched, so any change can be rolled back.

This is documentation I would never have written.

That’s the actual point. Not that Claude Cowork wrote it faster than I could (it did). Not that it was more thorough (it was). The point is that documentation that doesn’t exist provides zero value, and documentation that exists provides value the moment something breaks at 11 PM and I’m trying to remember why I set the thing up that way in the first place.

The dread of documentation comes from doing it after the fact, in cold blood, when the curiosity that drove the original work is long gone. Doing it as a by-product of the work itself, while the context is still hot, is a different experience entirely. It feels like I just had a longer conversation than I’d have had anyway, and a vault page popped out at the end.

I really hope I don’t need to look at it. I genuinely don’t expect to, most weeks. But it’s there if I need it. And the next time I add a service to the stack, the pattern is established. Future me can keep it current without dread, because the dread was never really about writing prose. It was about doing it alone.

✍️ Reply by email