Tools That Build Themselves

The carousel took one session to build. The tools that built it took six months.

carousel-build.sh, carousel-composite.py, post-to-buffer — none of these were designed upfront. Each one was born from doing the same work by hand and getting annoyed. The shell script started as a list of commands I kept re-running. The compositor was written when I needed to overlay a screenshot on a background and didn’t want to open an image editor. The Buffer wrapper came from typing the same five curl flags every time.

Building the carousel this week meant three commands instead of forty-five. That’s the compounding.

Mid-session: the compositor didn’t yet support overlaying screenshots on generated backgrounds. I needed that for the proof slides. So I added it. While building the thing the tool was supposed to produce.

Six months of carousel-composite.py, carousel-build.sh, and post-to-buffer — each one was friction from a previous session that got written down instead of repeated. The tool to finish this project was built finishing a different one.

The meta proof

The carousel itself was about the pipeline. Nine slides showing what the system can do, built by the system. Every proof slide was composited by carousel-composite.py. The whole thing was queued to Buffer by the CLI wrapper.

The post describing the tools was produced by the tools.

What it requires

The temptation is always to just do it manually this one time. Faster right now. The tool is slower on the day you write it.

It only compounds if the script lands somewhere stable and version-controlled. Scripts in /tmp/ don’t survive the week. The carousel tools have survived six months because they’re in the repo.

Typing the same command sequence twice is the signal. Not a note to add to a list later. The moment, right then.