Learning with AI (Part 1) - Redundancy equals insurance

"Look at the human body. We have two eyes, two lungs, two kidneys, even two brains (with the possible exception of corporate executives) - and each has more capacity than needed in ordinary circumstances. So redundancy equals insurance, and the apparent inefficiencies are associated with the costs of maintaining these spare parts and the energy needed to keep them around."

— Nassim Nicholas Taleb (The Black Swan)

Like all technology, AI is a double-edged sword; it can build things you only imagined and then break them. If you don't want to break something valuable, you need redundancy.

Coming from a cold start, I've now learned that there are two main ways to break something valuable. The first is that you break something in the data that sits behind your website and the second is that you break how the website looks or is used. The first risk has catastrophic potential (you lose all the data) and the second can make you look sloppy. Both can do damage to the relationship you have with potential users.

We all have experience hitting the save button in Word, Excel or PPT. If you're like me, you never thought too much about what happens after that. I eventually realized that the versions you can roll back to, the copies kept somewhere safe, the file that survives a dead laptop, had been handled for me invisibly the whole time. When you build your own products, you have to put it there for yourself.

After some trial and error, to protect the data, a GitHub Action automatically backs up an encrypted copy of my database to cloud storage every day. If I need to make any changes to the database that could delete or change existing data, I have Claude spin up a throwaway copy from the latest backup. While Supabase has point-in-time recovery that adds another layer of redundancy, it still lives inside Supabase. That means, ideally, you have a copy of the database elsewhere in case anything happens to your Supabase project itself.

When I want to test a change, I use a couple of subdomains. One is for database changes and runs against that throwaway copy; a (not real) example could be dbtesting.jeremycowcher.com. The other is for changes to how the website looks or is used; a (not real) example could be testing.jeremycowcher.com. Both are gated by Vercel, which means you need authorization to access them. It's how I check a change in a real setting before it goes "live".

The good news is that I can count the number of times I've had to run this DB test process on one hand. One recent example when I did run it, was changing how I presented co-authors of a book in one of my products.

Just as you hope never to rely on the fact you have two kidneys or two eyes, I hope that setting up this system is insurance against a risk that never materializes. While setting it up isn't exciting, once it's in place you can focus your energy where it matters, building something you want to use.