Think about a smart light switch in your house.
When the Wi-Fi is humming and the cloud app works, it feels like magic. Lights dim on a schedule, voice commands work across the room, and you never think about the wiring in the wall.
Nobody cares about the physical, mechanical toggle on that switch until the evening the internet goes down, the hub freezes, and you are standing in a dark kitchen. Suddenly, that boring manual toggle is the only thing that matters.
I learned this the hard way in 2016. I had automated the whole house with LIFX, Nest, a Raspberry Pi, and Node-RED, and I ripped out the kitchen light switches. Then the internet went down while I was away on a business trip, and my wife couldn't turn on the lights. You can imagine the call. I had to un-automate everything. I probably should have left the light switches in place.
As we wrap up this seven-part series on building and working with AI, the smart wall switch is my favorite test for any automated business system: does your workflow still work when the "smart" part fails?
Always keep a way back
Over the previous six parts, we've looked at how AI became both the coder and the client of our software, how a literal client guesses when we leave a blank, and how "all checks passed" can hide a silent failure. We moved the human job to the two ends of the loop, drew a line around the work that affects people, and locked the rulebook where the machine can't edit it.
Even when you do all of that right, there is one final guardrail every team needs: a manual override.
A true manual override has three parts:
- A way to pull the plug. An off switch, a way to revoke an access key, a way to roll back yesterday's automated changes in one click. If the only way to stop an automated system is to politely ask the AI to stop, you don't control it.
- An independent, manual backup. Keep independent copies of your critical records and a simple, non-automated way to do your most important job when the technology is down. Remember: a backup that depends on the same AI system it is backing up is not a backup.
- A brake that engages by itself. Pulling the plug only works if somebody notices in time, so I'd build the brake in. Give every unattended workflow a confidence budget, like a token bucket. It starts full. Every action nobody has looked at drains it a little, say 2 percent, so 50 unreviewed actions empty it. Unfamiliar work drains it faster, like a data format the agent has never seen. At zero, the workflow stops until a person looks and refills it. Yes, that is friction. It is friction on purpose, and it makes the machine wait for me, instead of me chasing the machine.
What to do this afternoon. This series can sound like advice for architects. It isn't. If you are shipping one endpoint today, make your pipeline block any change that touches money, access, or customer support until a person signs off. Write every error message so a stranger could understand it. Add one check that looks at the real outcome. None of that needs a new server or a budget approval. Pick one, try it, and tell me how it went.
If I had to put this entire series into one sentence, it would be this: let the machines run the routine, lock the rulebook and the diary where they can't rewrite them, and never install a smart switch without a manual toggle.
Why I'm still optimistic
None of the warnings in this series make me gloomy. In fact, I am having more fun building things today than I have in years.
The AI is the customer of the code. It may even be the client that placed the order and produced the result. A person still lives with that result, and pays for it.
Think about who sits at the other end of all our software: a real person waiting for a reply, a refund, a delivery, or a medical result. They don't care whether a human or an AI processed the paperwork. They care that it works properly, that the answer is right, and that if something goes sideways, a person can open the diary, see what happened, and fix it.
Who writes and operates the software will keep changing. A few years from now, I expect most of the code that touches my day will have been ordered by one machine and written by another. The person who needs the final outcome to be right won't change. Whether we keep that person in the picture is entirely up to us.
One role I've left alone in this series is the one who pays. Agents are already being handed wallets of their own. What happens the day the machine pays its own bill is a question for another series.
What is one "manual toggle" your business refuses to give up, no matter how much you automate? I'd love to hear about it. Tell me on LinkedIn.
Full disclosure: AI helped me draft this series. The stories and the opinions are mine, and I checked every line, which is kind of the point.
Cheers,
Markus
No bug 🐛 too small, no syntax too weird 🔍 🧐 🔨 🦾