This week my software factory shipped version 0.17 — of itself. I pressed one button in its cockpit. The release was drafted, checked, and cut by the same system it was a release of.
I want to talk about that button, because it’s the most misunderstood object in software automation. Teams build release buttons on day one. That’s exactly backwards. A release button isn’t something you build. It’s something the system earns — and the seventeen versions behind mine are the receipts.
Buttons are certificates, not features
Technically, a one-click release is trivial. Wire a script to a UI control: bump the version, assemble the changelog, tag, publish. A weekend project. Which is why every platform team has one, and why so many of those buttons are surrounded by tribal folklore: don’t press it on Fridays, check with Dave first, make sure the staging run from Tuesday actually finished. The button exists; the trust doesn’t. So the button is a lie with a nice icon — the checklist it replaced still runs, just informally, in people’s heads, where it can be forgotten.
The honest version of a release button is the last step of automation, not the first. Every action behind it got promoted to autopilot separately, one at a time, after proving itself the boring way: by being executed with human supervision until the supervision stopped catching anything. Changelog assembly earned its place when drafts stopped needing edits. Version bumps earned theirs when the rule became mechanical. Merge-readiness earned its place when “the checks are green” became structurally true rather than optimistically assumed — in my factory, work with a red check is never even presented as ready; a failing check automatically enqueues a fix round instead of waiting for a human to notice. By the time a button appears, it isn’t automating a process. It’s certifying one.
That’s the trust ladder applied to the scariest action a codebase has: autonomy is earned per action, not granted per system. The factory didn’t get a release button. Changelog drafting got one. Version arithmetic got one. Readiness checking got one. The big button is just the sum of small earned ones.
What the button actually does
So what happens when I press it? Less than you’d think, and that’s the point.
By the time the button is pressable, everything reversible has already happened: the work is merged, the checks are green by construction, the release draft — version, changelog, contents — has been assembled by an agent from the actual merged record, not from anyone’s memory of the week. The button is the one thing left that I refuse to automate: the moment where a human looks at the assembled evidence and commits the irreversible.
This is a deliberate asymmetry. Drafting is cheap, reversible, and verifiable — perfect agent territory. Publishing is none of those things. So the machine does everything up to the line, and presents me with a decision that takes thirty seconds precisely because everything under it is trustworthy. Thirty seconds is not the cost of the release. It’s the interest payment on keeping the right to say no.
And every autopilot in the system carries its stop-cranes — pause, skip, abort — one press away. Automation without a handbrake isn’t automation; it’s abdication with better marketing.
Cadence is a forcing function
Seventeen releases also means seventeen small releases, and the smallness is load-bearing.
A factory that ships quarterly accumulates a quarter’s worth of unverified interaction between changes; the release becomes an event, events need heroes, and heroes are a process smell. A factory that ships continuously with no versioned checkpoints has the opposite disease: no moment where anyone asks “what did we just become?” Versioned, frequent, small releases are the middle path: each one is a checkpoint small enough to actually review, cheap enough to roll back, and frequent enough that the release machinery gets exercised weekly instead of remembered quarterly. The muscle stays warm. The button stays honest.
There’s a compounding effect too: because releases are cheap, nothing waits. A finished improvement ships in days, which means feedback arrives in days, which means the specs for the next cycle are written against reality instead of against a roadmap’s guess about it.
The recursion is the test
One more thing about 0.17 that I keep coming back to: the factory released itself. The agents that drafted the release notes are the same machinery the release notes describe. The fix rounds that kept the checks green ran inside the system whose checks they were keeping green.
I like this recursion not because it’s clever but because it’s the strictest test I have. It’s easy to believe your delivery process works when it delivers something else — someone else’s product, a demo, a toy. When the process has to deliver the process, every weakness becomes self-referential: a flaky gate blocks the release that would have fixed the flaky gate. Dogfooding isn’t a virtue signal here; it’s a survival constraint. The factory works on the factory, or there is no factory.
The same week I cut 0.17, the industry was busy debating why software factories fail — and the diagnosis (ship fast, read nothing, trust the green checkmark) is correct for the factories it describes. Mine shipped quietly, from a button, because it was built on the opposite bet: automate the reversible, gate the irreversible, and make every button prove itself before it gets to exist.
The button isn’t the achievement. The seventeen releases of earned trust behind it are.
Fifth in a series on running an AI software factory: the trust ladder (how autonomy is earned), pets-not-cattle (where agent sessions live), lights-on (why factories that delete review fail), and the unbounded gate (what machine review reveals about human review). This one is about the day the ladder reached the release.