What Broke in My Lab This Week: A Preview That Went Live, a Mailbox Nobody Trusted, and a Budget That Vanished

Series: Building My Life With AI Bots · Weekly Lab Notes #2

I run my home lab with a crew of AI bots. They build, test, review each other’s work and write down what happened. My rule is simple: nothing gets sent, posted or paid for without my OK. Last week I started reading their failure notes in public. Here’s week two.

Three things that broke (or almost did), why, and what we changed.

1. A preview that landed on the live site#

What broke: A change that was supposed to stay in a preview ended up on the live site. Visitors hit a broken layout, and a few supporting files the live site depends on started coming back as ordinary web pages instead of the files they actually are.

Why: Someone took a shortcut and uploaded a partial copy straight to production, instead of shipping the full build through a preview first. A partial upload is worse than it sounds. It doesn’t just add the new pages. It can replace what was already there with an incomplete set, so visitors and browsers start seeing the wrong thing in place of files the site needs.

What we changed: We froze further uploads to that site and rebuilt from a known-good copy as a preview. The standing rule from here is simple: the only thing that may go live is a complete build that has already been reviewed as a preview. No more one-off uploads.

2. A brand-new mailbox that nobody would accept mail from#

What broke: I stood up a real business mailbox and tried to send ordinary mail from it. The first send bounced. It wasn’t a one-off, either. The same bounce had already hit another outside inbox a few days earlier, so this was about my new mailbox, not about one recipient.

Why: Brand-new mail setups, especially ones still on a trial, often have no sending history. The provider treats that as a risk and sends the mail through a restricted path. Other inboxes look at that path and refuse the message. The parts of the setup I control on my side looked ordinary. The recipients couldn’t fix it, and neither could I, from my side of the mailbox.

What we changed: I converted the trial to a paid seat, asked the vendor to review the new account, and kept volume low — only real conversations, no bulk. A later test send looked fine. I’m not calling it done until everyday mail is reliably delivered.

3. The weekly budget that emptied itself#

What broke: Midweek, the platform I run these bots on reported that the week’s usage budget was almost gone, even though I hadn’t asked them to do extra work. When that budget hits zero, the bots and their scheduled jobs stop.

Why: Usage jumped in a short window with nothing extra running on my side. Other people on the same platform saw the same spike. That points at the platform, not at one runaway job I forgot I had started. Either way, the effect at my desk was the same: I was about to lose the crew until the week reset.

What we changed: I paused every non-essential check-in and scheduled job until the weekly reset, and I kept only the work I had asked for plus anything that was a real safety issue. The lesson I’m keeping: a bot crew needs a budget the same way a lab needs a breaker. When the meter looks wrong, you cut the non-essential load first and ask questions second.

What I’d do differently#

I’d treat “upload this one folder” as a production change, not a convenience. And I’d assume a new mailbox is untrusted until it has sent a handful of real messages without a bounce — not after the first test that happens to look fine.

That’s week two. The lab broke a little in public this time, not just on a test box, and the notes were still more useful than the “done” ones.