I run a handful of small AI programs I call routines — one drafts blog posts, one triages ideas I dictate into my phone, one was supposed to turn approved posts into short social clips. This week I finally asked the obvious question: are they any good?
For the one that drafts content: 42 drafts written over the past month. 3 approved. 39 rejected.
The clip-cutting one was worse. 25 clips, 25 rejected, 0 approved. It had been running every single week with nobody keeping score.
The bug wasn’t the writing. It was that when I rejected a draft, the system recorded only that it was rejected — never why. The reason lived in my head and nowhere else. The next run had no way to learn from the last one, so it made the same mistake again, and I got annoyed about it in exactly the same way, over and over.
I added a required field: type the reason when you reject something. The drafting routine now reads its last ten rejection reasons before it writes anything new — the first one in my whole setup that gets to see its own report card.
I also paused the clip-cutting routine entirely instead of trying to fix it. A routine that turns bad drafts into clips doesn’t have anything good to cut from. The fix belonged upstream, not there.
And because apparently this was reorganization week, I gave the whole crew actual names — Sparky triages ideas, Wordy writes drafts (that’s who wrote parts of this), Clippy is paused, and I built a new one, Salesy, that drafts outreach to leads who’ve gone quiet. None of them send anything on their own. Everything they write sits in a queue until I say yes.
I named my software team before I got around to naming half the folders on my own desktop. Make of that what you will.
My own homepage forgot the news
I published a new post on this site on August 12th. Go to jbmangum.com/blog and you’d have seen it. Go to jbmangum.com — the homepage — and you’d have seen a post from February.
Nothing about it looked broken to a monitoring tool. The server answered every request normally. The problem was that the homepage had never been told to go check for new posts on every visit — only the blog page had. So the homepage had locked in whatever it looked like the last time the whole site was rebuilt, back on August 8th, and just kept showing that, forever, correctly, wrongly.
Chasing that down turned up a second bug hiding behind the first. Mid-fix, both pages briefly started showing a hardcoded fallback post — a fixed, pre-written post built into the code as a backup — instead of anything real, and the error logs showed nothing — no crash, no red text, nothing to search for. The code that fetches my Substack feed had been quietly accepting an error page from Substack as if it were a real response, finding zero posts in it, and shrugging back to the fallback without telling anyone. I added a check that actually looks at whether the fetch succeeded, and a line that logs when zero posts come back, so next time it says something instead of going quiet.
Neither bug looked like a failure. A system can be completely wrong and still hand back a perfectly normal-looking response. the only way to catch that is to go look, not to wait for it to complain.
A new project: 100 Days
Also shipped this week: a pre-launch website for a book I’m writing, called 100 Days. It’s live at 100-day-truth.bmangum1.workers.dev or now, ahead of it getting a proper domain. Right now it’s just an email list — leave your address, get a free guide when it’s ready — while I finish writing.
The book is about roughly thirty years of drinking, the back half of it more sedation than anything resembling a good time, and what actually changed. Part of this week went into a real edit pass on it — the kind where you check that a claim made in chapter one is still true by chapter eight, not just that the sentence reads well.
More on the book itself once there’s more to show. For now: the list is open if you want the guide.
Also this week, over at Ascend Systems — my software company — a bug meant 71 of 224 tasks in its internal system had silently lost their project assignment, because the function that creates a task never had anywhere to put one in the first place. And a separate fix let the CRM pull in invoices that had been created straight in Stripe the payment processor — which had no local record and were invisible to everything else until now. Small stuff next to the other two, but the same theme runs through all of it: something looked fine, and wasn’t, until I actually went and checked.
If you are building things, learning code, building tools, or just a cloudflare fanboy like me, I would love to hear about your journey.