The Best Automation Has a Manual Escape Hatch

Sun, 09 Aug 2026 10:00:00 -0500

Automation earns trust by being easy to override, not by being impossible to question.

That 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.

Most automation that you set up is enforcing some sort of policy, and that’s right most of the time, but not always.

The 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.

The automation must be flexible. You must be able to adapt the automation as the requirements change.

Do you have contingency plans on what to do if the automation fails?

Now 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.

It’s one operation. You run a command. You don’t perform a sequence of five steps where forgetting the third leaves things inconsistent.

It 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.

It’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.

It’s supported, not tolerated. It has tests. It survives refactors. Nobody has to feel clever for using it.

If 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.

If 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?

Log When the Hatch Gets Used

Don’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.

You 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.

Building 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.

So 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.

The automation you trust isn’t the one that’s always right. It’s the one you know you can overrule.

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.

Design on LLBBL Blog

The Best Automation Has a Manual Escape Hatch

Log When the Hatch Gets Used