Automation earns trust by being easy to override, not by being impossible to question.
\nThat sounds backwards. The pitch for automating something is usually that it removes the human, and a system you keep reaching into feels like a system that didn’t finish the job. But the automation you actually trust, over years, is the one you know you can stop.
\nMost automation that you set up is enforcing some sort of policy, and that’s right most of the time, but not always.
\nThe mistake isn’t automating a default way of working. It’s building a system where the default is ingrained so deeply that there’s no way out of it.
\nThe automation must be flexible. You must be able to adapt the automation as the requirements change.
\nDo you have contingency plans on what to do if the automation fails?
\nNow I’m not talking about how to get around the automation, or always forcing an outcome that disables the automation. Instead, I’m talking about what a real escape hatch looks like.
\nIt’s one operation. You run a command. You don’t perform a sequence of five steps where forgetting the third leaves things inconsistent.
\nIt maintains the invariants. This is the big one. When I override a post’s date, the file and the database both get updated. If the override only touched one of them, I’d have created a split-brain problem in the name of fixing a scheduling problem.
\nIt’s discoverable. It shows up in the help output next to everything else. An escape hatch nobody knows about is not a feature, it’s trivia.
\nIt’s supported, not tolerated. It has tests. It survives refactors. Nobody has to feel clever for using it.
\nIf your answer to “what if the automation is wrong” is “go around it manually,” you don’t have a hatch. You have a hazard with a tradition attached.
\nIf you design the escape hatch first, it forces a question that’s worth thinking about. At least what happens when the automation is wrong. What are your plans to do something about it?
\nDon’t forget about the log. It’s not one that you should skip over. You should be logging when your escape hatch gets used, even if it only happens once a quarter.
\nYou probably don’t need to update your policy every time. But your escape hatch log is a good indication of when you might consider updating the policy.
\nBuilding an escape hatch changes the risk. The worst case is not that the tool did something irreversible, but rather that the tool did something I fixed in one command.
\nSo build the hatch. Make it one command, make it maintain your invariants, put it in the help text, and count how often it gets pulled.
\nThe automation you trust isn’t the one that’s always right. It’s the one you know you can overrule.
\n\n\n", "date_published": "2026-08-09T10:00:00-05:00", "url": "https://llbbl.blog/2026/08/09/the-best-automation-has-a.html", "tags": ["DevOps","automation","Software-development","Tooling","Design"] } ] }I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @logan@llbbl.blog.
\n